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:

Provides priority, preference, and direction. All decision rights about the Target Architecture, and any relief from and enforcement of the target, are vested in the stakeholders.

Provides knowledge, advice, and validation of interpretation.

Scope of change is not relevant. Transformative capital projects and incremental operational changes are changes performed by an implementer. All decision rights about proposed implementation choices, such as design, product selection, and change sequence, are vested with the implementer.

Provides recommendations when non-compliance with the target is determined.

Best performed at multiple stages to capture errors before the cost of correction exceeds potential value realization. All decision rights about compliance during the development of the architecture and implementation are vested with the implementer. Auditing can be performed within a formal structure such as an architecture governing board or by a peer reviewer. Auditing can also be self-performed but the role being performed needs to be clear in the mind of the individual and that they are acting in accordance with the role.

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

This responsibility includes approving and realigning strategic initiatives, tracking a portfolio of projects, ensuring transformative benefits are realized, and meeting operational business goals.

This responsibility includes approving and realigning projects, tracking project progress, and ensuring project benefits are realized.

Typically, these stakeholders are responsible for some aspect of business operation.

Note: The architecture may not be provided to business partners, but must be evaluated from their perspective.

Note: The architecture may not be provided to members, but must be evaluated from their perspective.

B.2     Common Concern Classes

For each intersection, a viewpoint is created the identifies the necessary information and communication required to address the concern. (See Appendix C.)

Table 12: Stakeholder Responsibility (Portfolio)

Agility

Efficiency

Value

Value Proposition

Change Cost

Change Impact

Alignment

Feasibility

Dependability

Control

Specification

Security

Confidence

Customer Intimacy

Scalability

Business Continuity

Senior Leaders

X

X

X

X

X

X

X

X

Portfolio Managers

X

X

X

X

X

X

X

X

X

X

Business Requirements Owners

X

X

X

X

X

X

X

X

Implementers

X

X

X

X

X

X

Risk Owners

X

X

X

X

X

X

X

Business Partner

X

X

X

X

X

X

X

Customer

X

X

X

X

X

X

Appendix C: Sample Viewpoint Library

We recommend that a Viewpoint Library is maintained to identify the standard concerns, stakeholders, and the information required to address the question. The information is typically drawn from one or more models. How the view should be constructed is purpose-specific.

Table 13 shows the relationship between the stakeholder classes and concerns:

Table 13: Viewpoint Library (Portfolio)

Concern

Stakeholders

View Construction

Information Required

Agility

Efficiency

Value

Value Proposition

Change Cost

Change Impact

Alignment

Feasibility

Dependability

Control

Specification

Security

Confidence

Appendix D: Architecture Contract Template

This template is maintained to standardize communication from an architecture to a solution delivery team.

Table 14 shows the relationship between the stakeholder classes and concerns.

Table 14: Solution Delivery Notebook

Section

Part

Purpose

Solution Summary

This section provides the summary of the solution.

Central is:

  • What set of gaps in the architecture does the solution address?
  • Who are the stakeholders, relevant inbound requirements, and relevant specifications that address the requirements?
  • What are the risks, and the relevant controls that address the risks?

Solution Concept Diagram

Describes the central problem and how the solution addresses the problem.

Stakeholder Catalog

Identifies key stakeholders, their requirements, and any associated architecture specifications that constrain the design and implementation.

This allows any design and implementation to be tested against stakeholder requirements by tracing the design and implementation to the requirement through the architecture specification.

Risk Catalog

Identifies the risks applicable to the solution and the mitigating controls.

This allows the design and implementation to be tested against risk though the mitigating control.

Gap Catalog

Lists gaps that are addressed by the work package.

This identifies what is in scope of the project and what is not in scope. Keep in mind there will routinely be additional gaps that are not addressed by a project that will need to be identified as such.

Specification Summary

This section provides the summary for testing the design and implementation against the architecture and provides the basis of architecture governance.

Specification conformance will be tested against:

Requirement/specification pair

Risk/control pair

Implementation Strategy

Identifies the preferred approach to addressing the gaps or work packages, where a preferred approach will improve value realization.

