Business Architecture

In TOGAF this is the work of Phase B. The phase develops two pictures, the baseline of how the enterprise works today and the target of how it needs to work, and it names the business-layer gaps between them that matter to the change in hand.

The reason to do it well is the hold it gives over every later decision. When the business layer is explicit, the data, application, and technology phases that follow can be tested against real capabilities and outcomes; when it is skipped, those phases quietly optimise around the current systems instead. A national retailer reorganising fulfilment uses Phase B to say what it must become better at, not merely how its departments are drawn today.

Business architecture begins above the structure, in the strategy domain. It has three layers: the external vision, which is where the market is heading and what the enterprise believes; the strategic intent, which is the mission and the competences it needs; and the strategic priorities, which are the objectives and choices for this period. A grocery retailer might set a vision that weekly shopping moves online, an intent to be the easiest shop to reorder from, and a priority to win city families with same-day delivery.

The common mistake is to jump straight to capability maps and processes without writing the strategy down, so later work optimises around today's operation rather than tomorrow's intent. Capturing the strategy first gives everything downstream something concrete to be traced back to, which is what makes a business architecture defensible rather than decorative.

Before redrawing the operating machinery, it pays to be clear about the enterprise's value logic: who it serves, what it commits to, and how it sustains itself. A subscription streaming service and a public library both have one, and reading it first stops the work starting too low in the stack.

A business model is not enough on its own, and it is not only for commercial start-ups; a regulated body still has service commitments and a funding model that shape how change should be justified. Use it to frame why the enterprise works as it does, then move into capabilities, services, and value streams before any system is chosen.

An organisation map shows responsibility, accountability, and the handoffs between groups. Its value is not the chart itself but what the chart reveals: ownership gaps, duplicated authority, and the weak interfaces where work stalls. When a hospital blames delivery delays on its structure, a good map shows where the patient actually waits, at the handover between triage and diagnostics.

The common error is to treat the organisation chart as the business architecture. It is only one input into it. Read the map to explain why a capability or a value stream performs poorly, not to redraw management lines.

Between strategy and capability sits competence: the mechanism of related capabilities, knowledge, and skills that lets an enterprise realise its strategic intent. A courier whose intent is next-day delivery everywhere needs a competence in network optimisation, and that competence then shapes and sets the measure for the capabilities it builds, such as route planning and sortation.

Competence is easy to skip because it looks like another word for capability, but it does a different job: it says what the enterprise must be best at, and how good each supporting capability needs to be. Naming competences keeps the capability map honest, because each capability can be judged against the competence it serves rather than rated in the abstract.

A capability is a stable ability the enterprise needs in order to deliver value. It is named as a noun and it is independent of any team or system: "fulfil customer orders" is a capability, while the pick, pack, and ship process and the warehouse system that support it are not.

This is the distinction the whole stage turns on. The frequent mistake is to name a process step, a department, or a product as a capability, so that a CRM platform quietly becomes one. The test is simple: if the name sounds like a team or a tool, it is not a capability. A good one survives a change of system or a reorganisation, because it describes what the enterprise must be able to do, not how it happens to do it today.

A capability map earns its keep when it starts to drive decisions. Capability-based planning rates each capability by maturity and strategic importance, so the enterprise can see where to invest next rather than spreading effort evenly. An airline might find its loyalty capability both weak and strategically central, which settles the next investment.

The trap is the heatmap that changes nothing: colourful, well attended, and followed by no shift in funding, sequencing, or governance. Anchor each rating to evidence, and treat the assessment as worthwhile only when a real decision moves because of it.

A value stream traces the stages a stakeholder passes through to receive an outcome. Following an online order from request to doorstep shows where value is delayed or fragmented across team and system boundaries, which a system diagram alone would hide. This is the inside-out view: how the enterprise produces the outcome.

Its complement is the customer journey, the outside-in view of how the customer experiences getting it. A value stream can be efficient inside and still frustrate the customer outside, so the two are designed together. Keep the value stream at the level of value stages tied to an outcome, not a detailed process map, and let it point to the capability or the data that needs work.

Footprint thinking connects goals to the services and capabilities that deliver them, and attaches a measure to each. A university linking graduate outcomes to its teaching and careers services, each with a measure, can judge whether a proposed target is actually better than today rather than merely tidier on paper.

Measures are often added last, which leaves the target hard to defend. Bring them in early, so the business architecture stays something you can evaluate and the later roadmap has a concrete aim.

Each artefact so far has a job, but their power is in how they link. The connected model runs from strategic intent, expressed as a competence, which shapes a capability, which enables a value stream, which creates the value a stakeholder finally receives. Read in that order, the separate techniques become one model rather than a folder of unrelated diagrams.

Holding the chain in view changes how the work is judged. A capability with no competence behind it, or a value stream that creates no value for a named stakeholder, is a sign that something is missing or unnecessary. The model is the test of whether the business architecture actually hangs together.

Traceability is what lets a business architecture answer hard questions. Vertical traceability reads top to bottom, from strategy through competence and capability to the resources operations need, so any change can be traced back to the intent that justifies it. A bank cutting onboarding time can show exactly which capability, and which strategic priority, the change serves.

Horizontal traceability reads across business domains, showing strategic fit and the knock-on effects of a change in one area on another. Without traceability, a business architecture is a set of pictures; with it, the architecture can be assessed for impact, and a small change can be tested before it is made.

Gap analysis compares the baseline and the target to show what is missing, what changes, and what can be reused. In the business layer it surfaces two kinds of gap: structural ones, where a capability is simply absent, and performance ones, where a capability exists but is too slow or unreliable. A bank comparing its current and intended onboarding usually finds both.

A gap log on its own changes nothing. The gaps are grouped into a roadmap sequenced by dependency and value, and justified by a business case that sets the investment against the expected benefit. That is what turns the analysis into a defensible plan and a clear investment decision, and it becomes the direct input to the migration stage that follows.

Business architecture becomes theatre when it produces attractive maps and models that change no decision. The signs are familiar: capability maps with no planning consequence, value streams with no evidence behind them, and workshops that never tighten the scope.

The discipline that prevents it is a single test applied to every artefact: it should change a decision, reveal a dependency, or expose a governance issue. If it does none of those, the honest response is to stop producing it.