Enterprise Architecture with the TOGAF 10 Standard

Enterprise Architecture should be approached as a business transformation discipline, rather than simply a technology documentation exercise.

The TOGAF® Standard, 10th Edition provides a structured framework for developing and governing Enterprise Architecture. At the center of the framework is the Architecture Development Method (ADM), which provides an iterative lifecycle for moving from business drivers and architectural vision through architecture definition, implementation governance, and ongoing change.

TOGAF does not replace business judgment or architectural expertise. Instead, it provides a disciplined structure for connecting business strategy, capabilities, architecture, transformation, and governance.

Starting with Business Strategy​

The process begins with understanding the organization's business strategy, strategic objectives, operating model, regulatory constraints, and desired business outcomes.

TOGAF 10 provides the framework and ADM structure for Enterprise Architecture. The specific activities, techniques, deliverables, and sequencing should be tailored to the organization's context and architecture practice.

Within the TOGAF ADM, this business context is established through activities associated with the Preliminary Phase, Architecture Vision, and Business Architecture.

The Preliminary Phase establishes the organizational context for Enterprise Architecture, including architecture principles, governance, organizational capabilities, and the architecture framework being used.

The Architecture Vision then establishes the desired direction and creates alignment among stakeholders. It clarifies the business problem, desired outcomes, scope, stakeholders, and high-level architectural direction.

This creates an important principle:

Architecture should begin with the business problem, not with a technology solution.

Translating Strategy into Business Capabilities​

Strategic objectives are translated into business capabilities that describe what the organization needs to be able to do to achieve its strategic intent.

Capabilities provide a useful bridge between strategy and architecture because they focus on business outcomes and organizational ability, rather than prematurely prescribing applications or technologies.

Business capabilities can then be assessed to determine whether they are strategic, differentiating, or commodity, helping identify where architectural investment can create meaningful business value.

This aligns naturally with the TOGAF Business Architecture discipline, which connects strategic intent with business structures such as capabilities, organization, functions, and information needs.

Establishing the Current Architecture​

Once the business context and desired direction are understood, the baseline architecture must be established.

The TOGAF ADM develops architecture across the Business, Data, Application, and Technology Architecture domains, with Data and Application Architecture together constituting the Information Systems Architectures.

The baseline provides an understanding of how the enterprise operates today and establishes the foundation for identifying architectural gaps.

For the application portfolio, each application can be assessed based on business value, technical health, cost, risk, lifecycle, and strategic alignment.

This assessment provides the basis for determining whether applications should be:

Retained → Modernized → Replaced → Consolidated → Retired

The important distinction is that application decisions should emerge from business and architectural requirements, rather than from technology preferences alone.

Defining the Target Architecture​

With the baseline understood, the desired future state can be defined.

The target architecture describes how the enterprise should evolve to support its strategic objectives. It can encompass the Business, Data, Application, and Technology Architecture domains, with architecture principles, standards, requirements, and constraints providing the architectural guardrails.

The target state should therefore answer a fundamental question:

What architecture is required to enable the desired business capabilities and outcomes?

This prevents Enterprise Architecture from becoming a collection of disconnected technology diagrams.

Identifying Architectural Gaps​

The difference between the baseline and target architectures creates the architecture gap.

Gap analysis identifies what must change across business capabilities, applications, data, technology, integration, security, operating models, and other relevant architectural concerns.

The objective is not simply to document differences. The objective is to translate those differences into actionable transformation requirements.

From Architecture Gaps to Transformation Initiatives​

Architectural gaps are then translated into transformation initiatives.

These initiatives can include application modernization, platform transformation, data modernization, integration improvements, cloud adoption, capability development, operating-model changes, security improvements, or other changes required to reach the target state.

The initiatives should be evaluated based on factors such as:

• Business value
• Risk reduction
• Dependencies
• Complexity
• Investment capacity
• Organizational readiness
• Architectural feasibility

This is where architecture connects directly to portfolio and implementation planning.

The roadmap should not become a technology wish list. Every significant initiative should have a clear business outcome, architectural rationale, dependencies, and measurable success criteria.

Building the Transformation Roadmap​

The transformation initiatives are organized into a roadmap that describes how the enterprise moves from the baseline architecture toward the target architecture.

Rather than treating the target architecture as something that must be implemented in a single step, the roadmap establishes practical transition states and implementation increments.

The sequencing should consider:

Value → Risk → Dependencies → Complexity → Readiness → Investment Capacity

This creates a roadmap that is driven by transformation priorities rather than simply by the availability of technology projects.

Architecture Governance​

Architecture does not end when the target architecture and roadmap have been approved.

The architecture must remain governed throughout implementation.

TOGAF provides an architectural governance perspective that can be applied through mechanisms such as:

• Architecture Principles
• Reference Architectures
• Architecture Review Boards
• Architecture decisions and their associated decision records
• Compliance Reviews
• Exception Management
• Architecture Contracts
• Architecture KPIs

Governance ensures that implementation remains aligned with the approved architectural direction while providing a controlled mechanism for handling justified deviations.

The objective is not to create governance bureaucracy. It is to ensure that architectural decisions remain intentional, traceable, and aligned with business objectives.

Requirements and Continuous Change​

Requirements should not be treated as a one-time activity performed at the beginning of the architecture lifecycle.

Enterprise Architecture operates in a changing environment. Business strategy changes, regulations evolve, technology advances, customer expectations shift, and new risks emerge.

TOGAF therefore treats Requirements Management as a continuous activity across the ADM lifecycle.

New or changed requirements can trigger architectural reassessment, gap analysis, new initiatives, roadmap changes, or changes to the target architecture.

This creates a continuous feedback loop:

Requirements → Architecture → Implementation → Feedback → Updated Requirements → Architecture Evolution

Measuring Architectural and Business Outcomes​

Architecture is not complete when a set of diagrams has been produced or when a transformation roadmap has been approved.

Continuous measurement is required to determine whether the transformation is producing the intended results.

Relevant measures can include:

• Business outcome achievement
• Business capability maturity
• Technology risk
• Modernization progress
• Technical debt
• Architecture compliance
• Delivery effectiveness
• Cost optimization
• Operational performance

The emphasis should remain on measurable business and architectural outcomes, rather than simply measuring the number of architecture artifacts produced.

The Complete Enterprise Architecture Flow​

The resulting approach can be summarized as:

Within the TOGAF ADM, this flow is supported by the progression through the Preliminary Phase, Architecture Vision, Business Architecture, Information Systems Architectures, Technology Architecture, Opportunities & Solutions, Migration Planning, Implementation Governance, and Architecture Change Management, with Requirements Management operating continuously across the lifecycle.

The value of TOGAF is therefore not simply the production of architecture artifacts. Its greater value lies in providing a structured and repeatable way to connect strategic intent with architectural decisions, transformation investments, implementation governance, and continuous change.

Enterprise Architecture ultimately becomes the mechanism through which an organization can answer three fundamental questions:

Where are we today?

Where do we need to go?

How do we get there while maintaining architectural integrity and business alignment?