Organisation and enterprise

What is an enterprise? Perhaps more specifically, what is ‘the enterprise’ in enterprise-architecture?

(Quick TL;DR summary: in enterprise-architecture, ‘the enterprise’ is not the same as ‘the organisation’, and is always larger in scope than just ‘the organisation’. Confusing those two terms, or treating them as if they are the same, will cause architectural failure. The reasons for this are explained in some detail below.)

This is somewhat of an old perennial – I’ve covered it in many previous posts, in various different ways. But it’s so important, and there are so many people still making the same mistakes about it, that we really do need to cover it yet again.

There’s been a bit of a Twitter-fest about this in the past few days, again from various different angles. But perhaps the best illustration is this typically-wry aside from Ric Phillips, about current Australian politics:

• RT @ricphillips: Turnbull burns down community TV. Obviously the LNP think the only legitimate sphere of any human endeavour is for-profit companies. #auspol

(For those who don’t know Australia, the LNP (Liberal and National Party) controls the current government there, and is roughly the equivalent of the Republicans in the US, or the Conservatives in the UK.)

I’ll avoid any comments on the politics as such, but just note this one part of the Tweet: “[they] think the only legitimate sphere of any human endeavour is for-profit companies”. Which, if we stop to think about it for even a single moment, would be clearly absurd: there are many other forms of human endeavour than solely for-profit in for-profit companies – raising our families, just to give one example. If someone does think that the only legitimate sphere of human endeavour is for-profit companies, they’d be committing a term-hijack that would be so egregious – so disruptive, in so many social forms – as to be truly obscene.

The key here, though, is that there are two fundamentally different definitions of ‘enterprise’:

• Definition E1: “an endeavour, a bold undertaking” – hence the linkage to the concept of ‘entrepreneur’
• Definition E2: “a large organisation or consortium” – usually for-profit

These two definitions are not the same: don’t mix them up!

What’s too often happened – as indicated in that tweet above about “the only legitimate sphere of any human endeavour is for-profit companies” – is that the two definitions of ‘enterprise’ have been conflated together, with the priority given to Definition E2. They are not the same: that point is really important for enterprise-architecture (and much, much more) – and a point that needs to be hammered home at every appropriate opportunity.

What I want to reiterate here is that whilst both definitions are each arguably valid in their own right, Definition E1 is the only one that should be used in enterprise-architecture. Definition E2 is not ‘wrong’ as such, but in practice it’s so misleading that it should not be used.

Which is not going to be easy, because at present, Definition E2 is the one that is most (mis)used throughout almost all current enterprise-architecture and elsewhere. Usage of Definition E1 is, unfortunately, still relatively rare, and few people seem to fully understand either its full implications for EA practice, or why it is so essential to use this definition rather than Definition E2.

The reason this is so important is that if we use Definition E2, it becomes almost impossible to describe the context in which that Definition-E2 ‘enterprise’ operates – its business-model and so on, and also key business-concerns such as ‘right-sourcing’ – or even the actual motivations and drivers that apply to this Definition-E2 ‘enterprise’. By contrast, if we are systematic in the way we use Definition E1, all of those themes start to make practical sense, and are much, much easier to describe to others across that enterprise.

In enterprise-architecture, we’re working with two distinct types of bounded-entities, that can look the same, and whose boundaries can coincide, but yet have fundamentally different boundaries and drivers:

• Structure S1: a motivational entity, bounded by purpose, values and principles
• Structure S2: an organisational entity, bounded by rules, roles and responsibilities

Again, even though the boundaries of these two types of entities can coincide, they are not the same: don’t mix them up!

In essence:

• Definition E1 – ‘a bold endeavour’ – aligns with Structure S1 – ‘a motivational entity’
• Definition E2 – ‘an organisation or consortium’ – aligns with Structure S2 – ‘an organisational entity’.
• An organisation (S2) is a structure – a means – to support the motivation and intent (S1) of the endeavour (E1) – the ends.

