13   Mapping the EA Leader’s Guide to the TOGAF Framework

The EA Leader’s approach described in this Guide can be mapped to two central elements in the TOGAF framework: the Architecture Development Method (ADM) and the TOGAF Content Framework.

The activity described in this Guide follows the ADM’s Preliminary Phase; the Preliminary Phase is a customized path through the TOGAF ADM. This journey highlights a practical example of the TOGAF concept of iteration, answering the correct question at the right level of detail to inform the next question and decision.

The answers to the questions represent information that may be aligned with the contents of the TOGAF Content Framework. How this information is rendered is dependent upon:

High-functioning teams will take a more rigorous approach to information management (EA Content Framework), employ a more formal architecture description discipline (EA Content Metamodel), and utilize purpose-built modeling and repository management tools (EA Repository). For more detail, see Section 8.4 (Information Managed by the EA Capability).

13.1      Mapping the EA Leader’s Guide to TOGAF ADM Phases

The Preliminary Phase is designed as a customized journey of the TOGAF ADM. This journey is predicated on the best practice of developing EA. The ADM is not a linear process model; rather it is a logical method that places key activity steps together for the purpose of understanding the relationship of activity and clarifying information flow. In Table 9 several TOGAF ADM phases are entered iteratively. Partial indicates work only to the extent needed to answer the question at hand. More elaboration can be done in subsequent architecture work.

For a graphical representation of this journey see Figure 19. The graphic in Figure 19 focuses on Phase A. It highlights that in order to complete Phase A, some amount of work is needed in Phases B, C, and D. The ADM is used to develop the EA. There is no difference between exercising the ADM to architect an EA Capability, a finance capability, a portfolio, or an organizational strategy. We are using the concepts of ADM to support two different activities. Application of steps in ADM phases is limited by the context of supporting the EA Capability.

Table 9: Activity and Key Deliverables

Topic

Mapping to TOGAF ADM Phase

Enterprise Context and EA Context
(Chapter 4)

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
(Chapter 5)

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
(Chapter 6)

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
(Chapter 7)

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
(Chapter 8)

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
(Chapter 9)

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
(Chapter 10)

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[27]
  • 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 application architecture
  • Process and architecture repository gap and priority roadmap

Create the EA Capability Roadmap
(Chapter 11)

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
(Chapter 12)

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 your enterprise desires

13.2      Mapping EA Content, EA Leader’s Approach, and Metamodel

None of the questions or concerns raised in this Guide are purely technical or isolated to a single field or dimension. To deliver on the expectation of EA Capability, other frameworks and best practices should be brought together and customized to meet specific needs of the enterprise’s environment, roles, and responsibilities.

Based on the activities discussed in this Guide, here is a sample mapping of information and where it maps to the generic TOGAF Content Metamodel.

Table 10: Mapping to TOGAF Content Metamodel

Note: Mapping is dependent upon the final metamodel.

Topic

Content

TOGAF Content
Metamodel Grouping

Enterprise Context and EA Context
(Chapter 4)

Goals, strategies, objectives, initiatives, success measures

Plans (business, strategy, workforce, cash flow)

Competitive and tactic analysis, operating model, what-if scenarios, scorecards

Locations, partners, suppliers

Business Architecture

Portfolio Management

Project Management

Financial Management

Business Objectives for the EA Capability
(Chapter 5)

Strategies, objectives, initiatives, success measures

EA Capability and Maturity Model

Scoping the Depth and Breadth of Business Impact with the EA Capability
(Section 9.5)

Process diagrams and models, service and servicing models, portfolio and investments, demand/need descriptions

People, skills, organizational charts

Business Architecture

EA Capability and Maturity Model

Reference Architectures and Standards

Business Objectives for the EA Capability
(Chapter 5)

Alignment with Other Frameworks
(Chapter 7)

Organization Model for the EA Team
(Chapter 9)

Process Model
(Chapter 10)

People, skills, organizational charts

Customer interaction options, types/modes, tools, demands, security/privacy management plans, operational continuity plans

Information system data – requirements, applications, tools, solutions, defects, methods/methodology

Geospatial data IT networks and their connectivity/interaction maps

EA Capability and Maturity Model

Requirement Management

Operating Models

Change Management

Maturity Management

Information Technology Lifecycle Management

Architecture Governance
(Chapter 6)

Process Model
(Chapter 10)

Knowledge management plans, information exchange matrix, events and interactions list, roles, responsibilities, escalation plans

Risk Management

Governance Model