Architecture Specification

Identifies all the specifications that address a requirement.

Specifications can be of many different types.

Note that the specification can apply to anything in the architecture, but always traces to a requirement.

Control

Identifies all the controls that mitigate a risk.

Note that the control can apply to anything in the architecture, but always traces to a risk.

Architecture Description Summary

This section provides the summary of the Target Architecture using appropriate diagrams, catalogs, and matrices.

This section is provided for reference.

Business Architecture

Information Architecture

Application Architecture

Infrastructure Architecture

Security Architecture

Other specialized domain architecture depending on the specific organization needs

Appendix E: Another ADM Journey: Leader’s Guide Capability-Based Planning Journey

This Guide has focused on aligning use of the TOGAF Standard to support four primary purposes driving the development of an EA. The journeys described in Chapters 7, 8, 9, and 10 provide purpose-specific journeys.

Practitioners will face many journeys through the ADM.

Table 15 is from the TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability (see Referenced Documents). It outlines a customized journey through the TOGAF ADM that is optimized for an EA Capability; it is easily adapted to other capability-based planning Architecture Projects.

As always, Practitioners identify the information they need to know to answer the question at hand. These answers either inform the next question and/or support a decision. Effective iteration of the ADM is not linear.

Table 15: Mapping EA Capability Development with ADM Phases

Topic

Mapping to TOGAF ADM Phase

Enterprise Context and EA Context

Partial Strategic Level Phase B

Enterprise context:

  • Goals, objectives, initiatives, competitive, and tactic analysis
  • Operating model (partners, suppliers)
  • Explore what-if scenarios and scorecards

EA context specific for the EA Capability:

  • Goals

Business Objectives for the EA Capability

Capability Level Phase A

For the EA Capability:

  • Provide initial goals and objectives
  • Select a reference EA Capability and maturity model
  • Candidate EA Capability
  • Candidate operating model
  • EA Capability gap and priority roadmap

Architecture Governance

Partial Segment/Capability Level Phase B

For the Enterprise:

  • Enterprise Risk Management Model
  • Governance Model

For the EA Capability:

  • Risk Management Model
  • Governance Model
  • Extend candidate operating model to include EA governance
  • Initial Architecture Partition Model
  • Trace to EA Capability goals

Alignment with Other Frameworks

Partial Capability Level Phase B & Partial Phase C (Data)

For the Enterprise:

  • Reference models for key frameworks
  • Capability assessment of key frameworks

For the EA Capability:

  • Framework touch-points
  • Extend candidate operating model to include other frameworks
  • Extend EA governance and EA risk management
  • Initial EA Content Framework aligned to other frameworks and EA governance
  • Candidate architecture partition model
  • Trace to EA Capability goals
  • EA Capability and key framework gap and priority roadmap

Customization of Architecture Contents and Metamodel

Capability Level Phase C (Data)

For the EA Capability:

  • EA Content Framework
  • EA Content Metamodel
  • Viewpoint Library
  • Architecture Repository Model
  • Trace to EA Capability goals
  • Initial EA Content Framework and Architecture Repository gap

Organization Model for the EA Team

Partial Capability Level Phase B

For the EA Capability:

  • EA organizational model
  • Select reference EA skills framework
  • Initial alignment with Enterprise job titles and roles
  • Initial accountability matrix for EA Content Framework and initial Architecture Repository
  • Organizational gap and priority roadmap

Process Model

Partial Capability Level Phase B

Capability Level Phase C (App) and Capability Level Phase D

For the Enterprise:

  • Process model highlighting touch-points between EA Capability and Enterprise processes the EA Capability supports[45]
  • Performance matrix for key processes and organization
  • Accountability matrix for EA Content Framework and organization

For the EA Capability:

  • Process model
  • Architecture Repository application model
  • Matrix for EA Content Framework and Architecture Repository Applications Architecture
  • Process and Architecture Repository gap and priority roadmap

Create the EA Capability

Capability Level Phase E

Create a roadmap highlighting development of the EA Capability by changes in the:

  • Organizational model
  • Process model
  • EA Content Framework
  • Architecture Repository

