Highlighted Article
Sharing best practice
The Open Group published the first version of TOGAF in December 1995. Shortly before this the US Government had donated the US DOD’s TAFIM (an IT Architecture Framework for Information Management) to The Open Group as a possible common standard for IT Architecture. The newly created Architecture Forum within The Open Group developed an IT Architecture Reference Model based on TAFIM and TOGAF was born.
Over the next ten years the Architecture Forum encouraged its members to develop and adapt TOGAF to meet their own organisations’ IT Architecture methodology requirements. Through this shared ‘best practice’, TOGAF evolved from an IT Architecture reference model to a comprehensive framework and methodology for developing Enterprise Architecture.
The Open Group continues to publish TOGAF, now in its eighth release, providing free access to any organization wishing to develop an enterprise architecture – see http://www.opengroup.org.
TOGAF’s growing popularity
Many organisations, in both the private and public sector, are increasingly turning to TOGAF to help them develop Enterprise and IT Architectures. They are finding that TOGAF helps them produce
- well integrated solution portfolios
- clearly defined interfaces
- reduced complexity
- better managed IT services.
This popularity comes from a number of characteristics.
|
Comprehensive phased approach |
The development of Enterprise and IT Architectures is at the core of TOGAF. A phased approach ensures that managers make good decisions about their business structures and IT. |
|
Complete life-cycle management |
TOGAF has the ability to manage the complete architecture lifecycle – from the initial introduction and visioning of the conceptual architectures to the full specification, implementation and governance of the completed architectures. |
|
Best practice tool support |
TOGAF is supported by a large number of best practice tools and techniques. Customers have a rich infrastructure of instantly available capability to enable them to start using the method and bring it into their organizations quickly |
|
Simplicity and depth |
The appeal of TOGAF is its combination of simplicity and depth. For the CIO and CTO TOGAF’s refreshing simplicity enables IT to easily engage with the business. However, TOGAF also has the depth to manage complexity and provide sophisticated IT services. This combination allows business and IT to work together to build effective business operations and infrastructures that deliver competitive advantage. |
What exactly is TOGAF?
There are three main parts which define TOGAF. These are:
- The Architecture Development Method (ADM) – the centrepiece and core of TOGAF providing the process and method to create the component architectures.
- The Enterprise Continuum – the set of architectures, building blocks and products which are used to create the organization specific enterprise architectures.
- The Resource Base – basic best practice tools and techniques which are used to guide and create the architectures in the Enterprise Continuum.
The ADM
The ADM consists of nine phases – Diagram 1 shows their inter-relationship. Each phase defines a set of activities that enable the sponsor and stakeholders to reach decisions on the enterprise architecture.
Business and IT teams work together, phase by phase, to create and manage the enterprise architecture through its life-cycle.
Preliminary phase: Scoping and identifying resources
We start with the Preliminary Phase, which scopes the enterprise and identifies the resources required to create and deliver the enterprise architecture. It is at this stage that the specific people, process, tools and governance are allocated to the enterprise architecture development work.
The enterprise architecture is created from stakeholders’ requirements, managed throughout the method by the Requirements Management phase.
Setting up the resources, repositories and tools are key activity areas to be addressed in the preliminary stages. Now we are ready to start the enterprise architecture work.

