This chapter provides guidelines on how to use the ADM to establish an Architecture Capability.

40.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 (BPM) 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.

40.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 45. Architecture Maturity Models for guidance on this topic.

40.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 4.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 list 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, 31. 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 32. Architecture Deliverables are useful references that will assist in describing the architecture framework.

• The Architecture Accountability Matrix defining the roles in the architecture practice and allocating accountability of the roles to architecture deliverables and processes

  This matrix would include the required Architecture Governance structures and roles. Part II: Architecture Development Method (ADM) as well as 41. Architecture Board , 44. Architecture Governance , and 46. Architecture Skills Framework would provide guidance on this output.

• 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

40.4 Phase C: Data Architecture

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.

40.5 Phase C: Application Architecture

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 38. 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.

40.6 Phase D: Technology Architecture

The Technology Architecture of the architecture practice should define technology infrastructure supporting the architecture practice.

40.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.

40.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.

40.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.

40.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.

40.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