Business Architecture - Making Business Connectable to Technology

About this article

As the second installment of the “Enterprise Architecture” category in the series “Architecture Crash Course for the Generative-AI Era,” this article explains Business Architecture (BA).

The top layer of EA, taking business itself - “what / who / how to do” - as the design target. With unclear BA, DA/AA/TA lose their purpose - BA is the starting point of all technical decisions. This article handles capability maps, value chains, business processes (BPMN), org models, and connecting strategy to operations - design that bridges word gaps between tech and business.

What is Business Architecture in the first place

Picture a company’s business plan. Without writing “to whom, what, and how to deliver,” each department can only act on its own judgment, and company-wide direction falls apart.

Business Architecture (BA) is the top layer of EA, the domain of taking business itself as the design target. It structures capability maps, value chains, business processes, and other aspects of “what, who, and how to do.”

Without BA, the tech department ends up building systems without understanding business objectives. Means become ends, and unused systems get mass-produced.

Why BA is needed

Bridging word gaps between tech and business

To avoid the confusion of purpose and means like business saying “we want to strengthen customer touchpoints” and tech replying “we’ll deploy CRM,” a common model is needed.

Cross-org system alignment

Departments independently investing in systems causes duplication, contradictions, and integration impossibility. BA describing the whole picture avoids investment duplication.

Visualizing the impact range of transformation

New businesses, M&A, withdrawals - without BA, you can’t trace which systems / operations such business changes affect.

Main BA components

BA models business from multiple perspectives. Emphases vary by industry and company, but the following are general components.

Element	Content
Business strategy	Vision, goals, KPI (Key Performance Indicator)
Business capabilities	”What can be done” abilities
Value stream	Flow producing value
Business processes	Operational procedures
Organization	Departments, roles, responsibilities
Stakeholders	Customers, business partners, regulators
Business services	Catalog of services provided

Business capabilities

What organized what a company can do is business capabilities. “Customer acquisition,” “order processing,” “inventory management,” “accounting” - the feature is organizing by capability units rather than organization. Even with org changes, capabilities don’t easily change, so they’re used as EA’s stable axis.

flowchart TB
    RETAIL([Retail])
    CUST[Customer mgmt]
    PROD[Product mgmt]
    SALE[Sales]
    C1[Customer acquisition]
    C2[Customer retention]
    C3[Customer support]
    P1[Product planning]
    P2[Inventory mgmt]
    P3[Pricing mgmt]
    S1[Store sales]
    S2[E-commerce]
    S3[B2B sales]
    RETAIL --> CUST --> C1
    CUST --> C2
    CUST --> C3
    RETAIL --> PROD --> P1
    PROD --> P2
    PROD --> P3
    RETAIL --> SALE --> S1
    SALE --> S2
    SALE --> S3
    classDef root fill:#fef3c7,stroke:#d97706,stroke-width:2px;
    classDef l1 fill:#dbeafe,stroke:#2563eb;
    classDef l2 fill:#dcfce7,stroke:#16a34a;
    class RETAIL root;
    class CUST,PROD,SALE l1;
    class C1,C2,C3,P1,P2,P3,S1,S2,S3 l2;

The example here is retail, but capability granularity and classification axes change with industry. In finance, “risk management,” “compliance,” and “credit screening” appear as independent large-grain capabilities, with regulatory response itself becoming a value source. In manufacturing, “supply chain,” “production planning,” and “quality management” are the main axes, with hierarchy organized around physical-goods flow. In SaaS companies, “customer acquisition (marketing / sales)” and “product development” become large-grain pillars, and “inventory management” like in retail is mostly unneeded. If your industry already has organized reference models (BIAN for banking-industry capability standards, eTOM for telecom-industry process standards), starting from there greatly reduces granularity-adjustment effort.

Stop the capability map at 2-3 tiers practically. Going deeper makes it unmaintainable.

Value stream

