A company operates marketplaces, payments, logistics and cloud services as one ecosystem. What does business architecture contribute that technical architecture does not?

What it contributes

A map of what the organisation does, independent of how it is currently implemented or organised.

Technical architecture answers "how does the system work". Business architecture answers "what capabilities does the business have, which are differentiating, which are shared, and where do the seams belong". Those questions produce different boundaries, and the difference is the whole value.

In an ecosystem spanning marketplace, payments, logistics and cloud, the useful questions are business ones:

• Which capabilities are genuinely shared across business lines — identity, payments, fraud, settlement, merchant onboarding — and therefore belong in one place, versus which merely look similar?
• Which are differentiating and should stay owned by the business line that competes with them?
• Where does a capability serve one line but is being funded by another, which is where cross-subsidy and misaligned incentives hide?
• What happens if one business line is divested or regulated separately? That question exposes couplings that no technical diagram shows.

Why the last question matters most

Ecosystem businesses frequently face regulatory separation, and the capability map is what tells you the cost of separation before it is required. A payments capability deeply entangled with a marketplace's internal data model is a technical fact with a strategic consequence, and it is invisible in an application inventory.

What it is not

Not an application portfolio. Applications implement capabilities and change far more often. A capability map anchored to current applications ages immediately.

Not an organisation chart. The organisation will reorganise; the capabilities will not. Anchoring to teams produces a map that expires with the next restructure.

Not a diagram exercise. A capability map that does not answer a decision — invest, consolidate, separate, build, buy, divest — is documentation nobody uses.

The test of a useful business architecture

It should make a specific decision easier: whether to build one shared fraud capability or three, whether a business line can be operated separately, where a platform investment pays back across lines. If it cannot be used to argue for or against a concrete investment, it is decoration.