Appendix A: Partial List of EA Content Frameworks

Table 11 provides a list of alternative EA Content Frameworks. Specific mapping White Papers exist between the TOGAF Standard and BIAN, DoDAF, Frameworx, and SABSA (see Referenced Documents).

Table 11: List of EA Content Frameworks

Framework

Framework Description

AGATE

The France DGA Architecture Framework

BIAN

Banking Industry Architecture Network

Deloitte EAF

Deloitte Consulting Enterprise Architecture Framework

DNDAF

The Department of National Defence Architecture Framework (Canada)

DoDAF

The US Department of Defense Architecture Framework

FDIC-EAF

FDIC Enterprise Architecture Framework (US)

FEAF

Federal Enterprise Architecture Framework (US)

Frameworx

TM Forum

GEA

Government Enterprise Architecture – Queensland Government

MoDAF

The UK Ministry of Defense Architecture Framework

NAF

The NATO Architecture Framework

Navigate

Conexiam Enterprise Architecture Content Framework

NIST EA

NIST Enterprise Architecture framework (US)

NORA

Nederlandse Overheid Referentie Architectuur (The Netherlands)

OBASHI

The OBASHI Business & IT Methodology and Framework

OEAF

Oracle Enterprise Architecture Framework

PEAF

Pragmatic Enterprise Architecture Framework

PERA

Purdue Enterprise Reference Architecture Framework

SABSA

The SABSA Institute Enterprise Security Architecture

TEAF

Treasury Enterprise Architecture Framework (US)

UAF

United Architecture Framework (replacement for UPDM)

UPDM

United Profile for DoDAF and MoDAF

Zachman

Zachman Framework

Appendix B: Maturity Models

Note that most maturity models use the term “maturity” to measure the ability of an organization to control change of a capability or process; common usage associates maturity with quality of delivery. We recommend you are very clear on your usage and objective when referencing a maturity model.

Appendix C: Suggested Reading

Acronyms and Abbreviations

ACMM       Architecture Capability Maturity Model

ADM        Architecture Development Method

AEA        Association of Enterprise Architects

APQC       American Productivity and Quality Center

BIAN       Banking Industry Architecture Network

BPMN       Business Process Model and Notation

CAPEX      Capital Expenditure

CEB        Corporate Executive Board

CEO        Chief Executive Officer

CFO        Chief Financial Officer

CISR       Center for Information Systems Research

CMM        Capability Maturity Model

COGS       Cost of Goods Sold

DNDAF      The Department of National Defence Architecture Framework (Canada)

DoC        Department of Commerce (US)

DoDAF      Department of Defense Architecture Framework (US)

EA         Enterprise Architecture

EPCM       Engineering, Procurement, Construction, and Management

ERM        Enterprise Risk Management

FFLV       Functions, Flows (Processes), Layers, and Views

GAAP       Generally Accepted Accounting Principles

IoT        Internet of Things

IRR        Internal Rate of Return

ITGI       IT Governance Institute

M&A    Merger and Acquisition

NASCIO     National Association of State Chief Information Officers

NPV        Net Present Value

OPEX       Operating Expenditure

PMI        Project Management Institute

PMO        Project Management Office

POS        Point of Sale

ROI        Return On Investment

SCOR       Supply Chain Operations Reference (model)

SEI        Software Engineering Institute

SFIA       Skills Framework for the Information Age

SWOT       Strengths, Weaknesses, Opportunities, and Threats

UML        Unified Modeling Language


Footnotes

[1] The terms business, company, organization, and enterprise are often used interchangeably in various texts. This Guide uses the term Enterprise to refer to a logical entity that is taking part in an economic activity; i.e., one that involves some kind of risk/reward or new way of solving socio-economic problems. Likewise, the term organization is in reference to a group of personnel brought together to perform a set of tasks and deliver the outcomes defined for them. The term business is used to refer to the team that formulates and manages the outcomes that the Enterprise is set to do. And the term company is used only when it improves readability, though the definition remains that of an Enterprise.

[2] The references in relation to this paragraph are as follows:

[3] Gartner Clarifies the Definition of the Term “Enterprise Architecture” (see Referenced Documents).

[4] Derived from a presentation entitled Enterprise Transformation – An Architecture-Based Approach, by William B Rouse at The Open Group Conference, January 2012.

[5] Intraprise – a geographically or logically defined grouping of autonomous functions within an enterprise with functions not necessarily reaching outside the boundaries of the enterprise. Several intraprises constitute an enterprise.

