Day 29: Mapping Enterprise Architecture’s Four Domains & TOGAF ADM from Business Goals to Migration Roadmap

Why Architecture Starts with Business Goals

When a company wants a unified platform, architects cannot immediately suggest micro‑services, Kafka, Redis, or a cloud stack; those are merely possible technologies. The design process must first answer what the business wants to change, which data need unification, how applications should be divided, and only then select supporting technologies.

Knowledge Shelf for the Week

Business Architecture, Data Architecture, Application Architecture, Technology Architecture;</code><code>Baseline Architecture, Target Architecture, Gap Analysis, Migration Roadmap;</code><code>TOGAF ADM phases B, C, D;</code><code>Two groups of “four” that are easy to confuse.

Case: Retail Chain with 300 Stores

The company has built separate POS, online shop, membership, warehouse, procurement, and finance systems. Although each works in isolation, the enterprise faces problems such as inconsistent member IDs, inventory mismatches, lack of cross‑store returns, duplicated master data, point‑to‑point interfaces, and no unified view for management.

These issues span four concerns:

How business processes must change;

How enterprise data should be unified;

How application responsibilities need re‑allocation;

How underlying technology must support the above.

What Enterprise Architecture Is

Enterprise architecture starts from strategy and business goals, plans business, data, application, and technology in a unified way, aligns IT construction with business objectives, and defines a transformation route from the current state to the target state.

It solves five questions:

1. Where is the enterprise heading?</code><code>2. How must business capabilities and processes change?</code><code>3. How do data and applications support those changes?</code><code>4. Does technology investment truly serve business goals?</code><code>5. How to migrate from the current architecture to the target architecture?

Enterprise architecture is not a server deployment diagram, a product purchase list, a class diagram of a single system, or a slogan like “everything should be micro‑services”.

Business‑IT Alignment

Alignment is not “business writes requirements, IT implements them”. True alignment means every IT capability can be traced to a specific business goal, and every important business goal has corresponding data, application, and technology capabilities.

Example: “Customers can order, pick up, and return across any channel”. This translates to:

Business: redesign omnichannel order, fulfillment, and after‑sale processes;</code><code>Data: unify member, product, order, and inventory definitions;</code><code>Application: clarify responsibilities of mall, POS, OMS, WMS, CRM;</code><code>Technology: provide stable APIs, reliable messaging, high‑availability, and monitoring.

Business Architecture

Focuses on how the enterprise operates, not on servers. It describes strategy, goals, organization, roles, capabilities, processes, services, rules, and objects. In the retail case, it must answer whether omnichannel sales capability is needed, how cross‑store ordering works, who owns inventory commitment, and what process changes occur.

Artifacts may include capability maps, process diagrams, role matrices, and service catalogs.

Data Architecture

Addresses core data entities, relationships, ownership, standards, exchange formats, flow, sharing, archiving, quality, security, and lifecycle. Core entities for the retailer include members, products, stores, suppliers, orders, inventory, pricing, and promotions.

Typical designs:

• Unified member identifier;</code><code>• Master data for products and suppliers;</code><code>• Consistent inventory calculation and update source;</code><code>• Standard exchange formats for orders and inventory events;</code><code>• Defined data owners and quality rules.

Data architecture is broader than a database schema; it governs enterprise‑wide data assets.

Application Architecture

Defines which applications are needed, their business capabilities, overlapping functions, missing capabilities, interaction patterns, and mapping to processes and data.

Typical retail split:

• Mall – online browsing, cart, order entry;</code><code>• POS – in‑store sales and checkout;</code><code>• CRM – member and customer operations;</code><code>• OMS – unified order management and routing;</code><code>• WMS – warehouse operations;</code><code>• Inventory Service – unified inventory query and commitment;</code><code>• Finance – settlement and accounting.

Interaction example:

Mall and POS send orders to OMS;</code><code>OMS queries unified inventory and selects fulfillment location;</code><code>Order‑completion events notify CRM, inventory service, and finance;</code><code>All applications consume a single member master record.

Application architecture is not code structure; it concerns system boundaries, responsibilities, and integration.

Technology Architecture

Provides the runtime foundation for business, data, and application layers: compute platforms, OS, networking, databases, middleware, containers, identity, security, monitoring, backup, and disaster recovery.

