The Architecture Development Method

Digital transformation is often described as a technology problem: replace a legacy application, implement a new platform, integrate systems, or move a service online.

But the technology is only one part of the transformation.

A successful transformation also needs to address the business processes, information, applications, integrations, infrastructure, people, governance, and operating model that surround the technology.

This is where enterprise architecture provides a useful perspective.

The TOGAF Architecture Development Method (ADM) provides a structured way to move from an architecture vision toward a target architecture, implementation, governance, and ongoing change.

In this article, I use a generic service-transformation scenario to illustrate how the ADM can be applied in practice.

1. Start with the Architecture Vision

The first question isn’t:

What software should we implement?

It is:

What are we trying to change, and what future state would enable the desired business and service outcomes?

For a service organization, that might mean moving from fragmented, manually intensive processes toward a more integrated digital service environment.

The transformation vision could include:

• simpler customer access;
• streamlined business processes;
• greater self-service;
• improved visibility;
• better information flow;
• reduced manual workarounds; and
• a more integrated technology environment.

The architecture building blocks

From that vision, the architecture can be examined through several connected building blocks.

The diagram illustrates the relationship between:

• Business processes
• Data / information
• Applications
• Integration & data exchange
• Technology / platform

These shouldn’t be treated as independent boxes.

A change to one can create requirements or constraints in another.

For example, redesigning a business process may change the information that needs to be captured. That can affect application requirements, which can create new integration requirements, which in turn can affect the underlying technology architecture.

This is one of the reasons architecture is useful in transformation: it makes those relationships visible.

2. Understand the Current State

Before designing a future state, the organization needs to understand the environment that exists today.

That includes more than documenting the current application landscape.

A current-state assessment might examine:

• customer access channels;
• business processes;
• applications;
• information and data;
• integrations;
• technology;
• roles and responsibilities;
• manual workarounds; and
• operational constraints.

The current environment may contain multiple ways of accessing services, fragmented workflows, manual handoffs, legacy applications, and disconnected processes.

These characteristics aren’t necessarily problems individually.

The architecture question is whether they prevent the organization from achieving its desired outcomes.

3. Define the Future State

The next step is to describe the desired future state.

A future state might seek:

• digital and integrated services;
• standardized processes where appropriate;
• improved customer visibility;
• streamlined workflows;
• greater self-service;
• end-to-end visibility; and
• integrated service delivery.

The purpose isn’t to assume that every existing component should be replaced.

Instead, the architecture asks:

What capabilities and architectural components are required to achieve the future state?

4. Identify Opportunities, Gaps and Solutions

Once the current and future states are understood, the gap between them becomes an architecture problem.

What can be retained?

What needs to change?

Where are the dependencies?

Where are there opportunities for consolidation or simplification?

What new capabilities are required?

This is where concepts such as Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs) can become useful.

The architecture can describe what capability or architectural outcome is required, while solution design can address how that requirement will actually be implemented.

5. Design the Transition

A transformation rarely moves directly from today’s environment to the ultimate future state.

There may be multiple transition states.

Current State → Transition State → Transition State → Future State

Each transition can introduce its own:

• scope;
• dependencies;
• migration activities;
• integrations;
• testing;
• risks; and
• operational requirements.

This is particularly important when legacy systems cannot simply be switched off.

Data migration is one part of the transition, but migration can also involve processes, applications, integrations, roles, and operating practices.

6. Govern Implementation

Architecture shouldn’t stop when implementation begins.

The implementation phase creates new decisions:

• Does the proposed solution remain aligned with the target architecture?
• Has a requirement changed?
• Does a proposed change create a new dependency?
• Is an architecture exception required?
• Has implementation exposed a gap that wasn’t previously understood?

This is where Architecture Governance connects architecture with project and delivery governance.

The purpose isn’t to prevent change.

It is to make architectural change visible, deliberate, and governed.

7. Connect the Transformation to Operations

A project eventually becomes a service.

That transition is easy to overlook.

Once a new digital service is operational, the organization has to manage:

• incidents;
• service requests;
• defects;
• changes;
• access;
• new features;
• onboarding and offboarding; and
• continuous improvement.

This creates an important connection between enterprise architecture and IT Service Management (ITSM).

Architecture should consider not only:

Can we implement this?

but also:

Can we operate, support, govern, and evolve it?

8. Measure the Outcome

Ultimately, architecture isn’t the outcome.

The business outcome is.

For a digital service transformation, outcomes might be considered across three areas:

Service

• application status;
• online transactions;
• easier access to services;
• increased self-service.

Customer

• transparency;
• service experience;
• simpler interactions.

Operations

• productivity;
• reduced rework;
• service levels;
• improved visibility.

The architecture provides the structure for connecting those outcomes to the underlying business and technology changes.

The ADM as a Practical Thinking Framework

The TOGAF ADM can therefore be useful without treating it as a rigid checklist.

At a high level:

Understand the organization and context

↓

Establish the Architecture Vision

↓

Define Business Architecture

↓

Define Data / Information and Application Architecture

↓

Define Technology Architecture

↓

Identify Opportunities & Solutions

↓

Plan Migration

↓

Govern Implementation

↓

Manage Architecture Change

The real-world process is iterative. New information discovered during implementation can require the architecture to be revisited. Business priorities can change. Technology constraints can emerge. Stakeholders can identify requirements that weren’t visible initially.

That’s not a failure of the architecture process.

That’s the reason for architecture governance and change management.

From Strategy to Delivery

The practical value of the ADM is that it creates a chain of reasoning between strategic intent and implementation:

Business outcomes

→ Capabilities

→ Processes

→ Information

→ Applications

→ Integration

→ Technology

→ Implementation

→ Operations

→ Continuous improvement

That is the part of TOGAF/ADM I find most useful in a project environment.

It provides a way to look beyond the individual application and understand the system of capabilities, processes, information, technology, and people that has to work together for the transformation to deliver its intended outcome.

TOGAF ADM Tookit

Practical application of the Architecture Development Method –

For a more detailed example, I developed a TOGAF ADM toolkit that applies the ADM phases to a generic digital transformation scenario. The toolkit walks through the ADM in greater detail, using a service-transformation example to illustrate how architecture concepts can be translated into practical project and delivery activities.

The toolkit is intended as a practical working example rather than a prescriptive implementation methodology.

TOGAF® is a registered trademark of The Open Group. This article uses TOGAF/ADM concepts for educational and practical discussion and does not represent an official TOGAF publication or certification material.