RBP-EA: The dangers of business-centric ‘enterprise’-architecture

This is in part a follow-on to ‘The Really Big Picture for enterprise-architecture‘.

As a discipline, enterprise-architecture is still in the throes of a multi-year struggle against IT-centrism – in our context, the dangerous delusion that enterprise-scope IT-architecture somehow ‘is’ enterprise-architecture. There are signs now that that struggle is at last beginning to be won: a much better recognition in Open Group conferences, for example, that business-architecture is not merely “anything not-IT that might affect IT”.

But we need to be aware, and wary, of the next trap: business-centrism. Business-architecture is, and should be, the architecture of the business. But it is not the architecture of the enterprise: the two are fundamentally different. Or, more accurately, business-architecture is a detail-layer subset of enterprise-architecture – and exactly as with IT-architecture, it is essential not to mistake any subset for the whole.

Let’s take a classic business-architecture frame, Alex Osterwalder’s Business Model Canvas:

Business Model Canvas [(cc) Alex Osterwalder, Yves Pigneur et al.]

This provides an excellent way to describe a commercial organisation’s business-model: products and services, how the customer is contacted, revenue-streams, supply-chain concerns, costs and so on. We definitely need all that information in a business-architecture, and in considerable detail.

But what this doesn’t do is show how this expands downward into the fine-detail of implementation and operational-management – which is what we need in order to realise that business-model. For example, for the IT-related components of that business-model, that’s where the IT-architectures would come into play: information-architecture, data-architecture, applications-architecture, infrastructure-architecture and so on. We would also need to connect with BPM (business-process management), security-architectures, skills-mappings and a whole load more, especially on the ‘human’ side of business practice. So on its own, a business-centric architecture could be misleading: a big-picture that’s useful, and usefully descriptive, but not actually usable in real-world practice.

And that business-oriented ‘big-picture’ is not actually big enough: it ignores a whole swathe of information about the broader business-context, and hence is left to make arbitrary assumptions about that broader context – assumptions which may well turn out to be wrong. In essence, the Business Model Canvas – and almost every other business-architecture frame that I’ve seen – will summarise the core working of the organisation, its relationships with the ‘near-field’ aspects of the supply-chain, and some description of how it will relate to customer-prospects: but that’s usually as far as it will go. Which is dangerously incomplete in relation to the whole scope of the extended-enterprise:

Relationships with the ‘outside’ part of the extended-enterprise, beyond the core market, are primarily driven by values – not solely monetary concerns, which for the most part apply only at the market-transaction level. Failing to pay proper attention to those broader values can kill the viability of the business-model and even the business itself – even though those ‘transactions’ may not touch the actual business-model at all. We can perhaps see this best through what I call the ‘market-cycle’:

Another cyclical view of the relationships between all these layers also illustrates the source – and danger – of the all-too-common ‘quick-profit’ short-cut version of the cycle, which is guaranteed to drive a business into the ground in the medium to longer term:

The greyed-out area described as ‘tactics + operations’ in that diagram is usually the maximum scope of a business-architecture. An enterprise-architecture must, by definition, cover the entire scope. A ‘business-centric’ version of enterprise-architecture would constrain us to the business-specific scope – which is why everything else would be left to arbitrary and often unconscious assumptions. Not a good idea – in fact actually worse than the IT-centric version of ‘enterprise’-architecture, because at least in the latter case the limitations are obvious to most people, whereas in the business-centric version the gaps are easier to miss.

One of the things that that unhelpful troll on LinkedIn mocked me for – and others have done much the same, in the past – was my attempt to explain that in an enterprise-architecture we must take into account the value-transactions and interactions: we can’t simply reduce it all to monetary terms. As should be obvious from the diagrams above, there are relationships between those value-transactions and the monetary-type transactions that come later in the market-cycle: but those relations are usually complex, non-linear and non-reversible, so we can’t start from a monetary view (as in so many conventional ‘value-proposition’ concepts) and return directly to a monetary view (as monetary ‘profit’). The transforms from there to the much-vaunted and apparently much-desired ‘shareholder-value’ are even more complex and non-linear: as Michael Porter once put it, the obsessive quest for ‘shareholder-value’ is “the Bermuda triangle of strategy“, in which so many companies sink without trace… Yet even Michael Porter misses the point in that article: he refers to ‘economic performance’, when what he means is ‘overall performance as measured in monetary terms’ – which is not the same thing. As business-architects we can sometimes get away with that kind of kludge: but as enterprise-architects, we can’t get away with it – especially at the Really Big Picture level.

So yes, heave a sigh of relief as we finally break free from IT-centrism in enterprise-architecture. But beware of the next trap – the trap of ‘business-centrism’ – and instead keep the focus and emphasis, at all times, on the extended-enterprise as a unified if always somewhat-chaotic whole.