Business architecture is not a chapter of a framework

Ask ten organisations where business architecture sits and you will get ten answers, most of them organisational rather than intellectual. It reports to the CIO here, to strategy there, to transformation somewhere else. The common thread is that it is usually asked to justify itself in the language of whichever function it happens to report to.

What it is actually for

Business architecture exists to make a strategy operable. A strategy says what the organisation intends to be able to do. Business architecture says what capabilities that requires, which of them exist, how well, and what would have to change in the operating model for the rest to exist.

That is a small number of artefacts doing a large amount of work: a capability map, value streams that cross the organisation chart, an information view, and an organisation view. Done well they fit on a wall and settle arguments. Done badly they become a taxonomy nobody opens twice.

Three failure modes worth naming

• Levelling too deep. A capability map with six levels everywhere is a hobby. Go deep only where a decision hangs on it.
• Mapping the organisation chart and calling it a value stream. If your value stream stops at a department boundary, it is a process, and the interesting problems are exactly at the boundaries you removed.
• Modelling in private. Business architecture that has not been argued over with the people who run the business is a document, not an agreement.

Where it meets the method

In practice business architecture is the phase where an architecture practice earns the right to be listened to later. Get it right and the technology conversation happens against an agreed picture of what the business is trying to do. Get it wrong and every subsequent phase becomes a negotiation about first principles.