The Open Group Architecture Framework (TOGAF) is an integrated set of solutions and tools that support the development of corporate architecture.
Supports four sectors of the architecture:
TOGAF ADM (Architecture Development Method) conceptualizes the architecture development process in a few phases and each of them analyses a selected aspect of the whole issue. Below you will find a description of the TOGAF phases. The depicted approach is characteristic for SOA oriented solutions.
Diagram that illustrates the ADM cycle (courtesy of The Open Group)
This phase focuses on the preparation and initiation activities required to meet the business directive for new enterprise architecture. TOGAF offers an incremental increase of architecture. The preliminary phase is also the time, when requirements for each of the increments are pinpointed.
During the preliminary phase, the engineer will perform the listed activities:
During this phase, the architecture model is created. A diagram of class meta model incorporates all the four domains of architecture and describes their relations using UML notation. The meta model can be treated as a formal requirement specification of architecture products.
A TOGAF scoping diagram
This phase focuses on the vision, scope, business drivers and readiness assessment. A document describing the vision of architecture is created, and its role is to list the formally agreed project expected results and architectural solutions.
The description of strategic architecture is of key importance for phase A. It includes a formal description that creates an organizational framework for operational activities, transformations and provides a long term perspective and to define goals at the management level. It also allows defining separate segments in SOA, before their architecture is decided and described.
Beginning from phase A, for the next three phases the meta model is constantly actualized. Also the documentation is expanded and updated.
The elements of the business domain are:
It is assumed that between phase A and phase B, as part of the architecture solutions management process, a proper specification document for architecture requirements is created (Architecture Requirements Specification). This document provides a quantitative representation of the expected results and measurement criteria for the implementation of the new architecture. This specification is constantly updated and expanded up to phase F.
A recommended content of a specification document for architecture requirements include:
An Architecture Definition Document is a complementary document for the Architecture Requirements Specification. It is a container for artefacts that appear during the process of creation of the new architecture. It provides a qualitative status of the results and depicts the intentions of the architects.
The application domain is composed of:
The data domain contains the detailed model description, both on logical and physicals level:
The phase C concentrates on the application service portfolio and its organizational structure. Most of the changes applied in this phase resolve around the application architecture layer. The description of the base status is updated according to the service model and includes:
Artefacts are described with diagrams for presentation purposes.
During phase D implementation models are created, with a goal to describe the base technical architecture from the logical point of view and to create the target technical architecture in whole service context. The compliance with the SOA Reference Architecture and the SOA Reference Model is checked.
Also in phase D the application components map defined during the design phase is translated into a set of technical components, which will become the elements of the final product.
During the phase E new possibilities and key solutions are identified, as well as the means to implement them in the organization (as intermediate architectures), with a goal to obtain the final desirable architecture. Intermediate architectures are a base for the migration roadman.
In this phase the implementation planning begins, then necessary tools are identified for a give architecture. The expected outcome of this phase is a complete set of documentation (roadmaps, solution matrixes and diagrams) that describe the chosen solutions, integration and management patterns, as well as both internal and external service providers.
This stage aims to create in cooperation with the client a detailed architecture implementation roadmap. It is in same time the verification phase of the model, before the implementation takes place. The main target is to prioritize the projects and estimate their correlations, costs and benefits of distinct migration projects. A prioritized project list is a base for the migration roadmap.
This phase focuses on the creation of principles of managing the implementation of the system. The implementation process is monitored to assure the best quality possible and compliance with the architecture overall. The implementation process should be adherent to the managing models and strategies of SOA and TOGAF, which were defined in previous phases. When all tasks are completed, a post-implementation review is performed. During this stage a revision of two documents can be necessary: Architecture Definition Document and the Architecture Requirements Specification. After the review, the project is closed.
During this phase, which is achieved when the implementation governance phase ends, the change management process is defined for the new database architecture. Within this phase a constant monitoring of technological development and business environment changes is performed, in order to decide if a a new cycle of architecture development should be initiated.