Phase A: Envisioning the future state
The next major step is to create a vision of the future enterprise architecture. We use business scenarios to review the business vision, strategy and drivers. Then we generate a set of business requirements for the future enterprise. From this articulation we create the conceptual enterprise architecture and produce the first-cut “drawings and designs.” These will allow the business to see what the enterprise will look like in its future state.
During this phase we assess the existing baseline enterprise architecture and capability against the vision. Analysing this, we can then assess the work to be done, timescales and costs.
Phases B, C & D: Developing architecture specifications
Phases B, C & D concentrate on developing the individual architecture specifications that make up the whole enterprise architecture. These phases create different views of the enterprise architecture from each stakeholder’s area of interest.
- Phase B creates the new enterprise’s Business Architecture covering the business process, services, function, organisation and strategies.
- Phase C creates the Information Systems Architecture that support the Business Architecture. The Information Systems Architecture is made up of the Data Architecture and Applications Architecture.
- Phase D creates the Technology Architecture that forms the foundation of the target IT infrastructure.
While the main flow of decision making is from B to C to D these are iterative phases that cycle until the final versions of each is achieved and signed off by the sponsor and stakeholders.
Phases E & F: Developing and planning solutions
Phases E and F are concerned with determining the specific solutions architecture and implementation plans to migrate from the current state to the new enterprise architecture. Any procurement and development planning decisions are made at these phases.
Phase G: Managing deployment and realising value
Implementation Governance sits in phase G and provides the architecture governance framework for solutions development and implementation. This phase ensures that the development work remains consistent with the architecture specifications and delivers the requirements of the sponsor and stakeholders.
It is at the end of Phase G that the business starts to realise the business value of the enterprise architecture for their business operations.
Phase H: Managing change
While enterprise architectures can last for many years they must also be refreshed to suit the changing needs of the business. Changes may be needed due to:
- asset management and infrastructure refresh requests
- business process improvements
- re-organizations
- market and business capacity changes
- mergers and acquisitions.
Architecture Change Management, the final phase, allows for such changes throughout both the development and the operational lifecycle of the enterprise architecture.
One reason that enterprise architectures can fail is that the rigour and consistency of the architecture can be compromised and deteriorate over time because of changes. The objective of phase H is to ensure good housekeeping and best practices to keep the enterprise architecture up-to-date and fit for purpose.
Now we have completed the ADM and are ready for change!
The Enterprise Continuum – what have we delivered?
Using the ADM cycle we have created building blocks of business and IT capability to populate the future enterprise. In TOGAF we refer to this capability conceptually as the Enterprise Continuum.
The Enterprise Continuum consists of all the architectures, standards, reference models and deliverables that make up the enterprise architecture. These are in two parts, as illustrated in the Diagram 2.

The usual way to develop with TOGAF is to start with the basic foundation architectures and build on them until the organization specific enterprise architecture is fully defined. The architectures then guide the selection and development of the products and solutions for the organization specific business operations and infrastructure solutions.
The Resource Base – the tools we need to do this work.
TOGAF has a resource base of simple tools and techniques to support the ADM cycles. These range from templates for Principles, Business Scenario tools, skills frameworks, case studies and mappings to other architectures.
However, there are many other tools and techniques available in the marketplace which can support the ADM. In particular, TOGAF certified software tools are available from Proforma, Telelogic and Troux. These assist in the modelling and management of the enterprise architecture products.
Who has benefited from using TOGAF?
There is a growing take-up of TOGAF as an open method to develop Enterprise Architecture. Many organisations use TOGAF to ensure that they have common language, capability and workable deliverables from a range of suppliers and customers. Some examples include:
- Financial services organisations and institutions such as the FSA, Norwich Union and HBOS are at the forefront of using TOGAF, as it enables them to conform to complex legislation and governance requirements.
- Defence contractors such as Raytheon Company recognise the need to use TOGAF to develop their vast range of purpose-built products and solutions.
- Logistics company DHL uses TOGAF to bring global enterprise architectures teams together and manage their Architecture Governance.
- Government agencies are increasingly using TOGAF to develop their capability – examples include DWP and PITO.
TOGAF’s ongoing challenge
Industry leaders and governments are now recognising the value of Enterprise Architecture. This gives us some unprecedented challenges.
- We are still at the beginning of the Information Age.
- Creating, building and joining in with new markets are key to any successful business. Being flexible enough to do this is a significant business challenge – one that is a major driver for Enterprise Architecture.
- The demand for interoperability between enterprises and their world-wide partners is now just normal business life.
- Keeping business processes up-to-date, effective and efficient is a major infrastructure challenge.
- Exploiting new innovations whilst managing culture change is an ongoing requirement for success.
- The audit requirements of governments and markets are becoming more stringent.
All these challenges are at the heart of the CIO role. Many now recognise that quality enterprise architecture and a healthy, well-managed, operating enterprise go hand in hand.
TOGAF Enterprise Architecture is the only world-wide standard methodology that embraces these challenges.
TOGAF: Where to next?
The Architecture Forum is working with and influencing other standards groups, industry bodies and consortia. The objective is to ensure that TOGAF compliments and interoperates with their Frameworks and Methods delivering harmonisation in the marketplace. Example methods included ITIL, MDA, COBIT, DSDM, PRINCE 2, and DODAF.
Currently, TOGAF’s method is being refreshed to bring it up-to-date with modern business thinking and practice. Specifically, these changes will encompass transformation programmes and develop a variety of architecture styles and skills e.g. Agile Architectures, SOA, Dynamic Architectures.
TOGAF is clearly an open methodology without constraints. Its growing usage and acceptance means that it has a great future as the leading, best-practice methodology for creating unified global Enterprise Architectures. We just need to make it happen.