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…
Thanks for bringing this thinking together to prompt better understanding and (hopefully) better engagement in exploring some of the more subtle issues around key terms, expressions, concepts, methods, practices, habits and governance associated with the discipline of enterprise architecture.
I would like to engage on a number of issues in a slow and orderly (to my mind but perhaps not to others) manner which allows time for reflection and exploration of different ways of looking at these issues. Each require time, attention, reflection, communication, openness, courage, humility – a willingness to challenge our own assumptions and biases (if we have a brain, we are biased) and explore familiar territory, but perhaps with a different map or a different set of eyes and ears.
Peter, thanks for this. I’ll engage below in the spirit requested.
I’ll just ask you to note how frustrating it is to go over old ground again and again and again, with what (to me) seem even the most elementary of points being repeatedly ignored, leading us round and round in circular loops. No doubt you’d say the same about some of my reasoning too. Oh well.
The first area that I would like to explore pertains to “enterprise” and “shared-enterprise”. I like and concur with all that you have said until I reached the following point around “shared-enterprise”.
… there’s some aspect of enterprise – the aim, the intent, the story – that is held not just by us, but by others too …
Where the aim, the intent and the story are held not just by us – not all of that is shared – each exists in a broader context that is different – if you and I were to engage in an enterprise – we will share an aim, an intent and a story (of the enterprise) which will be in the context of my aim and your aim, my intent and your intent, my story and your story – and whilst there will be some commonality (which defines the enterprise that we share), there will be some differences, too. The common part is the essence of the “enterprise” and does not need to be called “shared-enterprise” (imo). For me, shared-enterprise implies that the broader context is held in common – and it cannot and is not – my story and your story will always be different, but have some common touch points. Even at those touch points, my story (perspective) and your story (perspective) will be different.
I say this out of experience – both of engaging as a sole trader in an enterprise – and as one of three principals in an enterprise. (We don’t need to make it more complicated than that to explore particular issues here.)
So, I will pause … to listen for the different perspective that you are bringing and ascertain whether there are some hidden assumptions that I am bringing that stop me from seeing and hearing what you are seeing and hearing.
Peter – I’ll admit straight off that ‘shared-enterprise’ is a kludge. The correct term is ‘enterprise’ – if only because enterprise must always be to some extent shared if transactions and/or interactions on those themes are to occur.
The reason why I’m all but forced to use the ‘shared-‘ prefix is because I seemingly cannot get people to grasp the dictionary-derived concept of ‘enterprise’ as an emotive driver denoting scope (Adam Smith’s ‘the animal spirits of the entrepreneur’) without people getting hung up on the other, unfortunately-misleading concept of ‘enterprise’ as an indicator of scale, usually with an arbitrarily-constrained scope (hence ‘enterprise’ as ‘large commercial organisation’). Although the second version of the term describes what is, in effect, an outcome of a subset of the first version of the term, they represent fundamentally-different concepts, and blurring them together causes enormous difficulty when we need to make sense of the compound-term ‘enterprise architecture’. To put it at its simplest, does ‘enterprise’ first emphasise scope, or scale? (Yes, there’s a lot more to it than just that one distinction, but I’d suggest it’s a useful place to start.)
On “For me, shared-enterprise implies that the broader context is held in common – and it cannot and is not – my story and your story will always be different, but have some common touch points” – yes, though this is another point where we need to tackle the themes with a lot more precision than usual, otherwise the discussion becomes circular, really fast. (To illustrate this, take a careful look at your following-paragraph about “I say this out of experience – both of engaging as a sole trader in an enterprise – and as one of three principals in an enterprise”: exactly what definition of ‘enterprise’ are you using in each case there? In each case, what meaning of ‘enterprise-architecture’ would that imply? Is that the meaning of ‘enterprise-architecture that you actually intend? If not, then what does that say about the meaning of ‘enterprise’ that you would intend, versus your usage of the term as in that sentence above?)
So to parse that sentence about ‘shared-enterprise’ just above:
— “that the broader context is held in common – and it cannot and is not”: the context itself may not be so, because in effect it’s a sea of intersecting enterprises, of actors each with their own drivers and needs. Yet there is a region of commonality – the touch-points, as you say. And at those touch-points, there is enterprise which is shared – hence ‘shared-enterprise’.
— “my story and your story will always be different”: yes, of course. We could, for example, distinguish those differences as ‘non-shared enterprise’ – from the perspective of the organisation, and/or from the perspective of the other actor(s). Note, though, that even the ‘non-shared enterprise’ can have hige implications for would-be shared-enterprise – as we see in all manner of broader-scope themes, from anticlient-issues to impacts of global politics or environmental change.
— “have some common touch-points”: what exactly are those touch-points? What are the drivers – the respective ‘enterprise’, in that first dictionary-definition – in each direction? (For example, this is where Osterwalder’s work on ‘value proposition design’ comes into the picture.) From there, what are the expectations? – again in each direction. (For example, this is where the rules of a market – both as organisation and as enterprise – would come into the picture.) What drives the service-cycle from one stage to the next? (See e.g. http://weblog.tetradian.com/2013/04/29/ecanvas-and-service-cycle/ or http://weblog.tetradian.com/2014/10/15/services-and-ecanvas-review-2-supplier-customer/ ). Who else is watching that micro-story unfold? (See e.g. https://www.slideshare.net/tetradian/enterprise-architecture-a-matter-of-perspective – particularly slides 73-128.) To me, understanding and modelling all of those interactions and their drivers is what distinguishes enterprise-architecture from other forms of architecture used within the organisation.
On “and ascertain whether there are some hidden assumptions that I am bringing that stop me from seeing and hearing what you are seeing and hearing” – I would point you to your many usages of the words ‘enterprise’ in your comment above, and ask you to consider what exactly you mean in each case; whether they are indeed the same meaning in each case; and if not, what you might need to do to bringing more clarity into any needed distinctions between those usages.
Leave it at that for now? I hope this helps, anyway.
Aha! So shared-enterprise is a “kludge” – the correct term is “enterprise”.
Thanks for that. For me, shared-enterprise had to be something different – otherwise, why create it? So … if a reader understands “enterprise” well – then “shared-enterpise” becomes confusing!!
Thanks for explaining why you have gone down this path – as I am sure you realise – I understand the term – I do not make the false connections to scale – I guess that since I have been a soletrader applying my trade to my own enterprise – it has seemed pretty obvious to me that an enterprise can be of any size – and, as you know, operating in an SME dominated economy, I have always had a mind to the relevance and value of EA thinking and practices to organisations and the enterprise they pursue, without being bound to the “large organisation” assumption.
Sure – I said “in an enterprise” rather than “in an organisation pursuing an enterprise” – that is the nature of narrative, story-telling, talking conversationally – one does not create a stilted discussion through clinical precision of language. You know me well enough to know that I understand the distinction. And to presume that I don’t and needing to point it out and explain it, makes me wonder whether you know me as well as I had assumed you do.
As an aside – my partner has been going through a rough patch and sharing this with her mother. Her mother has been asking “are you alright / OK”. My partner answers that she is fine and coping well, with some explanation and evidence to support her assertion. Her mother asks again and again to the point of exasperation where my partner asks her mother “Don’t you believe me?”
correction … “one does not want to create a stilted conversation” …
Peter: “one does not create a stilted discussion through clinical precision of language” – that would be true, except that this explicitly is a context where the whole focus is on being precise with language.
I’ll admit that this random unannounced switching between modes is driving me beyond ropeable at the moment. If you ask me to be precise about definitions and the like, please do the same yourself – otherwise this has no chance of being able to work. When people fail to do that, all that it does is make me feel that that person is playing wrong-making games against me – which is certainly not conducive to considered exploration…
(Re your aside itself, yeah, that’s my daily experience here: eldercare for 95-year-old mother is is, uh, not easy, for exactly the reasons you’ve described… 🙁 If I sound more than a little short-tempered at times, that’s part of the reason why… 🙁 🙁 )
Here is a definition of enterprise that has been around for a while and aligns with your thinking: “Enterprise: one or more organizations sharing a definite mission, goals, and objectives to offer an output such as a product or service”. I then use M. Porter’s concept of a Value System.. an end to end network of organizations encompassing the supply chain, the central organization and channel partners to the end customer organization (including recycle / waste organizations). This allows the system of systems architectural approaches to describe the interactions of the constituent organizations and the technology they are responsible for. Then Each organization has a defined set of capabilities (M Porter Value Chain). All of this can be Described in an Enterprise Architecture Description.
This is just an alternative way to understand an Enterprise. Many managers are aware of Porter’s work and the concepts of supply chain and channel partners..
Thanks, Bruce – though I’ll warn that this is a bit problematic for me…
On “Here is a definition of enterprise that has been around for a while and aligns with your thinking: “Enterprise: one or more organizations sharing a definite mission, goals, and objectives to offer an output such as a product or service”. This definition is interesting, because although I can see its appeal to business-folk, it actually manages to combine, in one brief sentence, most if not all of the errors that I’ve been warning about… 🙁
— It arbitrarily constrains – in effect equates – enterprise to organisations. (A key point I’ve been warning about is that ‘organisation’ and ‘enterprise’ represent different concepts: a rule-bound structure versus an emotive story.)
— It implies that the purpose of all enterprise is “to offer a product a service” – i.e. an arbitrary constraint to or towards commercial organisations. (Another key point I’ve been warning about is that expression of enterprise may take many forms, many if not most of which are not ‘commercial’.)
— It’s goal-based – about which a classic warning is once we do achieve that goal, by definition it kills the respective enterprise stone-dead…
— It’s explicitly organisation-centric, ‘inside-out’ only: there is no concept of the ‘outside-in’ that makes even that constrained version of ‘enterprise’ commercially-viable, nor of the broader ‘outside-out’ context that provides the rules and drivers within which the commercial ‘enterprise’ takes place.
In short, if that’s the definition of ‘enterprise’ that business-folk do actually use, then yeah, there’d be no surprise that what I’ve been trying to explain either makes no sense, or goes straight over their heads. However, the danger of a definition so narrow, self-centric, limited and arbitrarily-constrained is that it renders invisible everything else about enterprise that is not included within its own bounds – including a wide variety of absolutely key concerns that make an enterprise work. Not A Good Idea…?
More to the point, if the common definitions of ‘enterprise’ are that far adrift from the actual, literal meaning of ‘enterprise’, or of ‘to be enterprising’, then what can we do about it to make it right? – to make it actually work, in a genuinely meaningful way?
The definition does in fact bring together a number of separate concepts. Enterprise, Organization, Product, Service, Mission, Objective, Goal. Each term must be defined individually and as an interacting set. They are all terms that are in use in the organizations that I’ve worked with.
My focus is on finding and using a set of terms / concepts that provide meaning to the people in an enterprise. I don’t hear ‘shared-enterprise’ as a concept in the contexts I work in .. I tend to think of ‘partnership’ or ‘internal service organizations’ (a Drucker term) when I hear the term.
I have been influenced by Len F and his work on Enterprise definitions. I also use (quick google search) “a project or undertaking, especially a bold or complex one” or Endeavour along with the definition above .. (they can be used synergistically). The terms around mission, goal, objective are standard terms in strategic and normal planning.. They also fit the context for discussions about architecture.
The words are important.
NOTE: I now have a reference set of language (my babelfish) that I can translate to the ‘in-use’ language of an enterprise. I don’t force any language on an enterprise or people. I am clear about my terminology and what it means.
Architecture Frameworks represent a ‘shared language’ for those who choose to use that AF that people can use to create architecture descriptions for a specific type of system.
Getting to a shared set of language is an underlying challenge.
Thanks, Bruce. I’d still assert that that definition is a great example of exactly what not to do with definitions, but best if we leave that one open…
I agree about the value of Len’s work – except that eventually we clashed hard on some of his views, which showed strong (to my mind, mistaken) over-influence from mainstream US business concepts, and that I still suspect were also strongly skewed towards keeping the Open Group community happy, regardless of the damage doing so could cause elsewhere. Sadly, we’d reached a somewhat final impasse shortly before he died, so there’s no way now to resolve it. 🙁
To me it’s clear we’re at a similar impasse, were some fundamental concepts still seem to be absent from your descriptions. For example, whilst goals and objectives can be valid in their own right, there is no valid way that they can or should be used as descriptors for enterprise itself – which is what the Porter definition does. A project or goal is in context of enterprise – not enterprise itself. That distinction is absolutely crucial to the validity of ‘the architecture of the enterprise’, and the organisation’s options for responses to and interactions with that enterprise. If we get that one wrong, we have no literal enterprise-architecture: all that we’d have is disjointed organisation-centric architectures with no proper anchor into broader context – which is definitely Not A Good Idea…
It’s the concept that’s crucial here. If you want insist on calling it by some other label – FRED, for example, ‘Fantastically Robust Emotive Design’ – then go ahead. But that would mean (as is often the case right now…) that the term ‘enterprise-architecture’ becomes essentially meaningless, based on a core term without any robust definition. (You’ll note, by the way, that nowhere in the TOGAF specific for ‘enterprise’-architecture do they actually define the term ‘enterprise’.) Again, definitely Not A Good Idea…
I get so frustrated about this. To me all of this should be blindingly obvious right from the get-go, for everyone involved in any way in anything that calls itself ‘enterprise-architecture’. And yet even with you and Peter, it’s painfully clear that still I’m not getting through this wall of marshmallow that is corporate-centric thinking. It’s not about the frickin’ corporation’ – it’s about the context within which the corporation operates: how many ways will I have to reframe this before this at last makes sense?
I give up. I really do. It’s clear it’s a challenge that’s beyond my ability now. Oh well.
One last thought, to really solve this debate that has been going on for many, many years, the systems that are being architected really need to be examined.
The enterprise as a sociotechnical system which includes people and can have an enterprise architecture that brings together a team of people that understand the enterprise and the overall objectives including IT architects.
The IT, however, can be seen as a system of systems in its own right as a collection of tools that automate the Enterprise. This is a separate system of systems with a separate team to create an Enterprise IT architecture description. The key input to the IT architecture team is an enterprise architecture description. This approach can also be used for any other technology used in the Enterprise (e.g. aircraft, houses, food production, etc) where they each have their own architectural team and architecture frameworks.
Having one approach to the enterprise and IT makes less sense today given the way IT is being moved into the cloud or the IoT or our hands. Having a single enterprise architecture framework along with separate IT Architecture Framework might make more sense in today’s fast moving IT landscape. Both teams need to be able to respond quickly due to meaningful disruptions. The Enterprise Architecture Descriptions may remain stable longer than a set of optional IT Architecture Descriptions.
It is a lot easier to make architecture frameworks for a single type of system and single stakeholder team rather than the older multi-system architecture framework approaches that fail to gain stakeholder commitment.
Thanks again, Bruce. To answer this one fully would take far longer than I have available right now. Probably the simplest way to put it is to pick up on two points:
— the kind of enterprise we’re most usually talking about here is indeed a sociotechnical system
— the kind of ‘enterprise’ that’s most commonly discussed in IT-centric ‘enterprise’-architecture is primarily a ‘technical system’ (as distinct from a ‘socio-technical system’) and where ‘enterprise’ is a descriptor primarily of scale (bounded by the organisation) rather than scope (context-descriptors)
The former is a descriptor of a context, bounded by a shared-story; the latter is more a descriptor of content.
The former aligns well with the combined set of dictionary-definitions for ‘enterprise’; in most cases the latter aligns solely with the Porter-style ‘enterprise as large commercial organisation’ definition for ‘enterprise’, as per your previous comment.
The latter is why we have the absurdity of so much of current so-called ‘enterprise’-architecture, in which ‘enterprise-architecture’ is deemed to be both inside and outside ‘business-architecture’, and ‘business-architecture’ likewise both inside and outside ‘enterprise-architecture’… http://weblog.tetradian.com/wp-content/uploads/2017/07/bdat-ea-ba-ea.png .
It’s a mess. We urgently need to stop pretending that it isn’t a mess, and instead properly clean up the darned mess so that we can move on to get this right…
I do agree with many of the problems you identify. I would not post my thoughts unless I thought they were in line with your thinking.
(for example, the definition I shared in my mind separates the “Why from the how” of the enterprise).
Words and our mental models seem to be getting in the way when in reality I believe we are very close.
If you have any thoughts on how we get past these types of differences, let me know.. I’ll do the same ..
Many thanks. This is not a new problem. The key is really understanding the current problems and providing a solution to address these problems. This implies that something changes. The change equation is a useful way to see change.
I have always viewed my work so far as a ‘prototype’ or work in progress. I use what I know today and learn and change based upon experience / feedback. I’m on my eleventh attempt to understand this space and have used the various approaches many times and now refined them many times.
I’m always open to a 12th version (starting over if necessary).
What are the problems? What is the mess? What part do we play in this? (I’m probably part of the mess from your perspective as I have chosen to use definitions that don’t fit in your solution space).
Next steps??? I do like your videos..
Tom – you are the person who introduced “shared-enterprise” so that carries with it an obligation to convey the distinction between “enterprise” and “shared-enterprise”, especially for those of us who already understand “enterprise”.
Since I don’t use “shared-enterprise” and see no need to use the term, I have found a way to use “enterprise” and to be alert to when others may not be appreciating the distinction between the different uses of the word. This, of course, is normal in any conversation where a word has more than one meaning.
As you know, my aim is to communicate simply and plainly with business people – I find that the introduction of new terms makes things more complex and more difficult, rather than making it simpler and easier to understand – I operate on the basis that it is better to explain the distinction and the significance of terms that already have clear, but multiple distinct meanings.
Creating the term “shared-enterprise” seems (to me) to create more work and more effort – but that is the perspective of someone who understands the distinction between enterprise = undertaking vs enterprise = organisation wide 🙂
On “switching” …
We humans do this all the time. There is no ill-intent involved.
If the EA profession cannot operate in a world of multiple meanings, changing use of terms, discerning intent and meaning from naturally flowing, conversational language – then we have a lot of maturing to do – creating a new language-set will not solve the problem – it will alienate us from business people rather than strengthening our connections, our collaborations and our offering of value.
Reflecting back on some of the discussions here, I see the following statements as limiting and potential sources of difference in meaning and understanding …
Tom – I can’t get people to understand enterprise as an emotive driver denoting scope (Peter – I don’t experience that problem)
Tom – It arbitrarily constrains enterprises to organisations (Peter – perhaps you are constraining “organisation” too much?)
Tom – organisation as rule-bound versus enterprise as emotive story (Peter – perhaps you are constraining “organisation” too much? I don’t operate within the limits of the assumption you have expressed)
Tom – It implies that the purpose is to produce a product or service – an arbitrary constraint towards a commercial organisation (Peter – perhaps you are constraining your concept of product or service too much?)
Tom – It’s goal based (Peter – you seem to be constraining your concept of goal too much – it is quite feasible to establish a goal that is never realised yet is aspirational and motivating, such that the organisation and the enterprise it pursues are never killed stone-dead)
Tom – It’s explicitly organisation-centric (Peter – all successful organisations are outward-looking not inward-looking, so that do not suffer the limitation you are expressing – take, for example, VSM or any systems-based view which obligates an entity to consider the organisation-as-part-of-the-system(s)-in-context. Context and content (external and internal) are an inherent element of organisation-as-system and enterprise-as-system for which we express architectures.)
Tom – It’s about context and not content (Peter – It is interesting that you perceive that neither Bruce nor I understand that – we both appreciate that completely – I wonder why you think we don’t understand that?)
My scope is IT infrastructure and I wouldn’t call myself a Enterprise Architect 🙂
In my designs I have to deal with different business units, other companies (e.g. suppliers of Cloud platforms), government (regulation), non-clients/prospects etc. The focus or me is how they can interact/communicate by using IT.
Anyway for me architecture can make the world more beautiful but infrastructure changes the world 😉
To me the correct descriptor for what you do is Dana Bredemeyer’s term ‘EWITA’, ‘Enterprise-Wide IT-Architecture’. It’s correctly ‘enterprise-wide’ in that it extends not just throughout the organisation, but beyond it as well – as per your note about “I have to deal with different business units, other companies (e.g. suppliers of Cloud platforms), government (regulation), non-clients/prospects etc”.
‘Enterprise-Wide IT-Architecture’ is a perfectly valid term, and causes no harm to anyone else. The problems started when some idiot got lazy and shortened ‘Enterprise-Wide IT-Architecture’ – which it is – to ‘Enterprise Architecture’ – which it isn’t. Or rather, that EWITA is just one small subset within EA – and when a subset pretends to be the whole, and strives to block out everything but itself, bad things will always happen. 🙁 Oh well…