6 years, 7 months ago

Organisation and enterprise as ‘how’ and ‘why’

Link: http://weblog.tetradian.com/2014/10/06/organisation-and-enterprise-as-how-and-why/

What’s the relationship between organisation and enterprise? In particular, how would we work with that relationship in enterprise-architecture?

This one’s a follow-on from both ‘Fractals, naming and enterprise-architecture‘ and ‘Organisation and enterprise‘, and, more specifically, is a response to Len Fehskens, about a comment he made to the latter post:

This is why I object to your statement that the enterprise

“is always larger in scope than just ‘the organisation’”.

First the idea of “larger in scope” only makes sense when interpreted a certain way, and second, an enterprise cannot be realized except by an organization that is capable of realizing the entire enterprise.

To see the full context for that part of that comment by Len, you’ll probably need to read not only the full comment, but the whole comment-stream that precedes it, and the whole of the post as well. But there’s enough to start with just in that quote above, though I’ll add a few more quotes from that comment as we go along.

Again in the spirit of TL;DR (though I suspect that’s part of what’s caused the confusion in the first place), here’s a one-line summary: the organisation is ‘how’, the enterprise is ‘why’; the ‘why’ must always be larger than the ‘how’, hence the scope of ‘the enterprise’ must always be larger than the scope of ‘the organisation’.

To expand on that one-line summary, first, a key point about fractals, or patterns that sort-of repeat in self-similar fashion at multiple levels with the scope of an enterprise-architecture. Both Len and I do agree that that applies to this context:

OK, we agree that organizations are fractal or recursive in structure. But what makes something an organization, such we can sensibly apply that name to it?

That follow-on question sounds fair enough, but in practice – in Len’s description in that comment, at least – leads us into an even worse tangle of arbitrary boundaries. To make practical sense of it, we do need to keep very strictly to a very specific and very ‘flat’ set of fractal-oriented definitions – otherwise we’ll get lost in the thickets of terminology-confusion in no time at all.

To me, though, the core of that confusion arises in a slightly earlier part of Len’s comment:

For me enterprises and organizations are qualitatively different kinds of things. An organization is a real physical thing. An enterprise is a concept.

Yes, enterprises and organisations are qualitatively different things: the fractal-definitions I use (which I’ll restate below, just after this point) are very clear on that. But no, the qualitative difference is not that “an organisation is a real physical thing, an enterprise is a concept” – because both ‘organisation’ and ‘enterprise’ are solely conceptual entities. The expression of organisation – of the process of organising – is usually physical, yes; but organisation itself is not – not even as ‘the organisation’. A concept, versus the expression of that concept, are not the same thing: don’t mix them up!

To illustrate the qualitative differences that actually matter here, let’s restate those definitions, from the ‘Fractals’ post, and then extend them somewhat:

Enterprise: “a bold endeavour”; an emotive or motivational structure, bounded by shared-vision (purpose), shared-values and mutual commitments. In essence, it identifies:

  • the ‘why’ (purpose, or vision) for an activity
  • the ends (vision, or purpose) for that activity
  • key qualifiers and metrics (values) for guidance of that activity, to keep it on track to its intended ends
  • anchors (mutual-commitments) to engage people (as ‘who’) towards that ‘why’, those ends, those qualifiers and metrics

Organisation: the primary delimiter of scope; a legal structure, bounded by rules, roles and responsibilities. In essence, it identifies:

  • the human aspects of the ‘how’ (rules, roles, responsibilities) for an activity
  • the human aspects of the means (roles, responsibilities) for that activity
  • key guidelines (rules) to link the enacted activity itself back to the ‘why’, ends, qualifiers and metrics
  • anchors (roles and responsibilities) to engage people (as ‘who’) towards the respective ‘how’, means and guidelines

In short:

  • enterprise is why – the ends
  • organisation is how – the means

Or, to summarise this in visual form, using an Enterprise Canvas fractal approach where ‘the service’ is in effect synonymous here with ‘the organisation’:

The key here, then, is that the service – the organisation, the means, the ‘how’ – is always in context of the vision – the enterprise, the ends, the ‘why’. And one of the fundamental value-checks that we place on all enterprise, all organisation, all activity, is that the means must always be subordinate to the ends. We know – we all know – that if we ever get that one the wrong way round, we’ll be in deep, deep trouble, in many, many different senses of ‘trouble’…

So, assuming that it’s agreed that ‘enterprise’ in effect equates to ‘why’ and ends, and ‘organisation’ to ‘how’ and means, let’s follow through on the logic here:

