Business architecture

Why business architecture comes first

Engineering managers usually think about architecture in terms of systems. Business leaders think in terms of what the business needs to do. Business architecture connects the two, giving you a model of the business that is:

• Understandable to executives, who don’t care which database you use
• Stable enough to plan against for years
• Linkable to applications, data, teams, and investments

It’s also where many new EAs are weakest, so this module is worth extra time.

Business capabilities

A business capability is something the business does, or could do, to achieve its goals. It says nothing about who does it, how, or with what technology.

✓ A capability	✗ Not a capability
Payment Processing	The Payments Team (an organization unit)
Tenant Screening	The credit-check API (an application)
Contractor Management	“Assign job, notify contractor, confirm slot” (a process)
Owner Reporting	“Build a reporting dashboard” (a project)

Why capabilities are stable

A property manager has needed to collect rent and handle maintenance for as long as there have been rental homes. Who does it, what processes they follow, and which systems support it change all the time. Because capabilities change so little, they’re a good anchor for strategy, investment, and roadmaps.

Levels and naming

Capability maps are hierarchical:

• Level 1: around 8–15 top-level capabilities that cover the whole business on one page
• Level 2: typically 3–8 per level 1; this is where most useful analysis happens
• Level 3: only where you need the detail

Naming conventions vary. The Business Architecture Guild’s BIZBOK favors noun-based names (“Payment Processing”, “Agreement Management”). Others prefer verb-noun (“Process Payments”). Pick one convention and use it consistently.

It’s common to group level-1 capabilities into tiers:

• Strategic / customer-facing: what customers see and pay for
• Core / supporting: what makes the strategic capabilities work
• Enterprise / back office: what every business needs (finance, HR, legal)

Common mistakes

• Modeling the org chart. If your map changes every time there’s a reorg, it’s an org chart.
• Modeling applications. “CRM” isn’t a capability. “Customer Relationship Management” might be.
• Going too deep too soon. A complete level-3 map that took six months is worth less than a level-2 map that’s already being used.
• Building it alone. Business leaders need to recognize the map as their business. Co-create it in workshops.

Value streams

Capabilities describe what the business does. Value streams describe how value flows to a customer or stakeholder, from the stakeholder’s point of view.

A value stream:

• Is named for the value delivered, e.g. “Let a Property”
• Has a triggering stakeholder and an end result
• Is broken into stages, each of which creates some value
• Maps each stage to the capabilities that enable it

Value streams answer questions capability maps can’t: where do customers wait, drop out, or get frustrated? And which capabilities matter most to a particular outcome?

Using the map: heat mapping

A bare capability map is a nice picture. A heat-mapped capability map supports decisions. Color each capability by one dimension at a time:

Heat map	Question it answers
Strategic importance	Which capabilities differentiate us?
Maturity / performance	Which are weak today?
Application coverage	Which are supported by duplicate, missing, or end-of-life systems?
Investment	Where is money going now, and does that match importance?
Risk	Where are compliance, security, or key-person risks?

The useful insight usually comes from comparing two maps, for example “strategically important but low maturity” (invest) or “heavy investment but commodity” (stop, or buy instead of build).

Operating models

In Enterprise Architecture as Strategy, Ross, Weill & Robertson describe four operating models based on two dimensions: how standardized business processes are across units, and how integrated their data is.

	Low standardization	High standardization
High integration	Coordination: shared customers and data, different processes	Unification: one way of working, shared data
Low integration	Diversification: independent units, shared services at most	Replication: same processes, independent units (e.g. franchises)

The operating model tells you which architecture choices make sense. A unification business should invest in shared platforms and a single source of truth. A diversification business shouldn’t force them.

At Quillfeather

You run three capability workshops with the CPO, the Head of Payments, a customer success lead, and the Head of Security. Here’s the level-1 and level-2 map you produce, heat-mapped by application coverage and health:

The red cells line up almost exactly with the symptoms in the case study:

• Notification Delivery and Consent Management: three notification services with different opt-out handling. That’s a GDPR exposure as well as waste.
• Authentication: two logins, no SSO.
• Customer Account Management: customer data in four systems.
• Data Protection: nobody can say where tenant data lives, ahead of an EU launch.

The “Let a Property” value stream

1. Register property
2. Find & screen tenant
3. Agree tenancy
4. Move in
5. Collect rent
6. Maintain
7. Move out

Mapping the EU expansion against this value stream shows that the Find & screen tenant and Collect rent stages need the most change: screening relies on UK-only credit reference agencies, and rent collection needs SEPA Direct Debit and local payment methods. Those stages’ capabilities (Tenant Screening, Rent Collection, Payment Processing) become the focus of the expansion plan.

The operating model question

Quillfeather is drifting between coordination (PayNest and FixIt Pro run their own processes) and unification (customers want one product). The CPO’s goal of “one Quillfeather experience” implies unification for customer data, identity, and communications. That’s a strategic choice, not a technical one, so you take it to the CEO and CTO explicitly rather than assuming it.

Exercise

Draft a level-1 capability map for your current organization on a single page:

1. List 8–15 level-1 capabilities. Check each one: is it something the business does, not a team, system, or process?
2. Group them into strategic, core, and enterprise tiers.
3. Add level 2 for the two or three capabilities you know best.
4. Heat-map those by application health. Where’s the red?

Then show it to a business leader and ask whether they recognize their business in it. Their reaction is the real test.

Reflection

• Which of your organization’s capabilities are truly differentiating? Is that where the investment goes?
• What operating model does your organization have today? Does leadership want a different one?
• Where would a value stream map help you explain a problem that’s currently framed as “a technology issue”?