For the retailer, it may include unified network and cloud resources, API gateways, reliable messaging platforms, high‑availability databases, centralized authentication, logging, monitoring, and a release pipeline.

Technology decisions must be driven by the needs identified in the three upper layers.

Four Domains Inter‑Relation

Business Goal</code><code> ↓</code><code>Business Architecture</code><code> ↓</code><code>Data Architecture ↔ Application Architecture</code><code> ↓</code><code>Technology Architecture

Data and application domains are linked because applications produce and consume data, and data ownership influences application boundaries.

Baseline, Target, Gap, and Roadmap

Baseline (As‑Is) describes the current state: fragmented member IDs, separate inventory stores, many point‑to‑point interfaces.

Target (To‑Be) describes the desired state: unified omnichannel processes, standardized member/product/inventory data, clear application responsibilities with stable interfaces, and a technology platform that supports integration, high‑availability, and monitoring.

Gap Analysis compares baseline and target, identifying missing capabilities, new additions, modifications, and which existing assets can be retained, integrated, or retired.

Migration Roadmap translates gaps into phased projects, considering priority, dependencies, cost, and risk. Example phases:

Unify member, product, and store codes.

Build unified order and inventory services.

Gradually refactor mall and POS to use the new services.

Validate and decommission duplicate functions and old interfaces.

Establish governance and continuous measurement.

By comparing baseline and target architectures, performing gap analysis, and planning a staged migration, enterprises can move from a chaotic system landscape to an aligned, future‑ready state.

TOGAF ADM Overview

TOGAF (The Open Group Architecture Framework) is an open enterprise‑architecture framework. Its core method is the Architecture Development Method (ADM).

Key ADM phases relevant here:

A – Architecture Vision;</code><code>B – Business Architecture;</code><code>C – Information Systems Architecture (Data + Application);</code><code>D – Technology Architecture;</code><code>E – Opportunities & Solutions;</code><code>F – Migration Planning;</code><code>G – Implementation Governance;</code><code>H – Architecture Change Management.

Requirement management sits at the center of the ADM cycle, ensuring that every phase continuously captures, validates, and updates requirements as business, data, application, or technology designs evolve.

Two Sets of “Four” to Distinguish

TOGAF’s four architecture domains: Business, Data, Application, Technology (ADM B/C/D).

The textbook’s “Enterprise Information System Overall Framework” also lists four components: Strategic System, Business System, Application System, Enterprise Information Infrastructure, which map to three management layers (strategic, tactical, operational). These two “four‑sets” are not interchangeable.

Sample Exam Question and Answer

Given a retail chain’s omnichannel transformation, classify the following tasks:

A – Re‑engineer cross‑channel ordering, pickup, and returns → Business Architecture;</code><code>B – Standardize member, product, order, inventory codes and owners → Data Architecture;</code><code>C – Define responsibilities and interfaces of mall, POS, OMS, WMS, CRM → Application Architecture;</code><code>D – Build unified authentication, messaging, HA database, monitoring, disaster‑recovery → Technology Architecture.

Why not start with D? Because technology must support the already‑defined business, data, and application needs; designing tech first risks misalignment, duplication, or over‑design.

Baseline‑to‑Target example for the point‑to‑point interface problem:

Baseline: many point‑to‑point interfaces, complex dependencies;</code><code>Target: clear application responsibilities, stable service interfaces, unified identity and data standards;</code><code>Gap: missing interface standards, event mechanisms, governance; existing point‑to‑point links need refactoring;</code><code>Roadmap: define business boundaries and data standards, build common integration capabilities, batch‑wise interface refactor, dual‑track validation, then retire old interfaces.

Key Takeaways for Exams

When you see terms like “capability”, “process”, “role” → think Business Architecture.

“Entity”, “master data”, “coding”, “quality” → Data Architecture.

“System responsibilities”, “boundary”, “interface” → Application Architecture.

“Hardware”, “network”, “DB”, “middleware”, “security” → Technology Architecture.

Remember the four‑domain diagram and the baseline‑target‑gap‑roadmap flow.

Distinguish the two “four” groups; they belong to different classification perspectives.

In summary, enterprise architecture starts from business goals, aligns the four domains, performs rigorous baseline‑to‑target analysis, and delivers a phased migration plan, all while iterating through TOGAF’s ADM cycles and keeping requirements under continuous management.