This chapter provides guidelines on how to use the ADM to establish an architecture capability.
46.1 Overview
As with any business capability, the establishment of an enterprise architecture capability can be supported by the TOGAF
Architecture Development Method (ADM). Successful use of the ADM will provide a customer-focused, value-adding, and sustainable
architecture practice that enables the business, helps maximize the value of investments, and pro-actively identifies opportunities
to gain business benefits and manage risk.
Establishing a sustainable architecture practice within an organization can be achieved by adhering to the same approach that is
used to establish any other capability - such as a business process management capability - within an organization. The ADM is an
ideal method to be used to architect and govern the implementation of such a capability. Applying the ADM with the specific
Architecture Vision to establish an architecture practice within the organization would achieve this objective.
This shouldn't be seen as a phase of an architecture project, or a one-off project, but rather as an ongoing practice that
provides the context, environment, and resources to govern and enable architecture delivery to the organization. As an architecture
project is executed within this environment it might request a change to the architecture practice that would trigger another cycle
of the ADM to extend the architecture practice.
Implementing any capability within an organization would require the design of the four domain architectures: Business, Data,
Application, and Technology. Establishing the architecture practice within an organization would therefore require the design
of:
The Business Architecture of the architecture practice that will highlight the architecture governance, architecture
processes, architecture organizational structure, architecture information requirements, architecture products, etc.
The Data Architecture that would define the structure of the organization's Enterprise Continuum and Architecture
Repository
The Application Architecture specifying the functionality and/or applications services required to enable the
architecture practice
The Technology Architecture that depicts the architecture practice's infrastructure requirements and deployment in
support of the architecture applications and Enterprise Continuum
The steps in establishing an architecture practice are explained below, against the context of the ADM phases. The reader should
therefore refer to the relevant ADM phase in Part II: Architecture Development Method (ADM), to understand
the complete scope of each step. In this section, key aspects will be highlighted for each ADM phase that should be considered and
are specific to establishing an architecture practice. The intent is therefore not to repeat each ADM phase description, but to
guide the reader to apply each ADM phase within the context of establishing an architecture practice.
46.2 Phase A: Architecture Vision
The purpose of this phase within the context of establishing an architecture practice is to define or review the vision,
stakeholders, and principles of the architecture practice. The focus in this phase would be on the architecture practice as a whole
and not on a particular architecture project.
The following should be considered in terms of understanding the steps in the context of establishing an architecture
practice:
Establish the Project: This step should focus on defining the stakeholders in the architecture practice. The
stakeholders would include the roles and organization units participating in the architecture practice, as well as those that will
benefit from the deliverables generated by the architecture practice that can therefore be defined as customers of the architecture
practice.
Identify Stakeholders and Concerns, Business Requirements, and Architecture Vision: This step generates the first, very
high-level definitions of the baseline and target environments, from a business information systems and technology perspective for
the architecture practice.
Identify Business Goals and Business Drivers: This would be more relevant for the architecture practice than for a
particular architecture project. An understanding of the business goals and drivers is essential to align the architecture practice
to the business.
Define Scope: Defining the scope of the architecture practice would be a high-level project plan of what should be
addressed in terms of architecture for the next period.
Define Constraints: The focus in this step should be on the enterprise-wide constraints that would impact on all
architecture projects.
Review Architecture Principles, including Business Principles: The intent in this step should be to define the
principles that would govern and guide the running of the architecture practice. Where architecture principles usually govern the
architecture deliverables, the architecture practice principles would address the architecture practice organization, content,
tools, and process.
Develop Statement of Architecture Work and Secure Approval: This step should generate the architecture practice vision
and scope.
Another step that can be considered during this phase is to conduct an architecture maturity assessment. Refer to 51. Architecture Maturity Models for guidance on this topic.
46.3 Phase B: Business Architecture
Key areas of focus during this phase of establishing or refining the Business Architecture of the architecture practice are:
An Architecture Ontology defining the architectural terms and definitions that will be used in the organization in order
to establish a common understanding of these terms.
The Architecture Process where the ADM would form the base of the process and need to be customized to meet the
organization's requirements and architecture practice vision. Refer to 5.3 Adapting the
ADM for guidance on developing this process. The required architecture governance processes should be included in the
overall architecture process.
The Architecture Viewpoints and Views that lists all the viewpoints and views that should be addressed by the
architecture practice. The identified architecture practice stakeholders would guide the development of this definition. One of the
viewpoints to be included is the architecture governance viewpoint; refer to Part IV, 35. Architectural Artifacts for guidance on this output.
The Architecture Framework describing the various architecture deliverables that will be generated by the architecture
practice, the inter-relationships and dependencies between the architecture deliverables, as well as the rules and guidelines
governing the design of these deliverables. The defined architecture viewpoints and views should be used to guide the definition of
the architecture framework. Part II: Architecture Development Method (ADM) and 36. Architecture Deliverables are useful references that will assist in describing the architecture
framework.
The Architecture Performance Metrics identifying and describing the metrics that will be used to monitor the performance
of the architecture practice against its stated architecture practice vision and objectives.
The Architecture Governance Framework which is a specific view of the defined architecture process and Architecture
Accountability Matrix.
46.4 Phase C: Information Systems Architecture - Data
The Data Architecture of the architecture practice would specify and govern the structure of the organization's Enterprise
Continuum and Architecture Repository. The Data Architecture should be defined based on the architecture framework. The Data
Architecture is sometimes referred to as the metamodel of the architecture practice.
46.5 Phase C: Information Systems Architecture - Application
The Application Architecture of the architecture practice defines the functionality required to generate, maintain, publish,
distribute, and govern the architecture deliverables as defined in the architecture framework. A key focus should be on the
modeling toolsets required for modeling, but it should not be the only focus. Refer to 42. Tools
for Architecture Development for guidance on selecting a toolset. Publishing the architecture deliverables to address
specific views in the architecture framework would sometimes require specialized or customized functionality and should not be
neglected.
46.6 Phase D: Technology Architecture
The Technology Architecture of the architecture practice should define technology infrastructure supporting the architecture
practice.
46.7 Phase E: Opportunities & Solutions
A critical factor to consider during this phase of planning the establishment of the architecture practice is the organizational
change that is required and how this will be achieved.
46.8 Phase F: Migration Planning
The focus should not only be on the Information Systems Architecture components in this phase, but include the Business
Architecture. The adoption of the architecture process and framework will have a major impact on the overall establishment of the
architecture practice in the organization.
46.9 Phase G: Implementation Governance
The implementation of the Business Architecture of the architecture practice should be the focus of this phase. Changing
practices within the organization to adopt a more structured and disciplined approach will be a challenge and should be addressed
by the appropriate organizational change techniques.
46.10 Phase H: Architecture Change Management
Changes to the architecture of the architecture practice should be managed by this phase. These changes are usually triggered
during the execution of architecture projects. A typical change would be the requirement for a new architecture deliverable. This
would impact on all the architecture domains of the architecture practice.
46.11 Requirements Management
Understanding and managing the requirements for the architecture practice is crucial. Requirements should be clearly articulated
and align to the architecture practice vision. return to top of page
Navigation
The TOGAF document set is designed for use with frames. To navigate around the document:
In the main Contents frame in the left margin of the page, click the relevant hyperlink to load the Contents List for that Part
of the TOGAF document or go direct to a chapter within the document.
Within a chapter you can select Previous and Next at the top and bottom of the page to move to the previous or next chapter, or
select Home to return to the welcome page.
Downloads of the TOGAF documentation, are available under license from the TOGAF information web site. The license is free to any
organization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture for
use within that organization). A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document G091.