Tom Graves / Tetradian

Ends and means are not the same: everyone knows it’s not a good idea to mix them up.

The same is true of ‘enterprise’ and ‘organisation’. The enterprise represents the ends of what we do; the organisation is part of the means. It’s really important not to mix them up.

[Apologies, but this is another one where the words we use are really important: if we don't have the right words, we can't describe the concept we need. I'll use English here, where those two words 'enterprise' and 'organisation' can draw these distinctions: but in other languages we may have to use other words entirely to convey those same meanings. Let me know what you'd use in your language, perhaps? - thanks.]

The enterprise is the ‘why’ of what we do; the organisation is part of the ‘how’. Don’t mix them up!

The enterprise is about emotion, ‘the animal spirits of the entrepreneur’; often the whole point of the organisation is that it doesn’t express emotion. Don’t mix them up!

The enterprise is inherently about something uncertain; the organisation is all about making things certain. Don’t mix them up!

If we mix them up, we confuse ends with means; the ‘how’ becomes its own ‘why’, the pre-packaged ‘solution’ itself becomes the supposed requirement. Not a good idea…

If we mix them up, we apply emotion to things about which we need to be dispassionate – oh the joys of office-politics… – and fail to use emotion and drive to get things moving again in the direction that we need.

If we mix them up, we confuse ourselves about what is certain, and what is not; we confuse activity with direction; we confuse mere repetition with purpose.

If we mix them up, we end up with an organisation that has no enterprise, whose only real belief is a narcissistic obsession with itself, vapid, emotionless, devoid of meaning, purpose or reason. “An empty thunder, signifying nothing”: how well does that fit your own organisation right now?

If you want your organisation to have enterprise – an end or purpose that means something to everyone in the organisation – then you’ll realise just how important it is to maintain a clear distinction between ‘enterprise’ and ‘organisation’.

The organisation is not the enterprise; the enterprise is not the organisation.

They’re not the same: don’t mix them up!

[Update 05dec11: In a comment below, Stuart Boardman reminds me (thanks Stuart!) that some people here may not be familiar with the way I use the word 'enterprise'. There are several standard dictionary-meanings, but the one that's most useful here is from the early days of economics: 'the animal spirits of the entrepreneur' - the sense that aligns with the usual meaning of 'to be enterprising'.

For more details, perhaps take a look at the brief slidedeck 'What is an enterprise', up on Slideshare.

The content of slide 5 from this slidedeck there may also be useful for this:

Hope this helps, anyway.]

Had an interesting question come in today from one of my Dutch colleagues, Bas van Gils:

I have to write a document and I’m kinda stuck. Time to ask for some help I’d say

The issue with the document is that I want to make a distinction between ‘the organization as in: “the way in which some system / department / enterprise is organized” and “the organization as in: the legal entity”. I’ve had this issue before and I can’t figure out how to deal with this properly in documents. It just feels awkward to say Organization (with capital) for meaning one and organization (without) for meaning two…

Any thoughts?

This is a real doozy of a problem that really shows up the limitations of English as a language. It’s  hard enough for native English speakers to resolve, let alone those who only use English as a business-language…

I ain’t no linguistics specialist, but as I see it, the respective contexts for the two meanings are as follows:

• Meaning 1 (‘the way something is organized’): a nounal expression of the verb ‘to organize’, moving from the present-participle (‘organizing’) to the adjectival past-participle (‘organized’) to the verb-as-condition (‘organization’) [there'll be a proper linguistic term for this nounal form, but I haven't a clue what it is ]
• Meaning 2 (‘the legal entity’): a label for an abstract entity that is structured (‘organized’) in some defined way

To me, Meaning 1 is still more related to the verb, a temporary condition of something dynamic (“the act of organizing”), whereas Meaning 2 is definitely a noun, something static. In Meaning 1, the structure could change – the outcome of a ‘reorganization’ – and it would still be ‘organization’; whereas Meaning 2 is defined and delimited by its legal boundaries, so if those were to change, the previous ‘the organization’ would cease to exist.

[A quick check at AudioEnglish.net throws up a total of seven meanings: Bas's 'Meaning 1' is somewhere between their 1 ("a group of people who work together") and 2 ("an organized structure for arranging or classifying"), whereas Bas's 'Meaning 2' is probably closest to their 3 ("the persons or committees or departments etc who make up a body for the purpose of administering something"). The built-in thesaurus in MS Word isn't much help, either. Overall, it's all too obvious that English is a confusing mess. ]

