How BA, DA, AA, and TA Interlock: A Practical Guide to Enterprise Architecture

Business Architecture (BA) is a cross‑system blueprint that connects strategy to solutions, while Application Architecture (AA), Data Architecture (DA) and Technology Architecture (TA) address different aspects of the solution.

Key Acronyms

BA : Business Architecture

DA : Data Architecture

AA : Applications Architecture

TA : Technology Architecture

Strategic‑BA‑DA‑AA‑TA Relationship

The five elements form three hierarchical layers:

Company strategy (top layer) Business architecture (middle layer) Solution architecture (bottom layer)

Core relationships:

Strategy is defined by senior management and drives BA requirements. BA translates strategy into a detailed blueprint, which becomes the input for DA, AA and TA. DA, AA and TA design their artifacts based on the business processes defined in BA. Each lower layer supports the one above it, creating a closed loop.

Roles and Deliverables

Strategic planning is led by the company’s senior management, supported by a planning department that monitors industry policies, macro‑environment changes, and competitor moves.

The business architect designs and documents the business architecture (often called a "Business Architecture Book" or "Business Requirements Document").

Solution architects – data, application and technology architects – then create detailed solution designs based on the BA outputs.

Three‑Level Framework

Strategic layer Business architecture layer Solution architecture layer

Practical Work Content of BA, DA, AA, TA

After defining the strategic drivers, the business architect analyses organizational structure, business functions, and processes (the classic "who, what, how" trio) and adds business models and data to the blueprint.

Data architects focus on data types, sources, and flows; application architects map business functions to application services; technology architects identify technical requirements, select platforms, middleware, and design deployment and load‑balancing.

From Strategy to Architecture to Implementation

Key steps:

Strategic planning – output: strategic plan document.

Business architecture – output: Business Architecture Book.

Solution architecture – output: Technical Solution Document.

Architecture roadmap – budget‑driven, approved by the board.

Implementation planning – led by the CIO.

Project governance – R&D projects managed by PMO, purchased solutions by the General Manager’s office.

Case Study: Stock Purchase Process

The example demonstrates how a business process flows through the four architectures.

1. Business Architecture

Business function: "Buy Stock".

Business process: order placement, rule check, exchange reporting, result handling.

Business data: purchase order instruction.

Business events: exchange feedback triggers downstream processing.

2. Application Architecture

Required application services include order entry, rule validation, order submission, result reception, and result display, implemented by a broker app and a centralized trading system.

3. Data Architecture

Backend trading system queues orders for asynchronous processing.

Investor account data is stored in the brokerage backend for rule checks.

Trade result records are persisted for later processing.

4. Technology Architecture

Client‑side components support order entry and result display.

Rule checking, order submission and result handling are implemented as reusable services or micro‑services.

Infrastructure choices (servers, networks, middleware) are defined by the technology architect.

Summary

Positive logic: strategy determines business, business determines technology. Reverse logic: technology enables business, business supports strategy.