Another useful way to clarify those distinctions is to reframe that S1/E1 pairing – a motivation-based construct, to identify a purposive ‘bold undertaking’ – as an assertion that an enterprise is an ecosystem with a purpose. By contrast, the S2/E2 pairing is more like the kind of ecosystem we find in the natural world, without an intrinsic purpose – other than solely its own survival, perhaps.

When we use Definition E2 for ‘the enterprise’ – as a substitute for E1 – the effective result is a conflation of E2=S1=S2: ‘the organisation is itself the sole purpose for the existence of the organisation’. If we do that, what we’re in effect saying is that the structures that we use to support the endeavour are themselves the purpose of all activity – in other words, that the means are themselves the only ends for activity. Even a few moments’ thought about the differences between ends and means should indicate that, architecturally speaking, conflating all those items together in that way is not a good idea. Ends and means are not the same: don’t mix them up!

(Update, 24Sep14: The following quote, from an article by Allan Little about the Scottish independence-referendum, on the BBC website, illustrates well the complexity of ‘enterprise’ as a term – its boundedness, the nature of its boundedness, its relationship with purpose, and so on. Don’t worry much about the detailed-content here: just note the implied meaning of ‘enterprise’ in this context.)

[In the early 20th century] Even in our remote little village, which seemed impossibly distant even from Glasgow, was connected intimately to the great wide world through the shared global enterprise of the British Empire. …
Empire, industry, world war, welfare state: those were the powerful things that locked Scotland into the Union, that gave generations of Scottish people a sense of partnership in a common purpose.

(Update, continued: Note how the S1/E1 and S2/E2 pairings – ‘bold endeavour bounded by purpose, values and commitments’ and ‘organisation or consortium bounded by rules, roles and responsibilities’ – both make sense in this context. By contrast, the E2:S1:s2 conflation – ‘a large commercial for-profit organisation’ – sort-of makes sense in a strangely-squeezed sort of way, and might be the only way that many business-folk would see it, yet seriously misses the “intimate” emotive drives behind “the shared global enterprise of the British Empire” of that time.)

Given those entities and their boundaries, what or who determines their respective boundaries? Short-answer: we do! The boundaries are fractal: hence, much as with the boundary of a service, the boundary of ‘the organisation’ or ‘the enterprise’ is something that we choose. (We may be told or required to work with specific boundaries for any particular architectural task, but they’re still someone’s choice.)

• The boundary of the enterprise (S1) – its purpose, values and principles – is what we identify it to be.
• The boundary of the organisation (S2) – its rules, roles and responsibilities and its ‘boundary of control‘ – is what we identify it to be.

In practice, we always develop an architecture for an organisation of some kind – if only because that’s what probably determines who pays for the work. Again, though, it’s fractal:

• organisation as a business-consortium
• organisation as a government department
• organisation as a business-unit
• organisation as a sports-club
• organisation as an application-portfolio
• organisation as a functional cluster – for example, a server-rack
• organisation of a work-team
• organisation at a cellular level

We can do an architecture for any one of those things, or any other ‘thing’ that could be considered as bounded by a set of rules, roles and responsibilities.

Yet to develop that architecture, we need to know its context, and the drivers for that context – in other words, in terms of those definitions above, the enterprise that we identify as that organisation’s context, bounded by vision, values and commitments.

We develop an architecture for an organisation, but about the enterprise that we choose to identify as its context.

If we say that ‘the enterprise’ is ‘the organisation’, we’d in effect be saying that we’re going to develop an architecture that has no context. Or, to be slightly more pedantic, we’d be assuming that the vision, the values and the guiding-principles that apply in the respective architectural context are identical to and defined exactly by the rules, roles and responsibilities of the respective organisation. Yes, there might be a small number of special-cases where such an assertion might make sense, architecturally-speaking; but for most architectural concerns, such an assertion would make no sense at all. Once again, don’t mix them up!

For example, if we don’t separate ‘the organisation’ and ‘the enterprise’, we’d have no means to describe the contextual, and crucial, tensions between ‘inside-out’ (organisation-oriented) and ‘outside-in’ (enterprise-oriented) that drive markets and business-models:

