The Open Group Architecture Framework (TOGAF®)

The Open Group Architecture Framework (TOGAF®) is an open standard for designing, planning, implementing and governing enterprise architecture. It provides a shared method, vocabulary and collection of practices rather than a ready-made architecture for a particular organisation.

When to use it

Use TOGAF to align business operations and technology with current and future objectives. The enterprise architecture acts as a governed blueprint for processes, information, applications and infrastructure. The classic model examines four connected domains:

• Business architecture: capabilities, governance and key processes.
• Data architecture: data assets and the resources used to manage them.
• Applications architecture: application systems, their interactions and their support for business processes.
• Technology architecture: software, hardware and network infrastructure.

Data and applications are sometimes grouped as information-systems architecture. The domains should be developed together because decisions in one create constraints and opportunities in the others.

Origins

TOGAF was first published in 1995 and drew on the United States Department of Defense Technical Architecture Framework for Information Management. The Open Group—an industry consortium that develops standards, certification and shared practice—has maintained the framework through successive public editions.

What it is

The original 1995 framework evolved substantially while retaining its focus on a repeatable architecture-development method. The article’s historic reference point is version 9.1 as of December 2011; practitioners should consult The Open Group for the edition applicable to current work rather than treating that version as current.

How to use it

The classic TOGAF approach combines the Architecture Development Method (ADM), the enterprise continuum and supporting resources.

The ADM is a tailorable cycle for developing and governing an enterprise architecture:

• Preliminary: establish capability, governance, principles and the tailored method.
• A — Architecture Vision: agree scope, stakeholders, value and direction.
• B — Business Architecture: describe the current and target business design.
• C — Information Systems Architectures: develop the data and application views.
• D — Technology Architecture: define the enabling technology environment.
• E — Opportunities and Solutions: group changes into workable solution increments.
• F — Migration Planning: prioritise and sequence the transition roadmap.
• G — Implementation Governance: maintain conformance and resolve design decisions during delivery.
• H — Architecture Change Management: monitor change and determine when another cycle is needed.

Requirements management connects the phases, and iteration is expected both within and between cycles. Tailor the artefacts, depth and sequence to the decision rather than completing every possible document.

The enterprise continuum classifies reusable architecture assets from generic foundations to organisation-specific designs. It helps teams store, find and adapt models, patterns and descriptions produced through ADM work. Supporting reference materials historically included the Technical Reference Model, Standards Information Base and Integrated Information Infrastructure Reference Model.

Treat the repository as organisational memory, not a document graveyard. Each asset needs ownership, provenance, applicability and a relationship to real decisions and implementation.

Final analysis

TOGAF is widely recognised because it is open, comprehensive and explicitly connects business processes with information and technology. It gives large organisations a common language across architecture domains.

The same breadth creates the main risk. A consensus framework requires tailoring; generic phases do not prove that every artefact is necessary or that one phase mechanically determines the next. Success should be measured by better decisions, coherent change and governed implementation—not by documentation volume.

Top practical tip

Start from the business outcome and architecture decision, then tailor ADM depth, participants and artefacts to the uncertainty and risk involved.

Top pitfall

Applying every phase and artefact regardless of need can create an architecture bureaucracy that produces documentation faster than decisions.

Further reading

The Open Group: www.opengroup.org/TOGAF and www.TOGAF.org