Enterprise Architecture Governance

Enterprise architecture governance should not be hard. When the stakeholders understand the work to realize their objectives, they perform the core of governance—direction and control. They direct everyone with an implementation role to do the right thing, and execution controls ensure the work is done.

We can divide all governance activity into enterprise architecture governance to approve the target architecture, and implementation governance.

Architecture Governance & Implementation Governance

Governance is a “system by which an organization is directed, overseen and held accountable for achieving its defined purpose”

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

There is no role for Enterprise Architecture Governance Board to debate, or approve, the target architecture. Best-practice Enterprise Architecture Review Boards own the Process.

Enterprise Architecture Trap #1 - Trying to Own Decision Rights

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.

Decision rights about the enterprise architecture are always vested in the architecture’s Stakeholders.

Successful architecture teams providing enterprise architecture capability make sure that even within the lowest tier (technology architecture governance), Stakeholders own the decision rights.

Download Architecture Governance GuideAn Enterprise Architecture Governance board owns process, and a recommendation regarding completeness and confidence in the work that led to the target architecture.

The short decision-tree checklist pulled from the Enterprise Architecture Governor’s Guide identifies what an architect needs to show. This is the governance checklist for assessing a target architecture.

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 illusionary.

Target Enterprise Architecture Governance Checklist

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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

Following these governance checklists and arranging your EA governance to respect Stakeholder decision rights will enable efficient, enforceable Enterprise Architecture.

Architecture Governance Guide

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.

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.

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.

Enterprise architecture governance is designed to direct and control change. The Enterprise Architecture use cases will help you design your governance structure.

Additional Governance material is in the TOGAF Body of Knowledge

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:

  1. enforce compliance with the target architecture
  2. provide relief and allow the project to ignore the target architecture
  3. 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 Board 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.

  1. 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.
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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.

Stakeholders own the Compliance 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 assist approval of the target.

Anyone including the Enterprise Architecture Board, enterprise architects, and implementers who will not follow the Stakeholders' decision should be fired

Enterprise Architecture Trap #1 - Trying to Own Decision Rights

Join the Personal Enterprise Architecture Kickstart

Free 12-week program to be a better enterprise architect

Scroll to Top