What depicts the flow of activities producing customer value is the value stream. Like “order receipt → payment → delivery → after-support,” organize a sequence of activities from customer perspective. If business capabilities are “what can be done,” value streams are how customer value is realized.

Use case	Content
Operations improvement	Where the bottleneck is
Digitization	Where to automate
Customer experience	Identifying touchpoints
System investment	Priority judgment

A concept also used in Lean / DevOps, applicable beyond IT to manufacturing and logistics.

Business processes

Concrete operational steps and procedures. More detailed than value streams, depicting who actually does what. BPMN (Business Process Model and Notation) is the standard notation, written in flowchart form.

Notation	Characteristics
BPMN 2.0	Industry standard, many tools
UML activity diagram	Dev-leaning
Flowchart	Lightweight, simple
DFD	Data-flow centric

Realistic to layer processes when drawing. Splitting into L1 (overview), L2 (mid), L3 (detail) lets management and field discuss on the same diagram.

Organization and governance

BA also models org structures. Without clarifying who’s responsible for which operations / which systems, transformation falls into the state of not knowing whom to ask.

Element	Content
Org chart	Departments, hierarchy
Roles and responsibilities (RACI)	Responsible / Accountable / Consulted / Informed
Decision authority	Approval lines, amount criteria
Governance committee	Architecture committee etc.

The RACI matrix especially matters, clarifying “who executes, who’s ultimately responsible, who’s consulted, who’s informed.”

Stakeholder map

Visualization of relevant parties. Identify all entities involved in the business (customers, employees, partners, shareholders, regulators, community), organizing what each demands. This becomes the source of requirements.

Stakeholder	Typical concerns
Customers	Quality, price, experience
Employees	Workability, salary, growth
Partners	Trade conditions, payments
Shareholders	Profitability, growth
Regulators	Legal compliance, safety
Society / community	ESG (Environment / Social / Governance), employment

BA’s relationship with lower layers

BA becomes the basis for the lower layers of data, app, and technology. Being able to explain “why it’s needed” from BA to lower layers is the correct shape of EA.

[Business Architecture (BA)]
   - Customer-acquisition capability
         |
         v needed data
[Data Architecture (DA)]
   - Customer master, behavior data
         |
         v processing app
[Application Architecture (AA)]
   - CRM, MA system
         |
         v running infrastructure
[Technology Architecture (TA)]
   - Cloud, DB, servers

Designing only the lower layers produces tech-convenient systems generating no business value.

When asked by management “this system - why does it exist?” and dev members and business departments stammer - this scene often happens in the field. Mountains of design docs and table definitions exist, but the layer above is missing. Conversely, in orgs where BA lives, the same question gets answered in 1 line: “because it’s the core of customer-acquisition capability.” Whether BA exists is shown in this 3-second response - a suggestive episode.

BA modeling techniques

Multiple techniques express BA - use per use case. Beyond just drawing, the important thing is being a form discussable with stakeholders.

Technique	Use case
Capability map	Whole picture of capabilities
Value-stream map	Flow of value creation
BPMN	Process detail
ArchiMate	EA-integrated modeling language
Business model canvas	Business model

Capability-Based Planning

The representative analysis technique using BA is Capability Based Planning (CBP). Visualize which capabilities are strengths and where weak as a heatmap, deciding investment priorities.

State	Color
Strategic advantage	Green
Competitor parity	Yellow
Inferior	Red
Unneeded	Gray

Concentrated investment on red capabilities, maintain green, reduce gray - visualization of strategic decisions. Extremely effective for management-meeting communication.

Decision criterion 1: company scale

BA detail varies by company scale. Detailed BA at small companies is excessive, with operations not keeping up.

Scale	Recommended
Startup (~50)	Business model canvas level
Small (~500)	Capability map + main processes
Mid-size (~5000)	Full-fledged BA + EA team
Large (5000+)	Full EA + dedicated org

Decision criterion 2: transformation phase

