3 General Concepts
This chapter describes the general concepts used throughout this Guide.
3.1 Who is an EA Capability Leader?
This Guide is written for a Leader – the person tasked to lead the establishment and/or evolution of an EA Capability. We have selected the term Leader deliberately to reflect the role, rather than one of the myriad titles in an enterprise the Leader may have. Key to the successful establishment of an EA Capability is the Leader’s ability to step back from his or her current operational context to seek broader perspective before making a decision and then following through with the decision to lead the change.
This type of Leader takes into account multiple dimensions, like business drivers, organizational culture, and maturity, as well as the context within which his or her enterprise operates. Such a Leader is cognizant of the fact that their decisions are likely to live longer than their tenure in their current role. This person understands that there are multiple systems in play that interact with each other.
3.2 What is an Enterprise?
The TOGAF framework defines “enterprise” in the context of formal modeling. This Guide applies a different definition focused on defining the boundary of interest and activity. For the purpose of this Guide, an enterprise is the highest level of description of an organization used to identify the boundary encompassed by the EA and EA Capability.
This definition is deliberately flexible and not associated with an organization’s legal or functional boundaries. It covers monolithic organizations and extended organizations that include separate organizations connected by a mission or supply chain, as well as operating entities within an organization. Examples include the outsourced partners that provide manufacturing, logistics, and other support to an organization; a multi-national peacekeeping force; and a multi-billion dollar division of a Fortune 50 firm. All are enterprises.
A given EA will align with the defined boundary of an enterprise. Whether that boundary is an exact match for an organization, a subset, or superset is not material. It is assumed that the EA Capability will align with the boundary of the enterprise and be able to deliver the EA.
An enterprise exists within a context; it has an interaction with what happens outside the enterprise. The context is different for public, governmental, or defense enterprises and private or commercial enterprises. Political, economic, social, technological, environment, and legal forces provide a context for the enterprise.
Figure 1: Context for Commercial Enterprise[4][5]
Public agencies, government, and defense organizations all benefit from EA. This Guide does not comprehensively address all nuances or outlier aspects for government, defense, or not-for-profit enterprises, mainly not to distract the reader with alternate methods or special focus. This Guide assumes that the reader is associated with a profit-making, publicly traded, public defense, or social sector enterprise. The reader will have to make a few adjustments to context and motivation if otherwise. This Guide may in the future be updated to focus on the special needs of public organizations.
3.3 What is an EA Capability and EA?
In short, an EA Capability is the ability to develop, use, and sustain the architecture of a particular enterprise, and use the architecture to govern change.
This Guide discusses establishing and evolving an EA Capability; it explicitly does not discuss an EA department or any other organizational element. The term Capability is often defined tortuously, most commonly when it is used as part of a formal analysis technique when definition must be precise and constrained. This Guide uses EA Capability as a management concept that facilitates planning improvements in the ability to do something that leads to enhanced outcomes enabled by the Capability.
In its simplest terms, EA is used to describe the future state of an enterprise to guide the change to reach the future state. The description of the future state enables key people to understand what must be in their enterprise to meet the enterprise’s goals, objective, mission, and vision in the context within which the enterprise operates. The gap between the enterprise’s current state and future state guides what must change within the enterprise.
Figure 2: EA Capability Model[6]
Using the capability model in the World-Class Enterprise Architecture White Paper[7] as a base, we assume that an EA Capability is established specifically to support one or more purposes. Typically, there are four broad purposes of an EA Capability:
- EA to support Strategy: deliver EA to provide a target architecture, and develop roadmaps of change over a three to ten-year period
An architecture for this purpose will typically span many change programs or portfolios. In this context, architecture is used to identify change initiatives and supporting portfolio and programs. Set terms of reference, identify synergies, and govern execution of strategy via portfolio and programs.
- EA to support Portfolio: deliver EA to support cross-functional, multi-phase, and multi-project change initiatives
An architecture for this purpose will typically span a single portfolio. In this context, architecture is used to identify projects, and set their terms of reference, align their approaches, identify synergies, and govern their execution of projects.
- EA to support Project: deliver EA to support the enterprise’s project delivery method
An architecture for this purpose will typically span a single project. In this context, the architecture is used to clarify the purpose and value of the project, identify requirements to address synergy and future dependency, assure compliance with architectural governance, and to support integration and alignment between projects.
-
EA to support Solution Delivery: deliver EA that is used to support the solution deployment[8]
An architecture for this purpose will typically be a single project or a significant part of it. In this context the architecture is used to define how the change will be designed and delivered, identify constraints, controls and architecture requirements to the design, and finally, act as a governance framework for change.
3.4 EA Lifecycle
Whether the enterprise is embarking on establishing an EA Capability for the first time, is enhancing or re-booting an existing EA Capability, this Guide provides an approach to lead the EA Capability lifecycle and maturity. In all cases, the best practice is to establish a roadmap that provides an end-state and a set of capability increments.
At the time of writing, the most common EA Capability industry practice is a re-boot after a failed attempt to establish an EA Capability.[9] When enhancing an existing EA Capability or performing a re-boot, it is recommended to perform the activities described in Chapter 4 (Enterprise Context and EA Context) and Chapter 5 (Business Objectives for the EA Capability). These activities assist in identifying the pitfalls prior efforts ran into, and strongly influence the external Communication Plan and Roadmap. The following questions exemplify oversimplified thinking in an EA lifecycle:
- Should the EA team be created first and then develop the capability with the team?
- Are charter and sponsorship good enough starting points?
- Is the best starting point for EA practice understanding the enterprise and its external interactions or understanding the team that chartered the EA Capability team?
- Is there a need for a formal toolset at the beginning of the initiative or is back-of-napkin documentation enough?
This Guide discusses such questions as pragmatically and generically as possible to frame a proper starting point. This Guide follows a best practice approach based upon work that has established some of the most successful long-lasting EA Capability teams.
3.5 EA and Other Fields
An EA Capability is normally established in an organization to bring about changes to the current method of operation. Achieving a transformation outcome demands analysis of the current state of the organization along with current industry trends. Implementation of recommendations from such analysis requires planning, funding, and monitoring. In the course of this journey, the EA enablers interact with business strategy, cash flow management, environmental and competitive sustainability, organizational design, information and physical security, and IT and operations management to name a few spaces. Within an enterprise, many of the functions of an EA Capability will be performed, even implicitly, by several organizations.
This Guide does not take the position that a specific EA organization will perform the process and provide resources and deliverables embedded within an EA Capability. However, this Guide, in the following chapters, introduces related resources and an approach to set, build, and evolve the practice of the EA Capability. Leaders frame a charter – the extent of overlap with related functions, sharing of responsibilities, and having the necessary organizational conversations at the enterprise.
3.6 Characteristics of EA
The World-Class Enterprise Architecture White Paper highlights that there is no single correct scope, level of detail, or purpose for an EA. Different enterprises will expect their EA to guide change at different levels within the enterprise.
Herein lies a pair of substantive challenges. First, recognizing that the range, scope, and scale of an EA are as broad as the scope and scale of enterprises and their change programs. Second, the ability to develop, use, and sustain the required EA will be equally as broad. Later in this Guide, various approaches to scope (strategy, portfolio, or project), the effort, and an approach to enhance the positive impact of EA are discussed.
The purpose of EA is to optimize the enterprise to realize a specific business strategy or mission. All optimization must be responsive to change. Optimizing an enterprise to best realize the business strategy or mission requires all components to work together. Achieving competitive advantage is possible when all components are optimized to the enterprise strategy or mission.
An EA that highlights the relationship between the components of an enterprise helps facilitate effective management and exploitation opportunities. EA provides a strategic context for the evolution of the enterprise in response to the constantly changing needs of the business environment.
Furthermore, a good EA enables the sponsors and the enterprise as a whole to achieve the right balance across conflicting demands. Without the EA, it is highly unlikely that all the concerns and requirements will be considered and addressed with an appropriate trade-off.
3.7 Referenced Techniques
Within this Guide, there are references to techniques and key literature created by thought leaders. This Guide is developed using reference materials that are freely available through standards organizations and academic publications. There is no promotion or reference to any commercial techniques or tools. There is often commercial material available for topics discussed in this Guide. It is up to the reader to seek them.
References to key literature and their techniques are intended only to be representative. The reader is expected to read and assimilate referenced publications for a full understanding of these related topics. This Guide only highlights why it is used and what outcome is expected. Further, this Guide does not intend to suggest that the referenced techniques and literature are definitive. Other techniques and key literature can readily be substituted. The literature referenced is part of a body of knowledge that continuously evolves, and the reader is advised to explore updates to literature and techniques referenced in this Guide.
This Guide provides a summary of EA Content Frameworks, many of which are industry-specific, as starting points that can accelerate development of a Content Framework. See Appendix A (Partial List of EA Content Frameworks), Chapter 13 (Mapping the EA Leader’s Guide to the TOGAF Framework), and Chapter 8 (Customization of Architecture Contents and Metamodel) for the discussion.)
To summarize, this Guide offers guidance on what should be considered, how to customize a version of the ADM to an enterprise context, and when to seek use of automation tools. It also provides a commentary on successful approaches to continuously evolve and grow the application of EA Capability to meet the evolving nature of the enterprise context.
TOGAF® is a registered trademark of The Open Group