What exactly is ‘the enterprise’ in enterprise-architecture? To what extent is that enterprise a shared-enterprise? And how does this affect enterprise-architecture itself?
These questions have come up a lot in the past few weeks, in back-and-forth conversations on LinkedIn and elsewhere. The questions themselves might at first seem innocuous, or the answers so obvious as to be irrelevant – that’s been many people’s response, at any rate. But in reality each of those questions is utterly fundamental to enterprise-architecture – and the way we choose to answer them will in turn fundamentally affect both we view the role of EA in business and elsewhere, and how we address it as a practice.
Some answers result in a concept and discipline of ‘enterprise-architecture’ so myopic in view that it’s all but meaningless in real-world practice. Yet unfortunately those are the answers still most commonly used at present – which is precisely why EA continues to struggle so hard to gain acceptance or value. To find a way out of that mess, we first need to rethink how we answer those questions.
First, the term enterprise. Its literal root, from French, is ‘between-take’ (French: ‘entre‘, between; ‘prendre‘, take) – hence entrepreneur as a literal ‘between-taker’ who takes on a role as active intermediary interposing itself between needs.
From there we lead to Adam Smith’s ‘the animal spirits of the entrepreneur’: hence ‘enterprise’ as a descriptor both of aim or intent – often denoted via a story – and also of the energy or drive to reach towards that aim, to engage in that story.
To reach towards that aim, we’re likely to need to organise – in other words, provide some kind of structure around which to accrete resources and coordinate actions towards that aim. ‘Organisation’ is the verb, the activity, which in turn leads to ‘the organisation’ as noun, the structures arising from that activity; all of which arise in context of and because of the-enterprise-as-aim. Note again that although ‘organisation’ and ‘enterprise’ are closely intertwined here, they are not the same: the simplest summary would be that organisation is ‘how’, enterprise is ‘why’. Treating them as synonyms means that in effect we’re equating ‘how’ with ‘why’ – otherwise known as Not A Good Idea…
As the ambitions of enterprise grow in scope and scale, so too must the organisation. Which, if we’ve already made the mistake of blurring together ‘organisation’ and ‘enterprise’, in turn leads to the common notion that ‘enterprise’ is a synonym for ‘large commercial organisation’ – enterprise as a descriptor of scale, rather than of aim or intent. Hence the all too common notion that enterprise-architecture is relevant only to large commercial organisations. Yet by definition, enterprise-as-intent can and does apply at any scope or scale – hence the same must inherently apply to any architecture of that enterprise. In short, don’t use the enterprise-as-scale concept as the basis for ‘enterprise’ in enterprise-architecture: it is guaranteed to mislead, a proven antipattern for failure.
What about term architecture? Again, many different interpretations, typically more dependent on content – hence data-architecture, naval-architecture, applications-architecture, brand-architecture, infrastructure-architecture, security-architecture, business-architecture and more. Enterprise-architecture is a bit different, in that its content is other architectures: it’s more of a meta-architecture, less focussed on content as such, more on how to link other architectures together, within the overall context of the organisation and enterprise. The simplest way to put it is that we build an ‘enterprise-architecture’ of and for an organisation, in context of and about the enterprise(s) that drive the actions for that organisation.
Which in turn is where shared-enterprise comes into the picture.
All that ‘shared-enterprise’ means is that there’s some aspect of enterprise – the aim, the intent, the story – that is held not just by us, but by others too. Which always occurs, because there are always interactions with others about the matter of the enterprise – even in the edge-case where the enterprise is shared only with Self-as-Other. Which means that to understand and model the interactions of our organisation with that enterprise, our enterprise-architecture will need to understand and model the respective ‘sharedness’ of each of those interactions with others in the shared-enterprise, Amongst other things, that tells us the drivers, the ‘why’, for each of the interactions. Without that, it would be all but impossible to make sense of those interactions, or even what some of those interactions are – placing our organisation at risk. Which is why this matters to enterprise-architecture – and matters a lot.
Yet I’ve had so many strange responses on this point that it’s clear many people simply don’t get it as yet. Often these fail on mistaken conflation of ‘organisation’ and ‘enterprise’: for example, two people launched into tirades about the politics of ‘state-owned enterprises’ and the evils of socialism – which have almost no connection at all to what I’m describing here. (It’s true that those do relate to Really-Big-Picture Enterprise-Architecture concerns such as possessionism and large-scope power-problems, but those are different themes for another time.)
To summarise: the term ‘shared-enterprise‘ means an enterprise that is shared – nothing more than that. And what is shared is the elements that denote an enterprise, namely vision, values and commitments – typically expressed as aims, drivers, story, definitions of success or not-success, definitions of ‘right’ and ‘wrong’, and suchlike concerns. (Note that this significantly different from an organisation, which is bounded by rules, roles and responsibilities – another reason why blurring ‘organisation’ and ‘enterprise’ is Not A Good Idea…)
Why does this matter, to enterprise-architecture, or to anything? The short-answer is that if we don’t explore the shared-enterprise, we’d be basing all of our designs and processes for interactions with others upon arbitrary, untested assumptions – which would definitely be Not A Good Idea… Note too the crucial difference between interactions within the organisation (which we can sort-of control with rules and the like, but for which we’d be wise to base much on enterprise-drivers too), versus interactions with others beyond the organisation (which we cannot ‘control’, but only influence, via our understanding of the respective ‘sharedness’ of the enterprise). Being clear about those differences is crucial for validity and viability of any enterprise-architecture, and for all other domain-architectures too.
One way to depict that distinction between ‘control’ and influence is through a four-step pattern of ‘inside-in’ to ‘outside-out’:
‘Inside-in’ is all that we could sort-of ‘control’. ‘Inside-out’ is about our choices in how we relate to ‘outside’, ‘the Other’, the shared-enterprise. ‘Outside-in’ is how the shared-enterprise perceives its interactions with us – which is not in our control. ‘Outside-out’ is how the shared-enterprise perceives itself, its source of drivers, values and like – about which we have some influence, as a player in that shared-enterprise, though only as one (collective) player amongst many.
Another way I usually describe this, closely related to the ‘inside-in’ to ‘outside-out’ pattern, is in terms of another layered pattern of interaction-types: self (‘service-in-focus’), transaction, direct-interaction, indirect-interaction. In abstract form, the pattern looks like this:
For the organisation as a whole – the place where people most often conflate ‘organisation’ and ‘enterprise’ – the pattern would look like this:
Or in terms of typical scope of architectures relative to that organisation:
In classic IT-centric enterprise-architecture, the respective ‘enterprise’ is actually the context for IT-infrastructure, so the pattern would look like this:
…otherwise known as the dreaded ‘BDAT-stack‘:
…though these days even the most IT-centric of ‘enterprise’-architectures would need a broader grasp of the actual shared-enterprise:
And the two patterns align roughly as follows:
Yet herein lies an important catch. In each of these illustrations we’ve placed the organisation as the apparent centre of the respective shared-enterprise – which is the correct thing to do when we’re modelling those interactions from the organisation’s perspective, looking ‘inside-out’, and often for ‘outside-in’ as well. But when, for example, we need to position the organisation in context of its competitors or collaborators in a more complex market-relationship, we’ll need a different view of that same pattern – one that is not centred solely on our organisation:
As soon as we place ourselves in a shared-enterprise – the enterprise of ‘business-travel’, in this example above – we automatically place ourselves in relation to and with every other player in that shared-enterprise. Each of those players would no doubt see themselves as the centre of their own relationships and interactions with others in that market and the broader shared-enterprise – and correctly so, if only in the sense that each organisation has its own responsibilities in how it interacts with others in that shared-enterprise. Yet everyone affects everyone else in the respective shared-enterprise: every player affects and is affected by every other player, sometimes with potentially-huge impacts on business and more – risks, and opportunities, that would be utterly invisible unless we take the deliberate care to bring them to the surface. It’s only if we do have a solid grasp of what the respective shared-enterprise is, and how expectations and interactions flow around within it, that we and our organisation can start to have some real choices about those impacts.
In short, without a solid understanding of shared-enterprise, a supposed ‘enterprise’-architecture cannot be either valid or viable as a literal ‘the architecture of the enterprise’ – and hence itself also places the viability of the respective organisation at risk. We ignore this point at our peril…