If we can’t separate ‘the organisation’ and ‘the enterprise’, we’d have no means to describe the contextual, yet crucial, differences between a classic ‘hands-off’ sourcing-relationship – where the organisation’s ‘boundary of identity’ and ‘boundary of control’ are the same, and suppliers are outside of both – versus an outsourcing-relationship – where the outsourced-suppliers are outside the organisation’s ‘boundary-of-control’ (‘the organisation’) but inside the organisation’s ‘boundary of identity’ (a specific type of ‘the enterprise’):

And if we can’t distinguish between the current structures (‘the organisation’, as per S2 and E2 above) and its drivers and motivation (‘the enterprise’, as per S1 and E1 above), we’d have no means to make sense of strategy – or even to be able to develop a future-oriented strategy at all.

Or, to put it another way, if we conflate ‘the organisation’ and ‘the enterprise’, what we’d be saying is that our architecture defines an organisation – or something, at any rate… – that:

• is literally self-centric
• has no awareness of its context
• has no means to understand or even identify its market and other ‘external’ stakeholders
• assumes that its own rules must inherently apply everywhere, both within and beyond its own boundaries
• assumes that its top-down rules are the only valid form of motivation
• assumes that its top-down rules are the same as ‘values’
• assumes that its responsibilities to others cease exactly at its own boundaries
• assumes that the present (as defined by existing organisational rules, roles and responsibilities) extends linearly into the future (hence pseudo-strategies such as “Our strategy is last year +10%”)

Otherwise known as ‘not a good idea’… – or not a viable idea in the longer term, at any rate. (Though scarily close to how too many current organisations really do attempt to define themselves and their architectures and ‘strategies’…)

How much of a separation do we need between the boundaries of ‘the organisation’ and of ‘the enterprise’? In practice, for most architectural purposes, a useful guideline is that the enterprise in scope should be able to extend to at least three layers larger than the organisation in scope.

Or, given a scope for which we’re developing an architecture – ‘the organisation’ – we’d typically need to explore a context – ‘the enterprise’ – whose scope extends at least three steps further out.

Let’s see how that works in practice. First, the classic E2 definition, ‘the enterprise is the organisation’:

In other words, architecture-development without any awareness of context: not-a-good-idea, as described above. Or at least, rarely a useful idea.

A first layer of separation – for a commercial-business context, for example – would be where we set the boundary of the enterprise to the first-level of the business-model, with the tensions and drivers between the organisation and its direct suppliers and customers:

We can influence across those organisation/enterprise gaps, but we can never ‘control‘ it – not even with the tightest of contracts. That distinction is kinda important…

For some architectural purposes, we might extend that first-level separation to include more of the organisation’s supply-chain or direct value-web:

We’d use this type of extended first-level model to assess architectural, strategic and tactical concerns such as risks within the overall supply-chain. Although there are more connections and interdependencies here, this is still only a first-level separation, architecturally-speaking, because that it still places the organisation at its centre. The model wouldn’t make any sense if we took the organisation out of the picture.

The second layer of separation – if we again use the same commercial-type example – extends the scope of ‘the enterprise’ outward to the market, the context within which a cluster of related business-models take place:

Two important points to note here:

— Although we’ve placed ‘the organisation’ at the centre, this type of model would still make sense if this organisation did not exist. (Hence why we’d typically use this type of model to explore possibilities within a market, above and beyond our existing business-model – or maybe as a potential new business-model.)

— What we’d call ‘the market’ is also a ‘the organisation’ in its own right: it has its own rules, roles and responsibilities. If our ‘the organisation’ wants to be a player in this market, it first needs to know, and be able to align and comply with, those respective rules, roles and responsibilities. (Hence why we’d need to use this type of model to identify the market-context within which our ‘the organisation’ operates, or wants to operate.)

The third layer of separation extends the context-scope further outward to what we might call the shared-enterprise, to include a whole array of other stakeholders who are in effect part of the same overall ‘enterprise-story‘, but who are not active players in the same market-space (layer-2) for the organisation’s business-model (layer-1):

We’d use this type of model for a wide variety of ‘further-reach’ architectural purposes, including:

• identify potential for a market, where no market currently exists
• identify risks and opportunities in community and government, beyond the basic business-model
• create and maintain relationships with investors and beneficiaries – often beyond financial terms alone
• identify, and, where appropriate, build relationships with, relevant non-clients and anti-clients

The same E1/S1 pairing of purpose and structure is a key theme behind the Enterprise Canvas model-type, for service-oriented, fractal-based whole-of-enterprise architectures:

By contrast, the E2:S1:S2 conflation – ‘the organisation is itself the sole purpose for the existence of the organisation and its enterprise’ – tends to lead directly to the inherently-dysfunctional, past-oriented Taylorist or Milton Friedman-type concept of the organisation, where the only ‘purpose’ of the entire enterprise is parasitic profit for its financial-shareholders:

It’s important to note that this structure of ‘enterprise-in-scope is three layers larger the organisation-in-scope’ is a fractal pattern, and hence one we’d expect to see being used to identify contexts throughout enterprise-architecture and many other types of architectures. Which, in practice, we do. For example, back in mainstream IT-oriented ‘enterprise’-architectures, the misleading E2:S1:S2 definition (‘the organisation is the enterprise is the organisation’) is all too common, yet we still see a variant of the ‘self plus two-layer’ model in the ‘three architectures’ framing used in TOGAF and elsewhere:

This model is often referred to as the ‘BDAT stack’ – Business, Data, Applications, Technology. For that context usage, the effective mappings are:

• Technology Architecture: ‘the organisation’; also layer-0 enterprise, ‘the enterprise = the organisation’
• Data Architecture and Applications Architecture:  layer-1 enterprise (‘supplier/customer’ type enterprise)
• Business Architecture: somewhat-blurry mix of layer-2 enterprise (‘market’-type relationships, imposed rules, strategic-drivers etc) and layer-3 enterprise (‘beyond-market’-type relationships) – overall sometimes described as “anything not-IT that might affect IT” (i.e. ‘IT’ as ‘the organisation’)

The catch – and which is all too often missed in mainstream ‘enterprise’-architecture – is that the layering only works one way round, where ‘the enterprise’ is larger in scope than ‘the organisation’. Whatever it is that we’re developing an architecture for must be at the base of the respective ‘stack’, as ‘the organisation’: it doesn’t work the other way round. If we do try to run it back-to-front or upside-down – such as in trying to use the BDAT stack to develop a business-architecture – the structures and drivers for the inner layers (‘Technology Architecture’ and ‘Data Architecture’ and/or ‘Application Architecture’) are used as the drivers for the outer layers (‘Business Architecture’, in this case), leading directly to strategic and structural mistakes such as IT-centrism. The layers and their relationships have distinct roles and functions in an architecture, and playing random mix-and-match between them is not a good idea… – don’t mix them up!

Obviously, there are interactions between the layers: that’s the whole point of the BDAT stack and suchlike, to model how ‘bottom-up’ flows and drivers interact with ‘top-down’ and ‘sideways-in’ flows and drivers. But it’s essential to remember that, for those purposes, when using that type of ‘organisation and enterprise’ framing, that for which we’re developing the architecture is always at the base of the stack. For example, if we want to develop a business-architecture, then ‘the business’ is at the base of the stack – not at the top, as in implied in that BDAT stack.

There’s also that key distinction between influence, and ‘control’. We can perhaps influence what happens beyond that base-level, but we probably can’t design it, and we certainly can’t control it – because it’s beyond the rules, roles and responsibilities of ‘the organisation’ that’s at the base of that stack. Control and influence are not the same: don’t mix them up!

Another way to frame all of this is via an extension of the ‘inside-out versus outside-in’ relationships:

It’s another view into the same sort of ‘organisation versus enterprise’ separation, but mapped in a somewhat different way:

• outside-out: the broader-enterprise in its own terms, regardless of whether or not the organisation exists
• outside-in: interface between enterprise and organisation, from the perspective of the broader-enterprise
• interaction-journey: interactions across the interface between the organisation and the broader enterprise – such as through an API or a sales-channel
• inside-out: interface between organisation and enterprise, from the perspective of the organisation (‘black-box’ view of outward-facing interface)
• inside-in: ‘white-box’ view of the internals of the organisation’s services, independent of anything else