BA setup is most needed in transformation periods. More realistic to align setup with transformation opportunities than to spend time on BA in calm periods.

Transformation phase	BA’s role
Steady operation	Minimum maintenance
DX promotion	Create AS-IS BA, design TO-BE
M&A	Integrate both companies’ BAs
Business reorg	Re-allocate capabilities

How to choose by case

Startup / 50-person scale

Maintain lightly with Business Model Canvas (Strategyzer) + Miro. BA-dedicated person unneeded, founders / PdMs review quarterly. Full BA is over-investment, with the ideal being a state usable for strategy discussion via 1 canvas.

Small enterprise / DX in progress

Capability map at 2 tiers + main 3-5 processes BPMN-ized. Detail only digitization-target operational flows, others remain rough. Create with IT / business joint workshops, share via Miro / Lucidchart.

Mid-size enterprise / has EA org

Operate update process with ArchiMate + Confluence or Sparx EA. EA team of 3-5 manages company-wide BA, doing investment decisions via quarterly review and Capability-Based Planning. Also leverage for integration analysis at M&A / business reorg.

Large enterprise / regulated industries

Build with Full EA (TOGAF-compliant) + dedicated EA org + AI-supporting models. Publish ArchiMate models via API, having LLMs reference BA to auto-impact-analysis. Also manage stakeholder maps as structured data, having governance committee approve changes.

Phased BA-construction roadmap

BA breaks down with “sudden full construction,” so phased investment matched to scale is realistic.

Phase	Period	Output	Investment people
1. Startup	1 day-1 week	1-page Business Model Canvas	Founder concurrent
2. Small DX promotion	1-3 months	2-tier capability map + main 3-5 process BPMN	0.5-1
3. Mid-size enterprise	~1 year	Full capability map + RACI + stakeholder map	EA team 3-5
4. Large enterprise	Continuous	Full ArchiMate model + quarterly review + CBP	Dedicated EA org 10+
5. Regulated industries	Continuous	Full + industry-specific (BIAN etc.) + audit response	Central EA + business-unit EA

The practical iron rule is stopping capability map at 2-3 tiers. 4+ tiers are unmaintainable, becoming pie in the sky. The biggest criterion is granularity used in decisions, prioritizing “whether management and field can discuss on the same map” over detail.

Stop BA at “granularity that gets used.” The more elaborately built, the less it gets operated.

BA-operation pitfalls and forbidden moves

Typical accidents in BA construction. All produce the result of drawing and done, BAs not used.

Forbidden move	Why it’s bad
Make capability map at 4+ tier detail	Unmaintainable, neglected / outdated in 3 years
Throw BA to consultants	Diverges from tech decisions, unusable BA produced
Misunderstand BA = org chart and operational flow	Capabilities, value streams, and strategy missing
Hand-drawn diagrams only in PowerPoint / Word	AI-unparseable, no API-linkable, stays static material
Make once and abandon BA	Doesn’t follow business changes, full rewrite in 3 years
Build IT-only without business involvement	Diverges from operational reality, ignored by field
Split capabilities by org name	BA collapses on org change, stable axis by capability units
Don’t link numbers (KPIs) to BA	Just qualitative, neither AI nor humans can use for decisions
Don’t make BA at new businesses, start with requirements definition	Mid-size manufacturing’s “8-month new-subscription stagnation” pattern
Build from scratch without “reference models” (BIAN etc.)	Ignoring industry-knowledge accumulation, wasted effort
Believe “more detail = more value”	Opposite. Without granularity used in decisions, it becomes paper-only. If used, even rough is fine

Amazon’s “Working Backwards” (the culture of writing press releases first when considering new services) is widely known as a BA-philosophy success case. Visualizing business structure first let them keep producing wholly different businesses like AWS, Prime, and Alexa with the same thinking - acquiring organizational power.

BA exists not for drawing diagrams but for speeding org decisions.

What to decide - what is your project’s answer?

