15   Architecture Governance

ISO/IEC 38500:2015[35] defines governance as: “a system that directs and controls the current and future state”. The process by which direction and control are provided should imbibe equality of concern and transparency, protecting the rights and interests of the organization.

Governance is a decision-making process, with a defined structure of relationships to direct and control the Enterprise in order to achieve stated goals. The key difference between governance and management rests on the cornerstone of fiduciary and sustainable responsibility.

Most discussion on governance confuses management and governance. John Carver’s Policy Governance is written to support public agencies, where there are often competing priorities and strong distinctions between those who pay and those who benefit. It is one of the best pieces of guidance a Practitioner can get. Lastly, John’s work clearly distinguishes between governance and management. The parallels to EA governance are striking.

The development and use of EA must be governed. To define a customized governance approach, let us start to define the following:

15.1      What is Governed and Why?

Two distinct things must be governed. First, the development of the Target Architecture. Second, all change within the scope of the Target Architecture. Without the first, the Practitioner cannot support their organization’s leadership directing and controlling change. Without the latter, there was no point in developing a good target that provides an organization’s best achievable course forward.

Central to the definition of governance is “directs and controls”. Typically, the Practitioner and implementer are directed, and both are controlled by the stakeholder. This chapter will use the terms direct and control for focus.

15.1.1 Target Architecture

The TOGAF Standard provides a key concept to govern the Target Architecture: the Architecture Project.

The Architecture Project is used to direct and control the EA team to address issues in the Enterprise. An Architecture Project starts with a Request for Architecture Work. The primary control is Architecture Project management using the Statement of Architecture Work. For a broader discussion of controlling the development of the Target Architecture, see the Architecture Project Management White Paper.[36]

In short, the Practitioner is directed to develop an architecture within a controlled scope. Within that controlled scope, the Practitioner is directed to the stakeholder’s preferences. Preferences are expressed in terms of objective, priority, and specification. Best practice requirements management chases objective and priority as the baseline. The governance test will ask whether the Practitioner is addressing the stakeholder’s concerns.

15.1.2 Implementation Projects and Other Change

The TOGAF Standard provides two key concepts to govern Implementation Projects and other change: the Architecture Contract and the Architecture Requirements Specification.

The Architecture Contract is used to direct and control the implementation team to work towards a deliberant future. Regardless of the document structure an Architecture Contract takes in a Practitioner’s organization it will contain the same directional elements and provide a means to test compliance.

The Architecture Requirements Specification is used to direct and control the creativity of the implementation team. Every Architecture Requirements Specification enables control of the implementation team. Design, implementation, and other change choices can be tested against the Architecture Requirements Specification.

In short, the implementation team is directed to create changes with intentional value-based outcomes. Best practice governance enables the organization to control value realization.

15.2      Roles, Duties, and Decision Rights

Decision rights about the Target Architecture, relief, and enforcement are always vested in the architecture’s stakeholders. The most common failure pattern is to confuse roles.

Each role is involved in the governance of developing and using architecture, with different accountability and decision rights. The roles are:

In many organizations, the Practitioner will fill the role of stakeholder agent, subject matter expert, and implementer. This typically occurs when the organization does not use architecture to direct and control change. Instead, the organization attempts to use skilled thoughtful individuals to make tactical decisions. The value is illusionary.

The governance process does not have to be a heavyweight bureaucracy. It is simply based on demonstrating sufficient traceability that the organization can have confidence in the target being the best path to reaching the Enterprise’s preferences. With confidence, the Enterprise will enforce the target in deliberate change activity.

15.2.1 Target Checklist

Use the following checklist to execute architecture governance. Good Practitioners understand that only stakeholders can approve architecture. A good governance process will require the Practitioner to demonstrate the following when assessing a Target Architecture:

1.

Were the correct stakeholders identified?

Yes/No

If yes, proceed.

If no, direct the architect to engage with the stakeholders appropriate to the scope of the architecture being developed.

2.

Were constraints and guidance from the superior architecture taken into account?

Yes/No

If yes, proceed.

If no, direct the Practitioner to perform their job and take into account guidance and constraints from the superior architecture. Where the Practitioner identifies a conflict, obtain a recommendation on whether to grant relief from the superior architecture or enforce the superior architecture. This decision must be made by the superior architecture stakeholders.

3.

Do appropriate SMEs agree with the facts and interpretation of the facts in the architecture?

Yes/No

If yes, proceed.

