Crucial Role of Enterprise Architecture Governance Checklists
Architecture Governance Processes
Process to Approve Target Architecture
Implementation Governance Process
- Implementation Governance Checklist
- Get Well Recommendation Approach (Non Compliance Recommendation)
- Value Measurement Process
This article explains the the core of delivering architecture governance through the architecture governance checklists. Read these articles to look at all sides. The basics of architecture governance, what is an Architecture Review Board, the goals of a modern dynamic architecture review board, and how to stand-up an ARB.
Architecture Governance Processes
The diagram above outlines the core enterprise architecture review process.
The common pattern is:
Direction comes from above in your organization.
The direction is some mixture of performance expectations, constraints, and risk appetite.
A decision is made. Then the decision is executed.
Controls provide assurance that 1) the decision was followed, and 2) the decision was in alignment with direction.
The diagram below shows a simple cascade from a top-level direction through portfolio decisions, project decisions, solution architecture, to an implementation choice.
The picture below highlights that as direction transitions from strategy, to portfolio, to project, to solution delivery, to implementation each decision is accountably traced backwards. The original direction provider can be provided evidence their directions were followed.
The most agile enterprises have delegated decision making. Aligned decision making. The most successful organization have the same things, alignment and accountability.
The value of enterprise architecture is enabling:
- better decisions
- aligned decisions and actions
- accountable decisions and actions
All resting on architecture governance.
Two Central Architecture Governance Processes
Both the governance diagram above and the architecture decision cycle diagram to the right show cascading decisions.
At some point we transition from architecture development to implementation planning to implementation. The concepts are the same, regardless of whether it's a digital product or a portfolio. You need to transition from governing architecture development to governing implementation.
You need two architecture governance processes. First, a process to approve target architecture. This process will focus on the stakeholders decision rights, and ensuring the target architecture delivers to direction. The target architecture governance checklist explicitly check for performance expectation, constraint, and uncertainty.
Second, you need an implementation governance process that ensures the implementation complies with the architecture. This will include addressing the right problem, following the implementation strategy, and complying with any architecture specifications. All these directions exist to guard the stakeholder's expected value. The implementation governance checklist is designed to guard value.
Requirement for a Dynamic Architecture Review Process
Successful, agile enterprises are not dependent on simple top-down decision making. They have a complex matrix of actors. Complexity requires a dynamic architecture review board. One that can provides effective guidelines and guardrails for delegated decision making.
The Governor's Guide has three statements that highlight the need for dynamic architecture review processes:
- Stakeholders own all decision rights about the target architecture
- Implementers own all implementation decisions
- Attempting to vest these rights anywhere else is an illusion
We can't keep running to the CEO for a decision. She hired people and delegated authority to them. Often with overlapping responsibility.
Enterprise Architects call them stakeholders when they are making architecture decisions, sponsors when they are making planning decisions, and implementers when they are making implementation decisions.
Like the footprints in the picture below, the dynamic process will follow different paths. It will adapt to the current situation. The dynamic process needs to avoid unnecessary challenges getting to the objective.
Process to Approve Target Architecture
The architecture governance process to approve the target architecture needs to be dynamic.
Let's dig into this. A dynamic process comes from three intertwined facts:
- Stakeholders own architectural decisions
- Different architecture decisions have different key stakeholders
- Different architecture decisions will face different priorities and key concerns
It is easy to say 'Decision rights about the enterprise architecture belong to the Stakeholders!' It is hard to say 'these are the right stakeholders.
The criteria and stakeholders facing a consumer-facing digital product decisions are probably different than one facing a financial compliance decision.
The first question in the target architecture governance checklist leans into this dynamism - do the enterprise architects have the right stakeholders? This point is why we use the TOGAF Framework - it refuses to assume there is a single architecture use case and a single universal approach.
The most common difficulty establishing an architecture governance process is confusion about decision rights. Establishing a modern enterprise architecture governance board is based on a governance process of delegated decision making.
The most important oversite roles of the enterprise architecture review board are managing the target architecture approval process and focusing the enterprise architecture team.
The TOGAF Architecture Development Method start with Phase A, where the enterprise architect's essential knowledge includes:
- The problem being addressed
- Who has interests that are fundamental to the problem being addressed
- (Stakeholders & Concerns)
- What are the Stakeholders' priority and preferences
- (Performance expectations, constraints and risk appetite)
- What value does the summary answer provide?
The process of approving a target architecture needs to have a gate based on Phase A's essential knowledge. This knowledge addresses the tough part of enterprise architecture governance—who has decision authority. It separates decision makers from advisors and implementers.
This lets us address the hard part of real enterprise architecture governance method, a variable set of stakeholders own approving the architecture. Yet, their approval is subject to the guidelines and constraints of superior architecture.
It helps us develop an architecture with simplified implementation governance because key implementation leaders will be engaged in developing an architecture that delivers the cascaded performance expectations, constraints and risk appetite.
Target Architecture Governance Checklist
The Target Architecture Governance Checklist was initially published in the Enterprise Architecture Governor’s Guide. It was the included in the TOGAF Standard through the Practitioners' Guide to developing enterprise architecture.
The checklist is a set of controls that ensure the enterprise architect followed directions. The checklist is a control mechanism.
Using the target architecture governance checklist and having architecture governance processes that respect stakeholder decision rights enables efficient and enforceable enterprise architecture.
Target Architecture Governance 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.
Given effective target architecture governance you have direction for implementers. Whether you call them Ends & Means or Performance Expiations and Constraints, or it is a Project in a Portfolio - you have something the Stakeholders expect to be changed. You also likely have constraints about how, or when to proceed.
Those performance expectations and constraints are the foundation of implementation governance.
TOGAF Phase G is all about Implementation Governance. How you use the direction to proceed with the implementation. What constraints are provided. The role of the enterprise architect is primarily focused on guidance and interpretation. As a last resort, where the direction and constraints have not been followed they provide a non-compliance recommendation.
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 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 assessment and prepare a get-well recommendation.
- 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.
Get Well Recommendation (Non Compliance Recommendation)
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 an implementation project is failing to deliver, or failing to follow a constraint, the enterprise architect owes the Stakeholders a Non-Compliance Recommendation.
When there is a problem, the enterprise architect provides a recommendation of what the stakeholder should do. The Non-Compliance Recommendation is architecture governance in action. It identifies the least cost path to recover expected value. Every recommendation will net down to the Stakeholder having 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 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 Board tests the enterprise architects’ recommendation with the Implementation Governance Checklist.
Value Measurement Approach
Conclusion of the Crucial Role of Enterprise Architecture Governance Checklists
Enterprise Architecture Governance Checklists simplify enterprise architecture governance processes. The governance process needs to approve target architecture and provide implementation governance.
Implementing a robust enterprise architecture governance method requires:
- a dynamic architecture review board to provide accountability and traceability
- ensuring stakeholders own appropriate architecture decisions through trade-off between architecture alternatives
- enterprise architects developing architecture views
The result is confidence in the enterprise architecture. You know it represents the best path to deliver top-level goals and objectives.