I would probably try to juggle the phrasing so that I can avoid having to put the two meanings together in the same sentence, but I can see plenty of circumstances in which there’s no way to get round it.

If I did have to use both meanings in the same sentence, without any other option, I might well use Bas’s capitalisation kludge, though I would capitalise Meaning 2 rather than Meaning 1: “the organization of the Organization”. But as Bas says, it’s awkward and ugly: and whilst, to a native English speaker, the alternative uncapitalised “the organization of the organization” would probably be clear enough, it might not make sense to native speakers of other languages.

But as Bas again indicates, it gets messy when we try to distinguish the two meanings once we’ve bundled them together. And going back to the present-participle – “the organizing of the organisation” – is probably uglier still, although technically correct in English.

So the short answer is that I don’t see any easy way round this one. Sorry…

Anyone else have any better suggestions?

This one is a follow-up to a couple of comments by Pat Ferdinandi to my earlier post on “Annoyed at ‘Enterprise 2.0′”. I had explained in one of the comments that there’s a danger of a high-risk ‘term-hijack’ if conflating the terms ‘organisation’ and ‘enterprise’, because they’re not the same: ‘organisation’ is a legal entity – more accurately, an entity defined by an enforceable governance boundary – whilst ‘enterprise’ is a social entity, a collaboration towards shared aims and objectives that does not in itself imply or demand any explicit form of governance. In effect, an enterprise can be any subset or superset of the organisation:

From a business perspective, there are at least three layers of enterprise that are supersets of the organisation:

• partners/supply-chain;
• customer-base (and, in an E2.0 context, reviewers/critics);
• and broader community (e.g. reputation-management / CSR).

This latter point about supersets becomes extremely important in enterprise architecture and business architecture, because they’re outside the scope of direct governance of the organisation. If we make the mistake of assuming that the organisation is the enterprise, is a literally self-centric, self-referential ‘business architecture’ that has no connection with the real world – i.e. the ecosystem in which the organisation operates – which, in the mid- to longer term, usually leads to failure of the organisation. In other words, not a good idea… So we need to model that wider scope in our architecture.

Pat then remarked:

I will admit that I’m very business focused (ok biased).

Because B2B or any collaborative interaction between multiple companies (banks needing to share information/transactions or hospitals needing to share and transfer patient data) the EA needs to include both companies and may need to model the industry (including government mandated laws or reimbursement qualifications or negotiated rules).

These examples would be larger than the subset of the organization. Would this be your whole-of-enterprise? It fits the IEEE1471/FEAF definition.

My answer would be that whilst this is important, it’s still far too small a scope for a business-architecture or whole-of-enterprise architecture: in effect, just the first of those three layers above (partner/supply-chain context, including direct-impact legislation, regulation and standards). To identify the full depth of drivers that impact on the organisation from the broader enterprise, we need to model the other layers as well.

To model the customer-base context, it’s imperative to explore the shared vision held by all participants in the enterprise – in other words, the motivation that underpins the entire enterprise. Standards such as the Business Motivation Model can help here, though the BMM itself has some limitations that can be resolved via explicit extension – see my presentation on Vision / Role / Mission / Goal or the ‘Architecture on purpose’ chapter in Real Enterprise Architecture for more details on that. Perhaps the most useful hint here comes from ITIL Version 3: “customers do not want products or services – what they want is the satisfaction of a perceived need”. Focus on identifying the shared needs that unify all participants in the enterprise – your own organisation, your partners and suppliers, your customer-base and their social ‘quality-management’ context (anything from reviewers to critics and complaints), and the legal, regulatory and standards framework that applies to the servicing of those needs within that context. This describes the principles and drivers that you can use ininnovation-support, in customer-relationship management, and much else besides.

To model the social milieu context, explore the social expectations for any organisation or business operating in this context: issues such as transparency, fairness, environment, corporate social responsibility and so on. Do not forget to include these as drivers and themes within your architecture models, via techniques such as Vision / Role / Mission / Goal: failure to do so can cost you very heavily indeed, especially in the longer term. Also, be aware of cross-cultural differences: different cultures have different expectations and different demands, which can cause significant impacts, especially for organisations with a multi-national reach.

One useful approach is to view architecture as part of risk-management and opportunity-management. From that perspective, it should be obvious that a risk-analysis and matching opportunity-analysis would be incomplete if it fails to include the ‘bigger picture’; the same should hence also be true for architecture analysis, especially at the business-architecture orwhole-of-enterprise architecture scale.

Hope this helps, anyway.