If no, the Practitioner has to do their job and engage with the SMEs. Where the Practitioner identifies a conflict with, or between, SMEs, 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

If yes, proceed.

If no, the Practitioner needs to do their job and develop appropriate views that are consistent with analysis.

5.

Do the views produced for the stakeholders reflect their concerns and reflect any underpinning architecture models and analysis?

Yes/No

If yes, proceed.

If no, the Practitioner needs to do their job and develop appropriate views.

6.

Do the stakeholders understand the value, and any uncertainty in achieving the value, provided by reaching the target state?

Yes/No

If yes, proceed.

If no, the Practitioner needs to do their job and develop appropriate views, and other work products, then return to the stakeholders.

7.

Do the stakeholders understand the work necessary to reach the target state and any uncertainty (risk) in successfully accomplishing the work?

Yes/No

If yes, proceed.

If no, the Practitioner needs to do their job and develop appropriate work products and return to the stakeholders.

8.

Do the stakeholders understand any limitations in confidence they should have in the Target Architecture?

Yes/No

If yes, proceed.

If no, the Practitioner needs to do their job and develop appropriate guidance on the limitations in confidence and return to the stakeholders.

9.

Have the stakeholders approved the views?

Yes/No

If the answer to the last question is yes, the governance process is done. The architecture, associated view, architecture specifications, controls, and work packages are ready for publication in the EA Repository as an approved Target Architecture.

If the answer to the last question is no, then there is a decision on whether the Practitioner should rework the architecture or the Architecture Project should be canceled. Reworking the architecture typically requires the Practitioner to finally embrace the stakeholder’s preferences. Rework may require more advanced trade-off.

15.2.2 Implementation and Other Change Checklist

When the architecture is being used, changes to the Enterprise are guided and constrained. 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, the target was produced for a purpose and may not have been developed to the level of detail required for the current use. The governance process requires flexibility. When non-compliance is identified, the Enterprise must either change the architecture, provide temporary relief from constraint, or enforce the architecture. If relief is not temporary, the Enterprise has chosen the worst available option: changing the target without bothering with analysis and approval.

Two governance roles are often performed by the Practitioner: the auditor and the architect. Compliance assessment is an auditor role. When non-compliance is identified, the architect needs to produce an impact assessment and recommendation on what to do. The recommendation will have three choices: First, enforce compliance; second, provide temporary relief; and third change the Target Architecture.

The choice in the recommendation will be driven by the impact assessment. Practitioners must assess impact on the same terms as the target was developed. Assessing on any other terms invalidates the assessment and recommendation.

Implementation governance assesses compliance. Compliance assessment needs to be done soon enough that course correction is viable. As identified in the walk-through chapters, compliance assessment against value and operational change are as important as project-driven change.

This checklist is designed to assist the Practitioner understand what must be demonstrated during the governance process to address a non-compliance report:

1.

Did the organization embarking on a change reasonably interpret the Target Architecture’s guidance and constraints?

Yes/No

If yes, their interpretation should be accepted as compliance and any issues addressed through a change to the architecture. This is a key point. Good architecture can have multiple implementation choices, and the implementer is not required to adhere to opinion. If the implementation choice is a reasonable interpretation, it should be judged compliant.

If no, proceed.

2.

Do appropriate SMEs agree with the facts and interpretation of the facts in the impact assessment?

Yes/No

If yes, proceed.

If no, the Practitioner has to do their job an engage with the SMEs. Where the Practitioner identifies a conflict with, or between, SMEs, develop a report for the stakeholders identifying what limitations in confidence they should have in the impact assessment.

3.

Do appropriate SMEs agree with the recommendation to enforce the target, grant time-bound relief, or change the architecture?

Yes/No

If yes, proceed.

If no, the Practitioner has to do their job and engage with the SMEs. Where the Practitioner identifies a conflict with, or between, SMEs, develop a report identifying what limitations in confidence the stakeholder should have in the compliance recommendation.

4.

Do the views and other materials 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 no, the Practitioner has to do their job.

5.

Do the stakeholders understand any limitations in confidence they should have in the impact assessment?

Yes/No

If yes, proceed.

If no, the Practitioner has to do their job and provide the appropriate work products that highlight the impact of limitations in confidence 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 no, the Practitioner has to do their job and provide the appropriate work products that highlight the impact on expected value, and on uncertainly in reaching the expected value and return to the stakeholders.

7.

Have the stakeholders approved the recommendation to enforce the target, grant relief, or change the architecture?

Yes/No

