TOGAF: Establishing an Architecture Capability
Use the ADM to establish Architecture TOGAF: Capability
- 1 Phase A: Architecture Vision
- 2 Phase B: Business Architecture
- 3 Related
- 4 Phase C: Data Architecture
- 5 Phase C: Application Architecture
- 6 Phase D: Technology Architecture
- 7 Phase E: Opportunities & Solutions
- 8 Phase F: Migration Planning
- 9 Phase G: Implementation Governance
- 10 Phase H: Architecture Change Management
- 11 Requirements Management
- 12 Related
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. TOGAF: Architecture Maturity Models for guidance on this topic.
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 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 47. Architecture Board, 50. Architecture Governance, and 52. 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.
- TOGAF: Establishing an Architecture Capability
- TOGAF: Architecture Board
- TOGAF: Architecture Compliance
- TOGAF: Architecture Contracts
- TOGAF: Architecture Governance
- TOGAF: Architecture Maturity Models
- TOGAF: Architecture Skills Framework
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.
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 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.
Phase D: Technology Architecture
The Technology Architecture of the architecture practice should define technology infrastructure supporting the architecture practice.
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.
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.
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.
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.
Understanding and managing the requirements for the architecture practice is crucial. Requirements should be clearly articulated and align to the architecture practice vision.