Lets start with explaining what an Architecture Review Board is. An Architecture Review Board manages the process of approving and publishing the target architecture, assessing compliance with the architecture, and determining what action stakeholders will take to correct noncompliance.
Traditional Architecture Review Boards tried to hold decision making authority.
Features of a Modern Architecture Review Board
Centralized decision making, often based on IT criteria, was necessary for long-lived, expensive solutions. Failure to maintain centralized IT standards would cause spiralling IT cost, complexity, and rigidity. To maintain compliance, they performed costly detailed architecture reviews to sign-off the design phase, and just prior to a production release. Normally, this was a rigorous, highly documented process that required levels of approval and formal sign-off.
This approach fails in a modern agile enterprise. Good agile-based software development methods require a different architecture review board. One that supports rapid change, while maintaining enterprise agility. Modern digital enterprises require the ability to reach to unexpected opportunities and threats.
Many software development teams focus on Agile rituals. To optimize software development, they try to organize all decision making around Agile development methodologies. While this makes individual software development efforts easier, it does not deliver enterprise agility. Too often, it leads to a complex IT environment that is costly, rigid, and unreliable. The direct opposite of the right IT environment for digital transformation.
Today, many organizations struggle with how to maintain the benefits of the right IT environment, with the creativity and optimization of decentralized decision making. We solve the difficulty by adopting decentralized decision making supported by a modern Architecture Review Board.
Failure of Traditional Architecture Review Boards
The failure of traditional Architecture Review Boards is the attempt to maintain centralized decision making based on detailed architecture reviews and detailed IT standards. This process requires heavy up-front design and highly documented processes with levels of approval and formal sign-off. An approach doomed to fail in a modern agile enterprise. An approach that actively hinders the benefits of best-practice agile software development.
Traditional architecture Review Boards addressed long-lived hard-to-change systems. We developed long-lived complex systems through a formal method. Following release, they remained unchanged for years. The model worked, many of these systems are still in use. Still supporting the business. Today, modern Architecture Review Boards know that value comes from innovation and the software will be under constant development. We need to adapt the architecture review function to step back from every decision that is easy to change or we expect to change.
Features of Modern Architecture Review Board
A modern architecture review board needs to support
- Decentralized decision making
- Principle-based superior architecture
- Integration & Data based architecture standards
- Enabling infrastructure standards
- Linkage to all levels of agile development
- Existence of a product
- Mandatory acceptance criteria
- Mandatory priority criteria
- Focus on issues that cross the boundary of a development team, the cross-cutting concerns of a system or portfolio
- Empowering agile development and solution teams to be creative and innovate. Value comes from time to market or speed of delivery
Implementing a Modern Architecture Review Board
To implement a modern Architecture Review Board, you must start with the basics. Follow TOGAF Standard 10th Edition (or TOGAF 10) and ensure that decision rights about the fitness of the target architecture belong to the Stakeholders. Remove the legacy of an IT-centric Architecture Review Board. Eliminate the idea that there is central recommended or approved IT and organizational standards or recommending and approving solutions.
There is no role for an Architecture Review Board to debate, or approve, the target architecture, its constraints or guidance, or the compliance of any solution.
Transition the Architecture Review Board to a process manager. Ensure the enterprise architecture development follows the Target Enterprise Architecture Governance Checklist. The checklist is relatively straight-forward:
- Confirm the correct stakeholders were identified
- Confirm any superior architecture constraints and guidance were followed
- Confirm that subject matter experts agree with the facts and interpretation of the facts in the architecture
- Confirm the explanations of the architecture (Architecture Views) align with the analysis, and the constraints or guidance reflect the architecture
- Confirm the explanations of the architecture address the stakeholder’s criteria (Concerns
- Test that the Stakeholders understand the expected value and any uncertainty they will reach the value
- Confirm the Stakeholders understand the work required
None of these steps review the architecture. No modern Architecture Review Board should review the architecture, the standards, or guidance. They ensure experts agree with the facts, and they reflect the criteria driving the organization in the analysis. These are peer review steps. Then they confirm those with decision making authority, can approve the architecture.
Do the same thing when assessing an implementation. Ensure the implementation or software development follows the enterprise architecture development follows the Implementation Governance Checklist. Again, a straightforward approval process:
- Confirm the development or implementation project reasonably followed the guidance and constraint
This is important. Did they reasonably follow the documented guidance? Did they reasonably work within the documented constraints? If they reasonably followed the documented architecture, we are done. The system is compliant.
Only if they did not reasonably follow documented guidance or constraint, do we move forward with non-compliance recommendations. The non-compliance recommendation will come down to change the implementation to deliver the expected value or change the architecture and give-up on some expected value.
Far too often we see after-the-fact questioning of technical decisions. With the questions focused on issues irrelevant to the enterprise architecture. Worst cases we see an undocumented architecture. Then the review is a discussion of opinion. Both are contrary to any good practice.
- Check whether subject matter experts agree they did not reasonably follow constraints & guidance
- Confirm subject matter experts agree with the recommendation to change the implementation or change the value expectations
- Confirm the explanations of cost to get the value, or miss, are based on quality work
- Confirm the stakeholders understand any limitations in confidence they should have in the impact assessment
- Confirm the stakeholders understand what they won’t get the value that justified their approval to proceed, or the extra cost to get what they expected
- Help the stakeholder’s decision about the value shortfall get done
We focus the modern Architecture Review Board on ensuring the stakeholders have quality information to decide. We automatically decentralized decision making to those with the authority to decide. We filter top level decisions down. We sustain criteria to approve a change over time. Expected value is visible throughout the process.
A modern Architecture Review Board isn’t there to help IT-centric decision makers get a stable and long-lived IT environment. Nor is it there to help the sponsor of an agile development initiative deliver code fast. They are there to help develop their enterprise. Driving towards the criteria that matter. Adjusting to an ever-changing business environment and the harsh reality of change.
Next Steps to a Modern Architecture Review Board
The change energy to develop a modern Architecture Review Board is considerable. You need to move decision authority where it belongs. Many people used to a traditional Architecture Review Board instinctively look for a body to make architecture decisions. They assume the decisions, and information, are technical and require a technical understanding. Nothing can be further from the truth in a digital enterprise. Information about change, expected value, anticipated cost and risk needs to be presented. We always tie directly value to the organization’s objectives and current circumstances.
When you are starting your journey to adopt a modern Architecture Review Board, aim for the five goals for a successful Architecture Review Boards are:
- Ensure the enterprise architecture team is can guide effective change
- Ensure Target Architecture development addresses the enterprise’s deficiencies
- Ensure stakeholders approved the target architecture
- Ensure change leaders deliver the expected benefits within their constraints
- Ensure the enterprise architecture governance system functions efficiently
We strongly suggest you download a copy of the Enterprise Architecture Governance Guide. It goes into more detail than this brief article. If you are looking for more focused help, we suggest our Enterprise Architecture Governance Workshop.