For the EA Capability:

  • Trace roadmap to EA Capability goals

Establishing and Evolving the EA Capability

Capability Level Phase F and Capability Level Phase G

For the Enterprise:

  • Transition the EA Capability Roadmap to an Implementation & Migration Plan

For the EA Capability:

  • Execute the Implementation & Migration Plan to build the EA Capability the Enterprise desires

Appendix F: Evolving List of Domain Architectures

As the ecosystem in which an Enterprise operates and information technology evolves, specialty domain architectures will evolve. Table 16 documents a partial list of domain architectures and a short note about the domain. The list or the note about the domain should not be considered authoritative or comprehensive.

Table 16: Partial List of Domain Architectures

Domain Architecture

Short Note about the Domain Architecture

Business Architecture

Focuses on business motivations and business operations, linking customers, products, services, finances, suppliers, and partners. The linkages, relationships, and operational aspects are elaborated using the Enterprise’s goals, objectives, strategies, business processes, and capabilities along with its rules and controls.

Security Architecture

An approach that clearly addresses the necessities and potential risks involved in a certain scenario or environment. It also specifies when and where to apply controls to eliminate or mitigate the barriers to attain the objectives, including sustainability and continuity of business.

Service Architecture

An approach to describe the purpose and method of interaction to get an outcome for the buyer/user. Includes clear articulation of the service availability, location, access control, response expectations, and usage methods.

Human Machine Interaction Architecture

An approach to study and optimize the effort and understanding required by humans to work with machines and applications.

Information Systems Architecture

This is a logical grouping describing processes that are automated. The description includes information accessed and produced, infrastructure used to host applications that automates the processes, communicates across applications, or stores information. This is composed of all information, data, application, infrastructure, communications, and integration architectures.

Information Architecture

A structural design and approach to help users (humans and machines) understand where data (text, audio, video, binaries) is, how to find it, what to expect, and how to use it to improve quality of decisions.

Data Architecture

A description of policies, rules, or standards that govern which data is collected, how it is stored, arranged, integrated, and put to use. Organization of data is normally expressed in models.

Application Architecture

Describes the behavior of a solution (automated or manual) applied to solve a business problem, how the solution interacts with other such solutions, and its users. It also describes how the solutions are organized, including its structural and behavioral elements.

Infrastructure Architecture

A description of elements without which core business operations cannot take place. In generic terms, includes buildings and space for parking, power supply, heating, ventilation and air conditioning systems, dining area and restrooms (in other words facilities). In the information technology context, covers bare metal computing devices like servers, routers, switches, and disks.

Communications Architecture

A network of people and machines that connects separate components of an organization. The primary focus of this architecture is to enable flow of information across the organization and rest of the world. Normally includes telephony, video conferencing, and automated response systems.

Integration Architecture

A description of tools and techniques applied to enable applications to interact with each other using appropriate communications and infrastructure architecture. Its focus is on setting rules of engagement between applications including protocols and method, compliant with risk and security architecture.



Footnotes

[1] See the definition of Enterprise in Chapter 2. The important concept to keep in mind is that the term “Enterprise” is used as a boundary of analysis.

[2] For assistance customizing the TOGAF framework, see the TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability (see Referenced Documents), which provides in-depth commentary and guidance for executing the Preliminary Phase of the TOGAF ADM.

[3] The TOGAF Library is available at https://publications.opengroup.org/togaf-library.

[4] See https://psu.instructure.com/courses/1783235/files/77571925/download, August 12, 2008.

[5] A common trap is getting into efforts to fix terminology by using a different synonym. This is always done when people have added meaning, or special conditions, to a word. Implementation means “the process of putting a decision or plan into effect”. Feel free to substitute transformation, change, program execution, or deployment if these words align with your preferences.

[6] Refer to Hambrick & Fredrickson: Are you Sure you have a Strategy? and Mintzberg et al: Strategy Bites Back (see Referenced Documents) for a very good discussion of what a strategy is. For the purposes of this Guide, Hambrick’s position is found to be best suited. He focuses on what a strategy is used for and defines it as the central integrated, externally-oriented concept of how an Enterprise will achieve its objectives. A definition that architecture can support.

