Business Architecture
The practice of stating what a business does and who decides it - so technical investment can be sequenced and measured against the business's own structure rather than against the system inventory.
A two-year programme replaces an order-management system and ships on time. Eighteen months later nobody can say whether the business got anything: the case was written in the language of systems — "retire four applications" — while the business is run in the language of capabilities, margins and markets. The programme had a delivery plan and no way to be judged.
Business architecture is the practice that supplies the missing frame: a description of the business's capabilities, value streams, decision rights and external constraints that is stable enough to plan against and specific enough to argue with. It is not an org chart or a layer above technical architecture; it is what makes a technical decision arguable in the business's own currency.
Why it matters
Architects lose arguments for one reason: they bring a structure nobody else in the room is accountable for. A capability model changes that, because a capability has an owner, a cost, a maturity and a revenue line, and those four attributes let a boundary proposal be compared with a feature proposal.
The second reason is sequencing. Across eight funded initiatives the dependencies are invisible from every seat except the architect's: 5 of 8 need the same entitlement capability, so one order delivers 6 of 8 by year end and another delivers 3.
Implementation patterns
- A capability model three levels deep and no deeper. Level 1 is roughly 8 to 12 capabilities, level 3 a few hundred. Deeper, and it becomes a process catalogue that is wrong within a quarter.
- Value-stream to capability cross-map. For each customer-visible outcome, list the capabilities it crosses. One crossing nine capabilities owned by seven teams is a lead-time finding, not a documentation exercise.
- Overlays chosen for a decision — cost, differentiation, maturity, change frequency. An overlay with no pending decision attached is where a capability map becomes a consulting artefact.
- Decision rights written down. Who approves a change to each capability's rules, which is what makes a boundary survive its first urgent change.
- A register of dated external constraints — regulatory dates, vendor end-of-maintenance dates, contract renewals — the only deadlines nobody can renegotiate.
Industry example
SAP's February 2020 announcement set mainstream maintenance for the core SAP Business Suite 7 applications to the end of 2027, with optional extended maintenance to the end of 2030 at a premium of 2 percentage points on the maintenance base, and committed S/4HANA maintenance to 2040. For a customer that is a business-architecture input rather than an IT one: the end date is fixed, so scope is the variable, and the premium is the published price of three more years of decision time. Those who handled it well inventoried their customisations first: the work is the modifications, not the platform move.
Failure scenarios
- The map derived from the system inventory, which confirms the current implementation and cannot show that the business needs something it is not organised to do today.
- The model with no owners, quoted in strategy decks while funding decisions contradict it.
- A programme measured on delivery, closing as a success while run cost stays flat and the saving never reaches any ledger.
Trade-offs
| Choose business architecture when | Gains | Pays |
|---|---|---|
| Investment is contested across more than about five teams | A shared structure for sequencing and for measuring outcomes | Weeks of senior time and a model that needs maintaining |
| A dated external constraint exists | Scope becomes negotiable against a fixed date | Discovery that produces no feature |
The model costs 4 to 8 weeks of senior time to build and about 1 day a month to keep, and returns nothing unless a decision is taken from it in the first quarter.
When not to use it
In a company of 30 people with one product, the org chart is the capability map and the founders hold the decision rights in their heads; a formal model answers a question nobody is asking. The same applies to a single-team system however complex: use a domain model. The threshold is contested investment across teams, not company size: two teams arguing over who owns pricing rules need this; 200 engineers on one product with one owner do not.
Interview question
Q: You are the first architect in a 400-person company that funds work as annual projects. The CTO asks for a target-state architecture this quarter. What do you produce instead, and how do you prove in six months it was worth doing?
What a strong answer covers: a refusal to draw a target state before the capability and decision-rights picture exists; a three-level model with owners and a cost overlay; the value-stream cross-map that exposes lead time; the dated constraint register; and an outcome measured at six months — a sequencing decision taken from the model, with a benefit checkpoint rather than a claim that the model is "being used".
Quick check
Quiz: What makes a capability map an investment tool rather than documentation? Owners, costs and differentiation ratings on every capability, plus an open decision being taken from it.
Flashcard: What does business architecture give an architect that a system inventory cannot? A structure the business is accountable for — capabilities with owners, costs and decision rights — so a boundary proposal competes with a feature proposal in one currency.