This type of mapping between organisation and enterprise is especially useful at the two extremes: making sense of that more outward layer-3 shared-enterprise (outside-out); and doing a ‘clean up the mess’ internal-refresh that, by intent, should not change any outward-facing interfaces (inside-in) – such as per TOGAF 8 technology-architecture refresh.

To complement these two themes – enterprise as motivation, and bounded-entities – we also need to note that the term ‘vision’ has (at least) two fundamentally-different definitions:

• Definition V1: ‘the permanent anchor for all decisions on quality and purpose’ – one of the crucial points being that it does not change
• Definition V2: ‘the end-point for current strategic or tactical intent’ – which does change with each change in strategy or tactics

Definition V1 is typically used in quality-systems and the like, such as in ISO9000:2000; Definition V2 is used in quite a few business-oriented frameworks such as Business Motivation Model. Both of these definitions are useful in enterprise-architecture, but they’re not the same: don’t mix them up!

Both definitions describe motivation or ‘ends’ for an organisation and/or broader-enterprise. The fundamental difference is that a ‘vision’ in Definition V1 sense does not change – in fact, if it does change, we’re no longer in the same enterprise – whereas ‘vision’ in the Definition V2 sense can change at any time, usually dependent on the respective need within the organisation alone. In that sense:

• Definition V1 aligns strongly with the E1/S1 enterprise-pairing
• Definition V2 aligns more with the E2/S2 organisation-pairing

Importantly, the values and principles that arise from a V1-type ‘vision’ apply to all players in the respective shared-enterprise – all the way out to layer-3 and beyond. This means that, whether it likes it or not, the organisation and its performance will be assessed and measured according to that vision – not necessarily its own ‘vision’. Failing to understand this point is what causes businesses to collapse through ‘unexpected’ anticlient interactions. (I’ve seen at least one real-world case where the respective anticlient was virtually the entirety of a whole country, including its government.) This is yet another reason why the E2 definition of ‘enterprise’ should not be used in enterprise-architecture and the like: conflating ‘the enterprise’ into ‘the organisation’ all but guarantees failure to understand this point about the primacy of broader-scope layers of ‘enterprise’.

By contrast, a V2-type ‘vision’ is the kind of motivational-entity that we’d use when describing the intended outcome of an architectural roadmap or the like – such as in the somewhat-misleading concept of ‘future-state’. In enterprise-architecture, the values and principles that arise from a V2-type ‘vision’ are typically design-principles, such as weightings for an architectural trade-off such as ‘build versus buy’.

A V1-type enterprise-vision is crucially important because it underpins the ‘value’-component of any ‘value-proposition‘ in a business-model. In Enterprise Canvas, for example, we model value-flow ‘horizontally’, through the direct relationships between services; yet each of those services also connect ‘vertically’ to the shared-enterprise via the shared-vision and values that define and delimit that shared-enterprise. That’s ultimately the ‘why‘ for any interaction between the organisation and its ‘external’ stakeholders. This means that the full set of relationships between transactors in a supply-chain market-relationship would actually look more like this:

It’s also important to note that every person – and hence, ultimately, every potential-supplier and potential-customer – is ‘in’ not just this one shared-enterprise as delimited by this specific vision, values and commitments to which our organisation aligns itself, but rather is ‘in’ a fractal-type structure of many-upon-many enterprises-of-enterprises, and markets-of-markets, all at the same time. In effect, and in practice, they intersect with specific shared-enterprises, according to the need, often from moment to moment.

It may well be that to us, as enterprise-architects or business-architects or whatever, the organisation is ‘the centre’ of everything; but to suppliers and clients, to the market, and to the broader shared-enterprise, all we ever are is one possible option within the shared enterprise, that purports to propose a means of delivering value in terms of that shared-enterprise. We’re not the centre of their world: and we never are – other than perhaps in certain specific moments where some form of interaction actually takes place. We forget that fact at our peril…

Once again, organisation and enterprise are not the same – so don’t mix them up!

Leave it at that, I guess: over to you for comments, perhaps?