[7] The term “superior architecture” is used to refer the architecture created for broader scope and purpose. For the Architecture to Support Portfolio, the Architecture to Support Strategy is the superior architecture. When traversing transition states, the reaffirmed Target Architecture is the superior architecture.

[8] A well-run EA Landscape will maintain components, as well as associated guidance and constraints, through their lifecycle. A typical lifecycle is to be introduced as a candidate, approved through governance as target, then convert to current following an Implementation Project.

[9] See “Managing your Enterprise Repository” in the TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability (see Referenced Documents).

[10] “Oh that process, it is a P3M, don’t worry about it.”

[11] For example, the term “strategy” is widely used; specifically within the OMG’s Business Motivation Model. A high fraction of people who use the BMM trip over the term strategy. It holds a subordinate element in the model and the definition does not immediately resonate with common English. The BMM strategy definition “represents the essential Course of Action to achieve Ends – Goals in particular; it is accepted as the right approach to achieve its Goals, given the environmental constraints and risks”.

[12] The term “stakeholder” is one where many practitioners have preconceptions. Part of the problem is formal definitions having to be broad to ensure that they properly include all reasonably conceivable stakeholders. In this Guide where a formal definition doesn’t provide pragmatic guidance, it will move promptly to pragmatic guidance, and leave the discussion on semantic purity to others.

The TOGAF Standard definition aligns with ISO/IEC/IEEE 42010:2011: “an individual, team, organization, or classes thereof, having an interest in an enterprise or system”.

The Project Management Institute (PMI) definition is: “an individual, group, or organization, who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project”.

[13] Tell the inhabitants of Whitehorse, Yukon Territory that they live in southern Canada. Technically correct, but not helpful to any conversation with someone who knows they live in the North.

[14] See Customization of Architecture Contents and Metamodel in the TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability (see Referenced Documents), and Appendix B.

[15] Refer to John Carver: Reinventing your Board (see Referenced Documents).

[16] In the case of a control, it is always associated to the risk for the same reason.

[17] See Process Model in the TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability (see Referenced Documents).

[18] Refer to Hambrick & Fredrickson: Are you Sure you have a Strategy? (see Referenced Documents).

[19] This Guide is cognizant of repeated efforts to draw distinctions between “Enterprise Architecture” and “Solution Architecture”, which seems to be driven by some attempts to associate EA to big thoughts and big initiatives. In practice it is a distinction that drives no changes in an effective EA team’s organization and approach. This Guide treats it as a distinction without a practical difference.

[20] At several points in this Guide, and other papers from the same authors, there are very statements about effective architecture practice. These statements are drawn from the experience of the authors and reviewers. Gathering, maintaining, and analyzing pointless information is no different than establishing an EA team for the wrong purpose. Eventually, it will be fatal for the EA team.

[21] Earlier this Guide used the term “end state”. In reality, there is no end state for an Enterprise, unless it is terminating its operations. The Guide also used “future state” to indicate lapse of time to achieve and experience the improvement. From this point onward this Guide will use “target state” to indicate that it is the foreseeable best case scenario the Enterprise is striving to achieve. Having achieved, the same concepts and approach for trade-off can be applied or fine-tuned to new scenarios.

[22] American Productivity and Quality Center; refer to: www.apqc.org.

[23] An Architecture Requirements Specification can be delivered through different levels of detail and in multiple ways. For clarity, this Guide distinguishes use of an architecture specification to address a stakeholder requirement, from a control to address a risk. The semantic distinction is used to assess for value. Typically, stakeholder requirements have an up-side, where risks have a downside. This Guide typically divides architecture specification into four types: Principle, used to provide guidance on how to think about the decision; Pattern, used to provide a reusable approach to the decision; Standard, used to specify a correct approach to the problem, and Rule, used to specify a correct answer and eliminate any decision. The level of constraint required determines the type used by the Practitioner.