[6] Adapted from The Open Group White Paper: World-Class Enterprise Architecture and The Open Group White Paper: World-Class EA: A Leader’s Approach to Establishing and Evolving an EA Capability (see Referenced Documents).

[7] The Open Group White Paper: World-Class Enterprise Architecture (see Referenced Documents).

[8] Delivery is the act of taking something to a place. Deployment is organizing and sending people or things to be used for a particular purpose. Architecture is supporting the act of delivery. Value is realized upon deployment and use of a solution. Hence, the difference is use of terms.

[9] The State of Enterprise Architecture in 2011, Forrester Research; refer to: https://go.forrester.com/blogs/11-11-28-the_state_of_enterprise_architecture_in_2011/.

The State of EA 2014: New Demands, Same Headcount, Forrester Research; refer to: www.forrester.com/report/The+State+Of+EA+2014+New+Demands+Same+Headcount/-/E-RES104542

The State of EA 2016: Weak Enterprise Agendas Still a Fundamental Problem, Forrester Research; refer to: www.forrester.com/report/The+State+Of+EA+2016+Weak+Enterprise+Agendas+Still+A+Fundamental+Problem/-/E-RES121311

Gartner 2015, EA Summit Proceedings; refer to: www.gartner.com.

Corporate Executive Board: see www.cebglobal.com/blogs/the-ea-organization-3-0/ and www.cebglobal.com/blogs/enterprise-architecture-you-dont-always-need-a-seat-at-the-table/.

[10] How Competitive Forces Shape Strategy, by Michael E. Porter (see Referenced Documents).

[11] The Business Model Canvas, by Alexander Osterwalder (see Referenced Documents).

[12] This diagram is adapted from Enterprise Architecture as Strategy: Creating a Foundation for Business Execution, by Ross et al. (see Referenced Documents).

[13] PMBOK® Guide, 5th Edition, Figure 13-4, p.397 (see Referenced Documents).

[14] Diffusion of Innovations (1st Edition), E.M. Rogers (see Referenced Documents).

[15] The 2011 article Enterprise Architecture – Critical to Large Transformation Programs, by Suyog Mahendra Shah (see Referenced Documents).

[16] Depth as used in this Guide relates to the level of detail each “purpose” architecture is scoped to explore based on its parent. Architecture for strategy scopes architecture for portfolio and cascades down. Architecture work for a particular purpose can be performed at any level of detail, although the extremes are rare. Always remember the distinction between scoping and outcome intent.

[17] Successful Leaders are linguistically nimble. Often particular techniques place extreme pressure on a word. Technique practitioners will instinctively defend the technique’s value by defending the specialized use of key terminology. The term “function” is one such word.

This Guide distinguishes between words used in a general manner and when a specialized meaning is required. For “function”, this Guide relies on a general meaning, referring to elements of an organization such as HR, Finance, Sales, Plant Management, and Operations as functions. See Section 4.2.3 on the function-based organization model or Merriam-Webster Dictionary’s first meaning for function: “the special purpose or activity for which a thing exists or is used”.

Successful Leaders need to be able to seamlessly switch back and forth between the specialized language of particular techniques and the generalized language of everyday communication.

[18] Building an Enterprise Architecture Practice: Tools, Tips, Best Practices, Ready-to-Use Insights, by Martin van den Berg and Marlies van Steenbergen (see Referenced Documents).

[19] ISO/IEC 38500:2015: Information Technology – Governance of IT for the Organization (see Referenced Documents).

[20] Corporate Governance: An Essential Guide for South African Companies, by Ramani Naidoo (see Referenced Documents).

[21] The source for this material can be found at: www.applied-corporate-governance.com/best-corporate-governance-practice.html, adapted from Applied Corporate Governance (see Referenced Documents).

[22] TOGAF® and SABSA® Integration (see Referenced Documents).

[23] Derived from the ISO 31000 Risk Management standard (see Referenced Documents).

[24] This figure is an abstracted view of the TOGAF Standard – ADM Techniques, Figure 3-1.

[25] Derived from the World-Class Enterprise Architecture White Paper.

[26] For more on blue ocean strategy, see Blue Ocean Strategy: How to Create Uncontested Marketspace and Make the Competition Irrelevant, by Kim and Mauborgne (see Referenced Documents). Do not confuse this with green field work. Some efforts may be green field within an enterprise, but the pattern may have been solved elsewhere. There is value in such cross-pollination, and the EA team will play the role of a trusted advisor.

[27] 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