IT solutions analysis

TOGAF for SOA based solutions
Main ideas of the TOGAF methodology

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:

  1. Business Architecture – defines the business strategy, supervision methods, organizational model and main business processes.
  2. Data Architecture – describes the physical and logical structure of data stored and processed by the organization.
  3. Applications Architecture – provides a road map of IT systems, their interactions and connections to main business processes.
  4. Technology Architecture – which describes the infrastructure in terms of software and hardware to support IT services and other processes.


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)

Preliminary Phase

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:

  • Add the service-orientation principles under architecture principles.
  • Do the SOA maturity assessment using The Open Group Service Integration Maturity Model (OSIMM).
  • Define the SOA Governance and support strategy – SOA governance should extend IT & EA governance.
  • Populate a SOA-related architecture repository like SOA Reference Architecture, SOA Building Blocks, SOA SBB, or SOA technical components.
  • Form the SOA Centre of Excellence (CoE) while establishing the architecture team.

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. Architecture Vision

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.

B. Business architecture

The elements of the business domain are:

  • a description of business architecture and processes,
  • the model and description of sample business uses,
  • the specification of the realisation of business use,
  • business objects model,
  • business rules definitions.

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:

  • success measures,
  • architecture requirements,
  • business service contracts,
  • application service contracts,
  • implementation guidelines,
  • implementation specifications,
  • implementation standards,
  • interoperability requirements,
  • IT service management requirements,
  • constraints,
  • assumptions.

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.

C. Information Systems Architecture

The application domain is composed of:

  • use case model along with a description,
  • requirements specification for systems,
  • system architecture description,
  • interface and protocols descriptions,
  • prototype model of the user interface,
  • program component description,
  • analytics and project models of the system.

The data domain contains the detailed model description, both on logical and physicals level:

  • of the system data,
  • of the system metadata.

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:

  • the creation of a corporate data model,
  • the definition of the target service portfolio for IT systems with suitable detail level.

Artefacts are described with diagrams for presentation purposes.

D. Technology Architecture

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.

E. Opportunities & Solutions

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.

F. Migration Planning

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.

G. Implementation Governance

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.

H. Architecture change management

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.