Enterprise Architecture Governance
We can divide all governance activity of enterprise architecture governance to activity to govern the target architecture and implementation governance of the change projects expected to deliver the benefits of the enterprise architecture.
In short, you govern the enterprise architects when they are developing an enterprise architecture. Then you use the enterprise architecture to govern the implementation project.
What is an Architecture Review Board?
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.
There is no role for an Enterprise Architecture Governance Board to debate, or approve, the target architecture. Best-practice Enterprise Architecture Review Boards own the Process.
What is Governance?
Direction is what to do
- Ends (Outcome or Objective)
- Means (Boundary)
Control is ensuring accountability
- Test the directions were followed
- Correct when they were not followed
Because the failure pattern is so embedded in practice, we will highlight:
There is no role for an Enterprise Architecture Governance Board to debate, or approve, the contents of the target architecture, its constraints or guidance.
We vest decision rights about the fitness of the target architecture with the Stakeholders. Attempting to vest these rights anywhere else is an illusion.
Approval of the Target Architecture
The most common problem with enterprise architecture governance is confusion about decision rights. A common failure pattern is to establish an Enterprise Architecture Governance board that believes it maintains decision rights.
Successful architecture teams providing enterprise architecture capability make sure that even within the lowest tier (technology architecture governance), Stakeholders own the decision rights.
An Enterprise Architecture Governance board owns process, and a recommendation regarding completeness and confidence in the work that led to the target architecture.
The short architecture governance checklists are from the Enterprise Architecture Governor’s Guide. They identify what the Architecture Review Board requires an enterprise architect to show. This is the target architecture governance checklist.
Following these governance checklists and arranging your EA governance to respect Stakeholder decision rights will enable efficient, enforceable Enterprise Architecture.
Help ensure that they realize the intended benefits and values promised by the target architecture.
Understand the tough part of enterprise architecture governance—who has decision authority. Separate decision makers from advisors, and both from implementers.
We have a separate checklist for implementation governance.
Target Architecture Checklist
- Were the correct stakeholders identified: Yes/No
o If yes, proceed
o If not, send direct the architect to engage with the stakeholders appropriate to the architecture being developed - Were constraints and guidance from superior architecture taken into account: Yes/No?
o If yes, proceed
o If not, either exercise Architecture Governance change, relief and enforcement, or direct the architect to take into account guidance and constraints from superior architecture - Do subject matter experts agree with the facts and interpretation of the facts in the architecture: Yes/No?
o If yes, proceed
o If not, either direct the architect to engage with the subject matter experts or develop a recommendation for the Stakeholders that they should have limitations in confidence - Do any constraints or guidance produced reflect the Views produced for stakeholders and any underpinning architecture models and analysis: Yes/No?
o If yes, proceed
o If not, direct the architect to do their job - Do the Views produced for the Stakeholders reflect their Concerns and reflect any underpinning architecture models and analysis: Yes/No?
o If yes, proceed to the Stakeholders for approval
o If not, direct the architect to develop Views - Do the Stakeholders understand the Value, and any uncertainty in achieving the Value, provided by reaching the target state: Yes/No?
o If yes, proceed
o If not, direct the architect to develop Views and return to the Stakeholders - Do the Stakeholders understand the work necessary to reach the target state and any uncertainty in successfully accomplishing the work: Yes/No?
o If yes, proceed
o If not, direct the architect to develop Views and return to the Stakeholders - Do the Stakeholders understand any limitations in confidence they should have in the target architecture: Yes/No?
o If yes, proceed
o If not, direct the architect to develop Views and return to the Stakeholders - Has the Stakeholders approved the Views: Yes/No?
o If yes, publish the enterprise architecture in the enterprise architecture repository as approved target architecture.
o If not, the Enterprise Architecture Board should decide either to direct the architect to re-work the architecture or cancel the architecture initiative
Implementation Governance
Architecture governance during implementation should be easy. Stakeholders approved the target and the work to reach their objectives. Stakeholders will perform the core of governance—direction and control. Bluntly, when you have good architecture, the stakeholders will direct everyone with an implementation role to deliver. They will test the outcome.
The first step is to have an effective architecture governance that ensures approve the target architecture. With effective enterprise architecture governance covering the target, we can deliver architecture governance during implementation.
TOGAF Phase G is all about Implementation Governance. How do we use direction, control and compliance assessment to ensure the expected value is delivered by a change project.
Implementation Constraints
You can think about enterprise architecture as a set of constraints on the implementer’s freedom. The constraints translate the Stakeholder’s objectives into terms that matter to an implementer.
All the work performed by an enterprise architect is to get the correct constraint. The correct constraint limits the creativity and expertise of an implementation team to deliver key benefit. This is the challenge of architecture governance—how does this implementation should support the broad enterprise goal.
During implementation, architecture governance nets down to ensuring that they realize the overriding enterprise goals. Enterprise architect need not worry about tactical project specific outcomes. The project team will cover that. The enterprise architect has to worry about the outcomes outside the project scope.
We use terms like broad enterprise goal, stakeholder goal or key benefit to distinguish distinct types of goals. Frankly, the project teams should be prepared to deliver a project benefit at the expense of enterprise goal if the linkage is not obvious. We are not suggesting project teams are irresponsible. Rather, if the linkage is not obvious between an implementation choice and damaging an enterprise goal, the pressures of project execution cause them to narrow their decision criteria. If they did not, we could get a fresh implementation team that focused on the project at hand.
The enterprise architecture guides change. If there is no required change, you do not need an enterprise architecture. Architecture governance constrains implementation because this is where outcome is delivered. This is where we get the best combination of tactical project outcomes and enterprise outcomes.
Two factors impact governance of change. First, organizations operate in a dynamic environment, and the analysis of the target architecture cannot have assessed every circumstance or change option possible. Second, they produced the target for a purpose. Most likely that purpose did not provide the level of detail required by an implementation team. This is especially true with agile software development.
Implementation Governance Compliance Choices
The role of implementation governance is to manage compliance assessment and enforcement. All change is subject to compliance reviews against the constraints and guidance in the target architecture. Typically, these perform assessments periodically to assess the operationally changing current state, and associated with a project to assess project-driven change.
Where there is agreement between an implementation choice and the enterprise outcome, we have full compliance. There is nothing to do. This point is key to understanding how to run lightweight governance. We only work where there’s a problem.
When there is a problem, the enterprise architect provides a recommendation of what the stakeholder should do. The Stakeholders only have three choices:
- enforce compliance with the target architecture
- provide relief and allow the project to ignore the target architecture
- change the target architecture
The role of the enterprise architect is to translate the implication of a project implementation choice into its impact on a broad theme for the organization. This is the direct reverse of creating an enterprise architecture. When creating an enterprise architecture, the architect found the minimum set of constraints to enforce the key benefit. During architecture governance, the set of small decisions across multiple projects combines to steer the ship.
A best practice Enterprise Architecture Boards test the enterprise architects’ recommendation with the Implementation Governance Checklist.
Implementation Governance Checklist
The Architecture Governance Checklist provides a set of tests to apply to the enterprise architect's compliance assessment and non-compliance recommendation.
- Did the organization embarking on a change reasonably interpret the target architecture’s guidance and constraint reasonable: Yes/No?
- If yes, we should accept their interpretation as compliance and any issues addressed through a change to the architecture
- If not, proceed with non-compliance.
- Do subject matter experts agree with the facts and interpretation of the facts in the impact assessment: Yes/No?
- If yes, proceed
- If not, either direct the architect to engage with the subject matter experts or develop a recommendation for the Stakeholders that they should have limitations in confidence
- Do subject matter experts agree with the recommendation to enforce the target, grant time-bound relief, or change the architecture: Yes/No?
- If yes, proceed
- If not, either direct the architect to engage with the subject matter experts or develop a recommendation for the Stakeholders that they should have limitations in confidence
- Do the Views produced for the Stakeholders reflect the impact assessment and reflect any underpinning architecture models and analysis: Yes/No?
- If yes, proceed to the Stakeholders for approval
- If not, direct the architect to develop Views
- Do the Stakeholders understand any limitations in confidence they should have in the impact assessment: Yes/No?
- If yes, proceed
- If not, direct the architect to develop Views and return to the Stakeholders
- Do the Stakeholders understand the impact on prior expected Value, and any change in certainty in achieving the Value, provided by reaching the target state: Yes/No?
- If yes, proceed
- If not, direct the architect to develop Views and return to the Stakeholders
- Has the Stakeholders approved the recommendation to enforce the target, grant relief, or change the architecture: Yes/ No
- If yes, the Enterprise Architecture Board should approve the non-compliance action recommendation for publication in the EA repository
- If not, the Enterprise Architecture Governance board has a tough decision. In short, either direct the enterprise architect to expand the information provided to the Stakeholder to get a different decision, or re-work the recommendation to embrace the Stakeholder’s preferences.
Enterprise Architecture Governance Foundation: Stakeholders own the Decision
Stakeholders own the decision. No one else owns the decision. Anyone including the Enterprise Architecture Board, enterprise architects, and implementers who will not follow the Stakeholders' decision should be fired.
Because the failure pattern is so embedded in practice, we will re-iterate the role of the Enterprise Architecture Review Board
There is no role for Enterprise Architecture Governance Board to debate, or approve, the recommendation. Best-practice Enterprise Architecture Review Boards own the Process.
Best practice governance is about direction and control. Implementation governance works during implementation and delivers control. It delivers control to the stakeholder. It provides confidence that the target they approved will be delivered. Anyone who unprepared to work towards the target that is approved is working against the preferences of the Corporation. I don’t know what else you would do with someone who is working against the express preferences of the organization other than fire them.
Last, where relief is provided, the Enterprise Architecture Board should ensure that future compliance assessment and reporting take place to review time-bound relief. Without this step, the enterprise has agreed to change the target architecture without the bother of approval.
Following these governance checklists and arranging your architecture governance to respect Stakeholder decision rights will enable efficient, enforceable Enterprise Architecture. Stakeholders own all decision rights about relief and enforcement. Attempting to vest these rights anywhere else will harm your enterprise architecture team.
Help ensure that they realize the intended benefits and values promised by the target architecture.
Understand the tough part of architecture governance - translating small implementation choice into enterprise impact. Separate decision makers from advisors, and both from implementers.
We have a separate set of tests for enterprise architecture governance that approve the target architecture.
Anyone including the Enterprise Architecture Board, enterprise architects, and implementers who will not follow the Stakeholders' decision should be fired
>>> Jump to Enterprise Architecture Trap #1 - Trying to Own Decision Rights
Architecture Review Boards are the Foundation of Enterprise Architecture Governance
An Architecture Review Board plays a key role in Enterprise Architecture Governance.
What is an Enterprise Architecture Review Board?
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.
There is no role for an Enterprise Architecture Governance Board to debate, or approve, the target architecture. Best-practice Enterprise Architecture Review Boards own the Process.
Five Goals for an Architecture Review Board
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
Features of a modern Architecture Review Board
A modern Architecture Review Board will:
- Be based on decentralized decision making
- Leverage principle-based superior architecture
- Maintain Digital Transformation required Integration & Data standards
- Facilitate Enabling IT standards
- Linkage to all levels of agile development
- Focus on issues that cross authority boundaries
- Empowering creativity and innovation from implementation teams
At Conexiam, we’re a boutique shop with experience in multiple industry verticals across the US, Canada, Africa and the Middle East. Conexiam has established a sound practice of developing architecture predictably.
Understanding the purpose of the architecture engagement, and what information they require, allows Conexiam to tailor the architecture deliverables. Conexiam has developed a Predictable EA approach using fixed periods of time with known deliverables and work product.