– If the organisation is ‘above’ the enterprise, we’re in effect saying that the means has priority over the ends. That kind of mistake is directly implicit in, for example, the ‘BDAT stack’ in most so-called ‘enterprise-’architecture frameworks at present, and is exactly what leads to the inane IT-centrism that occurs whenever we try to use those frameworks for anything other than IT-infrastructure (‘Technology’) architecture. Not a good idea…

– If the organisation is the same as the enterprise, we’re in effect saying that means and ends are inherently identical – that the ‘how’ is itself the ‘why’, the sole reason and purpose for the activity. This mistake occurs automatically whenever anyone conflates ‘the organisation’ and ‘the enterprise’ – which happens a lot in business in general. It causes self-centrism, self-obsession, and an automatic disconnect from customers, suppliers, market or just about anything else. Not a good idea…

– If the organisation is ‘below’ the enterprise, we’re in effect saying that the means are subordinate to the ends, the ‘how’ is subordinate to the ‘why’. This is the only way that works – and, as above, all of us already know this. (Though many of us still seem either to ignore it, or pretend that that fact does not exist. Again, not a good idea…)

The means is always subordinate to the ends.

The ‘how’ is always subordinate to the ‘why’.

The organisation is always subordinate to the enterprise.

This is the only way that works well. Any attempt or error which does not support that subordinate relationship – in other words, that attempts to place means, how, organisation equal to or above ends, why, enterprise – will cause failure.

Clear enough, I’d hope?

There’s one important addendum I’d make to that, about relative-distance to identify the total scope that we need for an enterprise-architecture. It’s pretty straightforward, and builds on the classic ‘Five Whys’. For this example, let’s start with the BDAT stack:

Assume that Technology-Architecture is the focus of interest – the ‘how’ or means for which we’re defining an architecture. As the ‘how’ or means, this also represents the actual ’the organisation’, for the purposes of this item of architecture-development.

In the BDAT-stack, the first ‘Why’ for the technology-architecture comes from the mix of Data-Architecture and Application-Architecture – what TOGAF describes as ‘Information-Systems Architecture’.

In this version of the BDAT-stack, the second ‘Why’ – the ‘Why’ for the information-systems architecture – comes from the Business-Architecture.

We might shuffle things around a bit, give priority to data over apps or apps over data, or place an intermediate Information layer below Business-Architecture, to give us a ‘BIDAT-stack’: doing so might use up one or two more ‘Whys’. Even so, that’d still leave us anything up to three more ‘Whys’ to explore, to give us the real depth that we need, ‘above’ the business-architecture. And if we describe the scope of that business-architecture in the colloquial sense as ‘The Organisation’ – as so many architecture-folks would still misleadingly do – then the full scope of what we’d need to explore would look something like this:

Note that ‘the organisation’ that we’re really working with in this case, for the Technology-Architecture, is not the one shown on this diagram as ‘the organisation’, but in fact some two or three layers deeper within this ‘the organisation’. (That’s a typical confusion that arises from a fractal approach, of course, where we correctly use the same name for the same type of thing, but where others use arbitrary different labels for different levels of that same type of thing…) Strictly speaking, that diagram above shows the scope implied from around three to four ‘Whys’ outward from what’s colloquially called ‘the organisation’ and its respective architecture of ‘the business of the business’. But that distance all the way out to ‘the shared-enterprise’ above is where a Five Whys applied to an IT-infrastructure architecture actually takes us – and is the enterprise-scope that we actually need for that architecture.

All of which brings back to this last part of Len’s first comment quoted above:

an enterprise cannot be realized except by an organization that is capable of realizing the entire enterprise

Straight away, it should be obvious that this makes no sense – at least, when we look at it in terms of the Five Whys description above. In fact, it’s a direct example of the second mistake described above, where the boundaries of ‘the organisation’ and ‘the enterprise’, of the ‘how’ and the ‘why’, are deemed to be exactly the same. Instead, and in practice, an enterprise is realised by any number of organisations, from zero – in other words, where the enterprise is not realised at all – to a potential infinity of organisations: ‘why’ may be realised by any appropriate combination of ‘how’. Remember, it’s fractal, not linear: don’t mix them up!

So, to wrap up overall:

  • the scope of ‘the enterprise’ identifies the overall ‘why’ for ‘the organisation’ – the remit of organisation and control for the respective item of architecture-work
  • as the ‘why’ for the respective ‘how’, and the ends for the respective means, ‘the enterprise’ must always be broader in scope than ‘the organisation’
  • applying a Five Whys to a given ‘the organisation’ leads us to a ‘the enterprise’ that is necessarily much broader in scope than ‘the organisation’ – in practice, typically at least three steps broader, and sometimes (often?) more

Makes a bit more sense now, I hope?