A quick guide to Architectural Governance
Some hands-on or delivery focussed architects may see governance as a barrier to demonstrating value through rapid delivery. I find in these situations that educating the architect on the purpose and benefits of architectural governance will help gain their support and acceptance of the process and lead to more successful outcomes.
I wanted to take this opportunity to outline my thoughts on the purpose, benefits and potential structure of robust architectural governance processes.
The purpose of architectural governance.
The purpose of architectural governance is to ensure that technology and change is introduced to a business in a way that appropriate and sustainable. It should meet the needs of the business, align to an organisation’s strategies, principles and guidelines while fulfilling any non-functional requirements and adhering to agreed technical and documentations quality standards. This can be difficult to achieve as an organisation increases in size and complexity but can be embedded within the organisation through the introduction of an Architectural Governance Framework.
Solutions Surgery
A Solutions Surgery is an opportunity for a new idea to be informally assessed by architects, cybersecurity and operational support staff. It supports the introduction of innovation and ideas from anywhere in an organisation and allows technology professionals to ‘kick the tyres’ of an idea, providing insight into its feasibility within the context of the organisation’s IT Strategy (including Architectural Principles & Technology Codes of Practice), operational support structure and cybersecurity risk appetite.
Design Review
A Design Review can be a formal or informal session where a group of technical peers review a design and provide feedback and guidance on the clarity and technical quality of the design. The outcome of this review should be a ‘high quality’ design document that it is technically feasible within the context of the organisation, contains the necessary level of detail to be understood by any suitably qualified individual and is highly likely to be approved by the Design Authority.
Some organisations may use the Design Review as an opportunity to ensure design documentation meets pre-defined writing and naming standards, ensuring consistency of documentation and terminology regardless of the author.
Design Authority
A Design Authority is the formal governance gateway for any Design Activity. Comprising of senior architecture and technology leaders within an organisation, its purpose is to provide assurance that any ‘design’ brought to the Design Authority meets the organisation’s agreed strategy and architectural principles. If there are any deviations from strategy or technical debt as the result of design, the Design Authority should ensure that there is a plan in place to address it within acceptable timescales.
Post Build Review
The purpose of a Post Build Review is to assess the ‘as-built’ architecture against the approved design including initial requirements and anticipated benefits. This can result in the production of an ‘as-built’ design, benefits realisation assessment or requirements traceability matrix.
The Post Build Review provides an opportunity to measure the success of the architecture function through the number of implementations ‘as designed’, with any exceptions fed back to the architects to support the continuous improvement of the architecture function.
Tailoring the Framework
An Architectural Governance Framework needs to be ‘right-sized’ to the organisation and its approach to IT and governance. For example, there is little value in implementing a full governance framework in an outsourced environment where the design and build of a product is a third party responsibility. In this situation, a Design Review would be sufficient and would allow an internal IT team to understand, review and feedback on a design.
In an agile environment, the Architectural Governance Framework should be tailored to the Agile Framework, making sure that the relevant stages are aligned.
AgilePM / Dynamic Systems Development Method
The Dynamic Systems Development Method is an agile project management framework which was designed to add quality assurances to rapid application development, unlike some agile frameworks, DSDM is designed for traditional projects which have a defined start and finish date.
In the AgilePM Framework, consider holding a Solution Surgery between the Pre-Project and Feasibility Stage, the purpose of the Feasibility Stage is to determine whether a project is feasible from a technical perspective and a Solution Surgery would be able to provide important information and intelligence to help inform the stage outcome.
Look to incorporate the Design Authority into the Foundation stage, and follow an Agile DA approach by setting a minimum viable architecture within which the agile project can operate. As this framework guarantees the delivery of projects to time and cost through the prioritisation of ‘must-have’ features, there’s no need to agree tolerances / guardrails for the solution, however, it’s important to ensure that approved design / minimum viable architecture becomes ‘must-have’ features within the scope of the project.
By building informal design reviews into the Evolutionary Development stage, the technical quality and consistency of the product can be peer-reviewed, which can provide influence future Evolutionary Development cycles.
Holding post-build reviews after each deployment and again following project close will allow the differences between design and deployment to be assessed and any deviations recorded.