If the answer to the last questions is yes, the organization should action the recommendation. How this is actioned is context and organization-specific. Where compliance is enforced, the governance process should look for evidence of a course correction to the Implementation Project. Lastly, where relief is provided, the Practitioner should ensure that future compliance assessment and reporting take place to review time-bound relief. Without this step, the Enterprise has simply agreed to change the Target Architecture without the bother of approval.

If the answer is no, the stakeholder has spoken. A Practitioner can make the choice to try and convince the stakeholder through expanded information provided to the stakeholder. One of the common mistakes is that the Practitioner either switched terms of assessment from those used to develop the target, or failed to embrace the stakeholder’s preferences when developing the impact assessment.

15.2.3 Long-Term Compliance Reporting

The chapters discussing walk-throughs for Architecture to Support Strategy, Portfolio, and Project all included assessments of in-flight change and consider using summary reporting with a high visual impact. Below is an example of reporting against constraints, expected value, and known gaps. In all cases, the assessment will return either not applicable, conformance, or non-conformance. Good Practitioners will look for binary tests: compliance and con-compliance (Red/Green) where possible. Where binary testing is not possible, a 1-to-3 scale (Red/Yellow/Green) should provide sufficient range to provide a summary report.

Table 10: Example of Summary Governance Reporting

Constraint

(Architecture Principle, Architecture Requirements Specification, or Control)

Value

(Best done in terms of the Enterprise’s mandatory concerns)

Gap

Current state: assess what the Enterprise has

Conforms

Fails to Deliver

Not Applicable

Implementation Project: assess project, design, and implementation

Violates

Not Applicable

Filling

Roadmap, portfolio, or program: assess plans and directions

Not Applicable

Delivers

Leaving Open

15.3      Conclusion

The Practitioner serves the Enterprise’s stakeholders regardless of where they are employed in an organization. This requires the Practitioner to identify with and guard the stakeholders’ preferences. Good Practitioners use their position in front of decisions and outside of the change program to guard value. In practice, a high fraction of governance is informal, with the Practitioner thinking as the stakeholders’ agent and deciding when to push for compliance. For every change initiative, understanding and guarding the Enterprise’s expected value is the most important and arguably the only job of architecture governance.


Part 6: Appendices

Appendix A: Partial List of Modeling Approaches

Table 11 provides a list of modeling approaches. These examples are provided as a starting point for a Practitioner who needs to consistently describe some part of an Enterprise.

The EA community is filled with involved discussions of the distinction between language, notation, model kind, and model type. Such fine-grained distinctions are normally not useful. What is useful is describing something consistently.

These approaches may have a formal or informal metamodel, notation, or supporting method.

Table 11: List of Useful Modeling Methods

Reference Model &
Reference Architecture

Use

4+1 architectural view model[37]

Can be used in Architecture to Support Solution Delivery. The four views of the model are logical, development, process, physical view, and use-case.

Provides a nice simplified list of what you need to know and describe.

The ArchiMate Standard

Excellent fit for Architecture to Support Solution Delivery.

Good fit for Architecture to Support Project.

Business Model Canvas[38]

Use is entirely driven by the scope of the value proposition.

Commonly used for Architecture to Support Portfolio and Architecture to Support Project.

Business Motivation Model (BMM)[39]

Simplified is useful for Architecture to Support Project.

Can be used for Architecture to Support Portfolio BMCs.

Business Process Model and Notation (BPMN)[40]

Can be used for Architecture to Support Solution Delivery.

Limited fit for analysis required in architecture.

Kaplan Strategy Map[41]

Good for representing final strategy.

Organigraphic

Very useful in looking at a governance model of an Enterprise. Use is driven by the scope being described.

Commonly used for Architecture to Support Portfolio and Architecture to Support Project.

A3 Thinking[42]

Useful in summarizing Architecture to Support Project.

Unified Modeling Language (UML)[43]

Good fit for Architecture to Support Solution Delivery.

In particular, useful in providing a standard way to visualize the design of a system.

Appendix B: Stakeholder/Concern Matrix

We recommend that a set of standardized classes of stakeholders, concerns, and associated viewpoints are maintained for each architecture purpose. This follows the advice of aligning the EA Capability with the questions that are expected to be answered.[44] This appendix provides a partial list of common stakeholders, concerns, and their alignment. These examples are provided as a starting point for a Practitioner who needs to address common questions.

Table 12 shows the relationships between the stakeholder classes and concerns for a single architecture purpose.

B.1     Common Stakeholder Classes