[24] Do not fixate on definition of the term “project” or what a project is. It is just an organizing effort for work to achieve an understood outcome. Your organization’s internal definition of a project, and the label used, will be unlikely to align with anyone else’s. My assistant refers to booking a flight as a project.

[25] This does not suggest that one person does it all. Developing an EA is a team sport with specialist positions. Following the analogy, the team has to play the same game at the same time.

[26] For the purpose of this discussion, this Guide uses “portfolio” to refer a collection of projects that work to a common outcome. Whether a Practitioner’s organization uses initiative, portfolio, program, or some combination will be determined by the organization’s approach to change, how it has structured its PMO, and how the Enterprise strategy is structured. It is not in the scope of this Guide to pursue the theoretical distinctions between appropriate use of these terms.

[27] Refer to Jeff Conklin’s Wicked Problems & Social Complexity within Dialog Mapping (see Referenced Documents).

[28] Use of the term “desired” is intentional to communicate the fact that it is difficult for a human to foresee and consider change parameters in the future. Until a consensus is reached across key decision-makers, data gathered during assessment is an opinion or a wish. Once confirmed, it becomes a candidate target state. Once funded or signed off, it becomes the target state.

[29] Superior architecture is an architecture that constrains, guides, and directs population of the EA Landscape within the scope of the Request for Architecture Work. Architecture to Support Strategy is the superior architecture for Architecture to Support Portfolio. Architecture to Support Portfolio is the superior architecture for the Architecture Project. The Architecture Project is the superior architecture for Architecture to Support Solution Delivery.

[30] Terms like “initiative”, “portfolio”, and “program” carry organizational connotations and often derail us from communicating the message. Most of the definitions derive from investment management concepts, which essentially states portfolio as a mix of assets that matches the objectives balancing risks against performance.

As defined by the Project Management Institute: “A portfolio is a collection of programs, projects, and/or operations managed as a group. The components of a portfolio may not necessarily be interdependent or even related, but they are managed together as a group to achieve strategic objectives.” And: “A program is a group of related projects managed in a coordinated manner to obtain benefits not available from managing them individually.”

According to Robert G. Cooper: “Portfolio is a dynamic collection of new and existing product or service development efforts, to allocate, de-prioritize, or regroup resources in response to dynamic opportunities, multiple goals, and strategic considerations, interdependence among projects, and multiple decision-makers and locations.”

All of these definitions do not explicitly address the continuity and connectedness of the efforts in the context of an Enterprise. In order to stay away from such limitations, this Guide resorted to using “theme” to indicate that work packages should be grouped in such a way as to enable populating neighbors in the EA Landscape. One theme may populate the Operational Excellence capability landscape while another may populate the Financial Controls capability.

[31] Is the Architecture Project in the Mojave Desert of the EA Landscape or in Abu Dhabi?

[32] For a discussion of the different roles a Practitioner may play, see Section 11.3 and Section 15.2.

[33] See Appendix F.

[34] For a detailed discussion, read the referenced Open Group Guide: Integrating Risk and Security within a TOGAF® Enterprise Architecture.

[35] ISO/IEC 38500:2015: Information Technology – Governance of IT for the Organization.

[36] Architecture Project Management: How to Manage an Architecture Project using the TOGAF® Framework and Mainstream Project Management Methods (see Referenced Documents).

[37] Refer to Kruchten: Architectural Blueprints – The “4+1” View Model of Software Architecture (see Referenced Documents).

[38] See: http://businessmodelgeneration.com/canvas/bmc.

[39] See www.omg.org/spec/BMM/Current/.

[40] See www.omg.org/spec/BPMN/2.0/.

[41] Refer to Kaplan and David: The Balanced Scorecard (see Referenced Documents).

[42] See http://sloanreview.mit.edu/article/toyotas-secret-the-a3-report/.

[43] See www.omg.org/spec/UML/2.5.

[44] See Customization of Architecture Contents and Metamodel in the TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability (see Referenced Documents).

[45] While this has been stressed in the guide, align to processes the EA Capability is expected to support based upon its purpose. Do not align to those it could support. Worst practice is to fret over linkage to processes the EA Capability could support.

return to top of page