Business Architecture: Connecting Business 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

It bridges the gap in vocabulary between technology and the 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.

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

It makes the blast radius of a transformation visible. 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.

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.

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 streams and business processes

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.

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

Business processes are the level below the value stream.

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

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

Organisation and governance decide who owns each of them.

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.

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

The stakeholder map is what keeps that ownership honest.

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.

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.

How BA is modelled matters as much as what it contains.

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

Capability-Based Planning is where that model turns into investment decisions.

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.

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

How heavy the BA work should be depends on two things — first, company scale.

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

Second, which phase of transformation you are in.

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.

By case, the emphasis lands like this.

A startup at around fifty people. 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.

A small enterprise with DX under way. 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.

A mid-size enterprise with an EA function. 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.

A large enterprise in a regulated industry. 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.

A phased roadmap for building BA

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

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.

AI decision axes — A machine-readable BA becomes a competitive advantage

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 and AI agents propose management strategy and operational improvements, machine-readable BA becomes the source of competitiveness.

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.

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

Feeding BA information to AI for management analysis

When capability maps and business-flow diagrams are managed in structured formats like ArchiMate, they can be fed to AI for analyses like “where are the bottlenecks in this business” or “which capabilities overlap post-M&A.” Hand-drawn PowerPoint diagrams can’t be structurally understood by AI, so they can’t serve as analysis targets.

Quantifying value streams for AI prediction

When each step of a value stream (the sequence of processes producing customer value) is tagged with lead time, cost, and error rate numbers, AI can quantitatively analyze “where would improvement have the most effect.” With only qualitative descriptions, AI can’t judge improvement-proposal priority.

Pitfalls and forbidden moves

Here are the six most dangerous of the typical ways building a BA goes wrong. Every one of them ends in a BA that was drawn once and never used.

The belief that “the more detailed, the more valuable” is wrong too. At a granularity that is not used in decisions it is just paper; if it is used, coarse is fine. Building from zero without drawing on reference models such as BIAN is likewise wasted effort that ignores the accumulated knowledge of the industry.

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.

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)

When it comes to the final call, the order is this.

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.

Related Articles

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.