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:

• What is to be governed?
• Why should something be governed?
• When and who should decide on the recommended alternatives?

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:

• Stakeholder: owner of the architecture

  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.

• Stakeholder Agent: representative of the stakeholder
• Subject Matter Expert: possesses specialized knowledge about some aspect of the Enterprise or the environment in which it operates

  Provides knowledge, advice, and validation of interpretation.

• Implementer: responsible for performing all change activity

  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.

• Architect: developer of the Target Architecture

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

• Auditor: performs systematic reviews of both the target and implementation

  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

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.

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

• Senior Leaders are those with responsibility for management and oversight

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

• Program/Portfolio Managers are those with responsibility for management and oversight of strategic initiatives

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

• Business Requirements Owners are those responsible for identifying and expressing business requirements

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

  • Implementers are those responsible for developing, integrating, and deploying the solution
  • Risk Owners are those interested in risk
  • Business Partners are those who are engaged to provide services sustaining a customer value proposition

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

  • Customers are those who consume products and services

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

  B.2     Common Concern Classes

  • Agility: what is the ability of the architecture to adapt to future unanticipated change?
  • Efficiency: how does some aspect of the architecture contribute to efficiency of operations?
  • Differentiation: how does some aspect of the architecture address enable differentiation?
  • Value: what is the value of the architecture?
  • Value Proposition: how does some aspect of the architecture address a value proposition?
  • Change Cost: what is the impact of a change to the architecture in terms of cost of change?
  • Change Impact: what is the impact, or scope, of a change to the architecture?
  • Alignment: to what extent is the architecture aligned with priorities?
  • Feasibility: what is the probability the architecture will be realized and sustained?
  • Dependability: how will the architecture consistently deliver value and operate safely?
  • Control: how will we protect assets in the architecture?
  • Specification: what needs to be built?
  • Security: will the architecture consistently address the risks and opportunities embedded in operations?
  • Confidence: what confidence can be placed in the target?
  • Customer Intimacy: is the Enterprise delivering products and services the customers want? What is the confidence that the new product or service will be liked by them?
  • Scalability: Can the architecture and the Enterprise handle the range of demands and growth cycles?
  • Business Continuity: Does the architecture provide the appropriate level of continuity needs relative to the Enterprise’s needs?

  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

  ---

  Copyright © 2022 The Open Group, All Rights Reserved.
  TOGAF® is a registered trademark of The Open Group

  ---

  <<<Previous

  Home