Architectures are iterative creations. They are not sequential, waterfall processes. This obviously means that iterative methodologies such as Agile-Scrum are necessary for projects to succeed. This does not mean, a dearth of documentation or proper planning. Quite the opposite. It does mean however, a limitation to creating relevant and impactful documentation, in which IS supports the Business Strategies and Objectives. The goal is to build a functioning IS Architecture. Not produce endless and quite useless artefacts. An open-standards approach to building aligned IS systems, through an iterative methodology is TOGAF (The Open Group Architectural Framework).
TOGAF is a standard which provides a useful roadmap to both describe and implement IS architectures within larger enterprises. TOGAF proposes an Architectural and Solutions Continuum, in which IT and Business objectives are aligned. Within the Enterprise Continuum TOGAF proposes 10 key phases to develop an open, accountable, business-centric IS as given in the figure below:
Figure: TOGAF’s 10 phases
TOGAF’s 10 Phases
Each Phase is explained below and provides insight into building proper architectures. Not every detail, and artefact of every phase needs to be identified or followed. But in general, the 8 phases are sensible, running from creating the Target Model (Phase A), through Business, IS, Data, Technology architectures, into implementation details, migration, governance and change management. Many projects fail through a lack of change management and governance procedures.
TOGAF targets mostly VLEs (very large enterprises); for smaller firms a scaled down Architecture Development Model (ADM) will suffice. Note that the requirements phase should involve iteration on most projects, using Agile. It is unusual if a project(s) has clearly defined and understood business requirements, which are not in need of elicitation and clarification.
TOGAF’s 10 Phases: (link)
| Preliminary Phase | Preparation and initiation activities required to create an Architecture Capability, including the Customization of TOGAF, selection of tools, and the definition of Architecture Principles. |
| Requirements Management | Ensure that every stage of a TOGAF project is based on and validates, business requirements.
Requirements are identified, stored, and fed into and out of the relevant ADM phases, which dispose of, address, and prioritize requirements. |
| Phase A: Architecture Vision | Set the scope, constraints, and expectations for a TOGAF project. Create the Architecture Vision.
Identify stakeholders. Validate the business context and create the Statement of Architecture Work. Obtain approvals. |
| Phase B:
Business Architecture Phase C: Information Systems Architectures Phase D: Technology Architecture |
Develop architectures in four domains:
1. Business 2. Information Systems – Application 3. Information Systems – Data 4. Technology In each case, develop the Baseline and Target Architecture and analyze gaps. |
| Phase E:
Opportunities and Solutions |
Perform initial implementation planning and the identification of delivery vehicles for the building blocks identified in the previous phases.
Determine whether an incremental approach is required, and if so identify Transition Architectures. |
| Phase F:
Migration Planning |
Develop detailed Implementation and Migration Plan that addresses how to move from the Baseline to the Target Architecture. |
| Phase G:
Implementation Governance |
Provide architectural oversight for the implementation. Prepare and issue Architecture Contracts.
Ensure that the implementation project conforms to the architecture. |
| Phase H:
Architecture Change Management |
Provide continual monitoring and a change management process to ensure that the architecture responds to the needs of the enterprise, and maximizes the business value. |
TOGAF takes these 10 phases and approaches them in an iterative manner. You can cycle within and between phases. For example, in Phase A we deal with scope, vision and general requirements. As you proceed through the Architecture levels and details in Phases B, C and D (IS, Data and Technical); there may well be scope, requirements or other constraint changes, which may impact the original scope and statement of work. You will need to update Phase A and then align the following Phases. Governance, documentation type and quantity are other areas which are usually quite iterative.
TOGAF’s 7 Categories of work
To complete the above 10 phases and properly assess and implement business requirements, TOGAF proposes 7 categories of work, represented in the following, overly elaborate diagram. You start with the Business Requirements move to the right, in an iterative cycle of development and deployment.
Figure: TOGAF’s 7 categories summarised
The above diagram is somewhat complicated, but when viewed by category it becomes clearer what the intentions are. In general terms, we start with an iterative requirements-gathering and elicitation process, mapping these to our target architecture, whilst considering the current model, gaps, capabilities, tools, principles, governance and standards, whose details are contained in the 7 main categories or ‘parts’ are described below.
PART I: Introduction
A high-level introduction to the key concepts behind enterprise architecture and in particular the TOGAF approach. It contains the definitions of terms used throughout TOGAF and release notes detailing the changes between this version and the previous version of TOGAF.
PART II: Architecture Development Method
The core of TOGAF. It describes the TOGAF Architecture Development Method (ADM) – a step- by-step approach to developing an enterprise architecture.
PART III: ADM Guidelines and Techniques
A collection of guidelines and techniques available for use in applying TOGAF and the TOGAF ADM.
PART IV: Architecture Content Framework
The TOGAF content framework, including a structured metamodel for architectural artifacts, the use of re-usable architecture building blocks, and an overview of typical architecture deliverables.
PART V: Enterprise Continuum & Tools
Taxonomies and tools to categorize and store the outputs of architecture activity within an enterprise.
PART VI: TOGAF Reference Models
A selection of architectural reference models, which includes the TOGAF Foundation Architecture, and the Integrated Information Infrastructure Reference Model (III-RM).
PART VII: Architecture Capability Framework
The organization, processes, skills, roles, and responsibilities required to establish and operate an architecture function within an enterprise.
The core of TOGAF is the Architecture Development Model or ADM. The ADM process has the following key characteristics:
- The ADM is iterative, over the whole process, between phases, and within phases
- The breadth of coverage of the enterprise to be defined within the ADM
- The level of detail needs to be defined within the ADM
- The extent of the time period aimed at, including the number and extent of any intermediate time periods needs to be agreed upon
- The architectural assets to be leveraged need to be assessed (current, off the shelf)
- Assets created in previous iterations of the ADM cycle within the enterprise need to be reused if possible
- Assets available elsewhere in the industry (other frameworks, systems models, vertical industry models, etc.)
The above characteristics and decisions need to be based on reality, including resources, skills, budget and general competency.
The phases of the ADM cycle are further divided into steps; for example, the steps within the architecture development phases (B, C, D) given in the table above, are as follows:
- Select reference models, viewpoints, and tools
- Develop Baseline Architecture Description
- Develop Target Architecture Description
- Perform gap analysis
- Define candidate roadmap components
- Resolve impacts across the Architecture Landscape
- Conduct formal stakeholder review
- Finalize the Architecture
- Create Architecture Definition Document
The Requirements Management phase is a continuous phase which ensures that any changes to requirements are handled through appropriate governance processes and reflected in all other phases.
An enterprise may choose to record all new requirements, including those which are in scope of the current Statement of Architecture Work through a single Requirements Repository.
==END