For each of the following, try to articulate your project’s answer in 1-2 sentences. Starting work with these vague always invites later questions like “why did we decide this again?”

• Capability map (creation scope, tiers)
• Value stream (flow of customer value)
• Important business processes (BPMN-ization targets)
• RACI matrix (roles and responsibilities)
• Stakeholder map (identifying relevant parties)
• Modeling tool (ArchiMate / Miro etc.)
• Update process (who and when reviews)

Author’s note - “BA absence” that stopped a new business for 8 months

Cases showing how heavy decision-making cost BA absence generates are widely told from mid-size to large enterprises.

A DX project of “launching a new subscription business” started at a mid-size manufacturer, and proceeded to requirements definition without capability map or value stream, with the result that the discussion of “use existing order-management system or introduce new SaaS” couldn’t settle for over 6 months, the project stagnated 8 months - often reported. With BA, the discussion that could have been organized in 1 line “this is a new establishment of ‘customer-retention’ capability, separate system from existing ‘order processing’” returned to scratch every time it crossed orgs - typical damage from BA absence.

Conversely, Amazon’s “Working Backwards” culture is told as a BA-philosophy success case. When considering new services, writing press releases first (customer-perspective value stream) and then dropping to capabilities and system architecture - by enforcing this discipline company-wide, they acquired organizational power producing wholly different businesses like AWS, Prime, and Alexa with the same thinking.

Both cases reverse-show the value of “first visualizing business structure.” BAs slap home that they exist not for drawing diagrams but for speeding org decisions.

How to make the final call

The core of BA is the thinking of visualizing business in a form connectable to technology. Without BA, “this system - why does it exist?” can’t be answered, and tech-convenient systems get mass-produced. The correct EA shape integrally models business strategy, capabilities, value streams, processes, and org, functioning as the basis for data, app, and technology layer decisions. Capabilities are stable axes that don’t easily change with org changes - the rule is stopping at 2-3 tiers and maintaining practicality. Value is decided by being “granularity used in decisions,” not detail.

Another decisive axis is the demand for AI-readable BA. In the era when LLMs and AI agents propose management strategy and operational improvements, BAs buried in PowerPoint / Excel don’t function. Only companies creating an API-referenceable state with structured models like ArchiMate, quantifying capabilities, and having continuous-update habits can hold competitiveness even in AI usage.

AI decision axes

When AI-driven development (vibe coding) and AI usage are the premise, BA is redefined as teaching material for AI to understand the business. In the era when LLM (Large Language Model) and AI agents propose management strategy and operational improvements, machine-readable BA becomes the source of competitiveness.

AI-era favorable	AI-era unfavorable
Structured BA (ArchiMate etc.)	Hand-drawn diagrams / PowerPoint
Quantified capabilities	Qualitative descriptions only
API-referenceable models	Excel-buried data
Continuous-update habits	Abandoned for 3 years

For AI to analyze the business, BA in a format AI can read is required. The era of “hand our capability map to AI for analysis” has arrived.

AI-era BA must be machine-readable and continuously updated. Paper diagrams can’t compete.

Selection priorities

1. Capability map as stable axis - resilient to org changes, stop at 2-3 tiers
2. Adjust detail per scale - canvas for startups, full EA for large enterprises, no over-investment
3. Build precisely in transformation periods - align with DX / M&A / business-reorg opportunities
4. Maintain in machine-readable form - continuous updates via ArchiMate + API publication, as AI teaching material

“Visualize business structure and have AI read too.” BA is the starting point of all tech decisions.

Summary

This article covered Business Architecture, including capabilities, value streams, BPMN, RACI, stakeholders, ArchiMate, and AI-era machine-readable BA.

Capability as stable axis stop at 2-3 tiers, adjust detail per scale, build in transformation periods, maintain in machine-readable form. That is the practical answer for BA design in 2026.

Next time we’ll cover Data Architecture (DA) (company-wide data strategy, MDM, data catalog).

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.