Peter Flemming T. • It only matters if we benchmark.

Richard S. • It doesn't matter what is done under the "banner" of enterprise architecture. It does matter if those doings act as an enabler or inhibitor to the delivery of value to the broader organization.

Rob A. • I think you sum it up well in the penultimate sentence of your second paragraph where you talk about "what we regard as interesting, relevant and useful...". However, perhaps the real focus should be on what is of interest, relevance and use to the Enterprise, and to the Enterprise as a whole, not just a small part of it. If it passes that test, why not call it Enterprise Architecture, if it doesn't then let's not devalue the title.

Tom G. • The literal meaning of 'enterprise-architecture' is 'the architecture of the enterprise'.

The word 'enterprise' is a blurry kind of term, so there are always going to be _some_ confusions there.

It probably doesn't matter much when people extend the scope, other than that it could cost more in time and effort if we're not careful.

It tends to matter somewhat when people reduce the scope, because we cut out potential connections and risk missing out on essential information that we need for a viable architecture.

It tends to matter a _lot_ when people not only reduce the scope, but then pretend that that narrower scope _is_ the whole of the scope, because the result is that not only do we miss out on any means to describe essential connections, but would-be clients and even practitioners get really confused about what is or isn't enterprise, or architecture, let alone enterprise-architecture.

That's exactly what happened with TOGAF and FEAF and the rest of the 'classic' IT-centric 'enterprise'-architectures: what they _meant_ was 'enterprise-wide IT-architecture' or 'the architecture of the enterprise-IT', which is a much narrower scope than 'the architecture of the enterprise'. But by insisting that the IT alone is the whole scope of 'enterprise-architecture', we're left with no term to describe the remainder of 'the architecture of the enterprise'. Which non-IT 'remainder' happens to be around 90-95% of the enterprise, according to Open Group's Len Fehskens. Oops.

So no, it doesn't matter much, and yes, it's almost literally a matter of life-or-death. Depends on the context, really.

Pallab S. • Well said, Tom.

I am glad to see so much in common between our thinking in the "six reasons........" discussion and Len's comments in The Open Group Blog. I am sure it comes as a shock to current EITAs (passed of as EAs) to know that despite all their rhetoric and current statistics, they cover only about 5% of what construes the entire enterprise.

Richard V. • @Rob. I fully agree that the real focus of #entarch should be on what is of interest, relevance and use to the Enterprise. But a telescope doesn't cease to be a telescope, and a camera doesn't cease to be a camera, if the user fails to focus it on something interesting. Moreover, a photograph is still a photograph even if it is blurred and ill-framed.


So I don't see why something should fail to count as enterprise architecture just because it doesn't satisfy some context-dependent (and probably subjective) notion of quality and fit-for-purpose.

Richard V. • @tetradian identifies three risks

(small) when people extend the scope it could cost more in time and effort

(medium) when people reduce the scope we cut out potential connections and risk missing out on essential information that we need for a viable architecture.

(large) when people not only reduce the scope, but then pretend that that narrower scope _is_ the whole of the scope, stakeholders get really confused about what is or isn't enterprise, or architecture, let alone enterprise-architecture


It seems to me that managing these risks calls for different levels of clarity.

Tom asserts that the third risk is the greatest of the three, but that's exactly the point that I'm challenging. Of course there is confusion, often propagated by precisely those elements whose raison d'etre is to remove such confusion. But does that really mean we would be better off if TOGAF did more, or would it be better if it did less?

The first two risks are practical ones about managing the architecture activity. Of course architects need to work in teams, and to accept some direction about the content and scope of their work, but competent management is going to define content and scope precisely for a specific job, rather than assume that content and scope can be inferred from some standard definition and a set of generic principles. In other words, defining "enterprise architecture" is not going to address these risks.

Pallab S. • Below are four statements by Len Fehskens:

1. The key to a truly enterprise-centric concept of EA lies inside that black box labeled “the business” – a black box that accounts for 95% or more of the enterprise.

2. If so, will we be honest about this IT focus and will the potential for EA to become a truly enterprise-wide capability be realized?

3. Enterprise architecture ought to be about the entire enterprise, because that’s what the name implies. If it’s really about IT, it ought to be called enterprise IT architecture. Whether or not you believe it’s possible or desirable to apply architectural thinking to the entire enterprise doesn’t change the fact that we ought to name things honestly. And when we name architectures, it seems reasonable to me to expect that if an architecture is implemented primarily in the <x> domain, it ought to be called an <x> architecture. Adding two more syllables (IT) to the seven (en-ter-prise ar-chi-tec-ture), or inserting two characters (IT) in the acronym (EA), isn’t an unbearable burden. Say it – “enterprise IT architecture.” Spell it – “EITA.”

4. This leads me to propose that a good definition of EA ought to be expressed without the use of the words "business" or "IT".

If we connect the dots, the underlying message is absolutely clear. That said, for some current IT Architects the shift is too big to fathom and digest. Hence I expect them to fight on for some time to come. Recall the "six reasons....." discussion.

Emeric N. • Agreed. Too much endless talks about "what is or isn't Enterprise Architecture". That's why I choose to stop spending time on writing/reacting on this kind of topics. I'd rather practicing it than trying to convince some who don't want to be convinced of what should they do.

Tom G. • @Pallab - I'm very happy that we agree on this. :-) - many thanks!

@Richard. Okay, I take your point re "that's exactly the point that I'm challenging". So perhaps let me rephrase and reclarify more exactly what I see as the real problem here?

To me the real problem is not IT-architecture. IT-architecture is a very necessary scope for someone, and TOGAF and FEAF and the like do handle it quite well. There are a fair few detail-layer concerns about how well it each does Its IT-architecture - what's missing and so on - but those needn't concern us here.

The real problem is not whether IT-architecture is or is not enterprise-architecture. Clearly it is a necessary part of most enterprise-architectures, though whether it or is not essential in absolutely all enterprise-architectures is a minor quibble that need not concern us here.

The problem that really _is_ important is not having a term available around which to anchor key concepts. In English, for example, the term 'the architecture of the enterprise' provides a very useful anchor for all manner of ideas and activities and principles and governance and suchlike around 'structures and stories about how to do enterprisingness'. Without a term like that, we have little or no means to describe the related concepts - and that can make things very hard when we _do_ need to describe those concepts.

(Yes, sure, 'enterprisingness' is an ugly term that I've just made up, and also somewhat blurry, in the classic English way. Yet paradoxically it's precise _because_ it's imprecise: most English speakers would know that I mean something around the 'get up and go' that drives business and social endeavours; and the blurriness of the term identifies a specific _type_ of scope without requiring any exact definition of that scope.)

There are (at least) three sub-problems here. One is that we may not have a term at all - which is one reason why new words get created all the time.

Another is (mis)translation. We may not have the right word in our own language, so we borrow from another - but then risk missing the point of the term in the translation. For example, the Welsh term 'hiraedd' and Portuguese 'fado' are both translated into English as 'homesickness' - but whilst sort-of correct, the translation misses both the inevitability and the sheer _intensity_ of the original meaning, and often its true scope as well.

A third form is scope-compression - where a term _seems_ to describe the scope we need, but actually doesn't. Sometimes this arises from inadequate translation, or concept-match in translation: for example, we've been struggling for some while to find a suitable word in Latin-American Spanish or Portuguese that _does_ carry that English sense of 'enterprise' in relation to business and organisations: 'empresa' is just a business, and likewise 'entreprise', without any explicit 'enterprisingness' about it. But _within_ a given language we also have scope-compression caused by 'term-hijack' - and that's where so many of our scope-problems around 'enterprise-architecture' arise.

A term-hijack occurs when a powerful or influential group assert that a subset of the natural-meaning for a term is the only possible meaning of that term. 'Economics' is probably the most extreme example: it literally means 'the management of the household' (hence the strange tautology of 'home economics'), but at global scale the scope has been compressed to dealing solely with money and trade - making it all but impossible to describe the scale-equivalent links to what we now have to describe as 'the environment' and the like.

Sometimes a term-hijack is intentional - as in Orwell's not-so-fictional 'Newspeak'. More often, though, a term-hijack arises when someone places their own small sphere of interest as being 'the sole centre of the world' - which has clearly been the case with IT-architecture describing itself as 'enterprise'-architecture.

[more]

Martin H. • I agree with the broad thrust of this discussion. And I guess this angle is all very well if you are a) already a practising EA, b) a CEO looking to leverage insights from the discipline, or c) a strategy-level person in a role that might encompass some of what the discipline might do.

What's not helpful about it is in the area of nurturing the EAs of the future and helping them get into those positions in the first place. Most "EA" jobs are still technical architect jobs:
http://www.jobsite.co.uk/cgi-bin/advsearch?search_type=quick&location_within=20&fp_skill_include=enterprise+architect&location_include=&annual_hourlyreqd_salary_low=annual&reqd_salary_low=ANY&reqd_salary_high=ANY&jobtype=E&daysback=7

It's like medicine: it's a thing (the medicine itself), a taxonomy of knowledge (eg Grey's anatomy), a set of procedures (surgery, general practice etc) and a host of well-defined disciplines (GP, consultant, nursing etc). We seem to be good at the first 2 things, reasonable at the third, and rubbish at the fourth.

Tom G. • [continued]

There's also an adjective-versus-noun confusion here, or scale versus scope: 'enterprise' as adjective describing the scale of something else - as in 'the architecture of enterprise-scope IT' - versus 'enterprise' as noun, as scope - 'the architecture of the enterprise', where the enterprise _itself_ is the context and scope. That too can be a cause of unintentional term-hijack.

Term-hijacks are lethal, because they block out all other aspects of the real scope. The term tells us we're covering a much larger scope than we actually can do with the tools that attached to the term. _That's_ the problem that we have with TOGAF and the like: they work well enough for the scope that they actually mean - enterprise-scale IT-architecture - but they _don't_ have tools to cover the _actual_ implied scope of 'the enterprise', in fact most of their tools _prevent_ us from looking beyond that narrow subset of IT. (Try describing a fork-lift truck or physical package or person-to-person relationship or even the physical building of a data-centre in the TOGAF metamodel: there's no way to do it. That's what I mean by 'scope-compression' - everything outside of the 'permitted' small subset of scope is rendered invisible.)

@Richard: "But does that really mean we would be better off if TOGAF did more, or would it be better if it did less?"

Either would do, really. (Realistically, given that Open Group is an IT-standards body, 'less' would probably be wiser than 'more'.) But it _does_ have to be one or the other: we can't continue with the present term-hijack mess.

Tom G. • @Martin: "It's like medicine: it's a thing (the medicine itself), a taxonomy of knowledge (eg Grey's anatomy), a set of procedures (surgery, general practice etc) and a host of well-defined disciplines (GP, consultant, nursing etc). We seem to be good at the first 2 things, reasonable at the third, and rubbish at the fourth."

I'd say that, relative to 'the architecture of the enterprise', most of the 'EA' discipline is still rubbish at all of them. We haven't even a decent understanding of the scope as yet: and because we haven't, we have inadequate taxonomies, some procedures that are being used completely out of context and others that are entirely missing, and disciplines claiming to work in areas for which their skills are entirely inappropriate. In short, it's a mess - and we need to stop pretending that it isn't.

I'll use your medical analogy here. Back in the earlier part of last century, the medical profession was a lot less well defined than it is now. There's a real case of a an ambitious man who started out as a veterinary surgeon, then moved sideways into (human) surgery, and then again into psychiatry - he ended up running a very large psychiatric hospital in one of the cities in central England. He was convinced that all psychiatric illness was caused by septicaemia, and hence, "as a precautionary measure", removed the tonsils and teeth and various other items of all patients in his so-called care. (We suspect that this was because his position of 'authority' allowed him to do minor surgery as he pleased, with no-one actually able to stop him from doing so.) In short, inadequate definition of scope, hence ludicrously-inadequate taxonomy, with wrong procedures and wrong skill-set for the actual context, leading to a seriously nasty mess that he still presented, to the end of his days, as a 'success'.

Is that medical mess any much different from the kind of messes that we see created by most current IT-centric 'enterprise'-architecture or 'business-process reengineering' and the like? Not really...

So we have a long way to go. And the first step is getting clear on the _real_ scope that we're dealing with here - which would then indicate the real scope of the taxonomies, procedures and disciplines that we need for a real 'architecture of the enterprise'.

René S. • EA is the taxonomy of the entire enterprise, IT or not. You are able to explain why a company exists and where things go wrong (current state). Knowing this you must be able to vision the future state of the organization, in all its expects to make it a better place  here comes practicing EA, not explaining it. Creating continuous improvement throughout the entire enterprise  EA is doomed if you are trying to explain EA to your organization or your customer! Use EA as a component in your (soft skill) toolbox, and in your presentations and advice do not mention architecture at all, and then you might have a shot…Also do not follow EA frameworks (Togaf, Dragon1, etc) to the letter, you do not want to become an EA purist

I have never met a Project Manager who explains Prince2 to me…
I have never met a Governance Manager who explains Cobit to me…
I have never met an Infrastructure Manager who explains ITIL to me…
I have never met an Information Manager who explains BiSL to me…
Etc

They all are practioners

Tom G. • @Rene - Agree re not always a good idea to try to explain to others, but we do at least need to be able to explain it to ourselves! :-)

Most project-managers etc have a fairly clear idea of what they do, and why, and the nominal and actual scope and scale of what they cover. Yet in EA we don't even seem to be able to get that far at present.

As for what term we should use to describe what we do, I honestly don't care. In terms of natural-meaning, it's true that the term 'enterprise-architecture' _does_ match best to the scope and scale implied by 'the architecture of the (extended)-enterprise' and so on. Yet we could just as easily call it 'Fred' rather than 'enterprise-architecture', as long we have _some_ agreed sense that this 'Fred'-or-whatever-it-is _does_ cover the scope and scale required.

But again, we don't even seem to be able to get that far at present. And I honestly don't why we can't: it's not _that_ hard a challenge, surely?

Sigh.

René S. • @Tom, agree on most aspects. What I did (and do) is first visualize the current state (using EA models :)) of the enterprise in all its expects: people, products (why the compony exists!), process, governance etc. The next step is to analyze where the flaws are, the most of the time this will be in the governance and collaboration area. Think about customized EA-products to overcome these flaws and also create EA-govervance (business, information and technical architecture functions) to implement these products (mapping strategic, tactical and operational layers). Now you are leaving the safe area of current models such as Togaf, these new custom EA products are customized to this enterprise only

The challenge is that you must convince al kind of stakeholders on all kind of levels! Do not do this by explaining your analysis; instead use this analysis by visualizing the future state (the better place!) and give it a name (for example service decision support, do not use architecture). Create a story board of this new and better future state. Let your stakeholders believe that they become more successful in their jobs and they can benefit from it…. Maybe and maybe you might have a shot to an explicit architecture (most companies have an implicit architecture), which consists of architecture functions and architecture products

And I know, this is practicing EA in a tiny nutshell, someone should write a book about it :)

Geoff E. • Hi Guys,

In interesting discussion. I assume the purpose of an EA is to reflect what the organisation does and perhaps equally as important reflect what an organisation could do. In this respctive I would argue that an EA has to mirror the resource based view of the firm (resources and capabilities model of business strategy) which is concerned with current and future capabilities. In this sense an EA is very much a conceptual and context model

However very much like the systems thinking debate we still have to avoid the three traps of

Holism & Pluralism
Dogmatism
Reductionism

Richard V. • @Tom

Perhaps you are right that a proper and commonly understood term would provide "a very useful anchor for all manner of ideas and activities and principles and governance and suchlike". But useful is not the same as essential.

I don't go along with your statement that term-hijacks are lethal. You talk about economics: it is certainly true that most so-called economists used to take a fairly narrow view of the subject, and perhaps many stlll do. Then along came people like Amartya Sen, who led economics into paying attention to a broader set of issues. Are many people sitting around arguing that economics is dead, or debating the meaning of the word?

I agree with you on many of the issues you identify, but I see the lack of an agreed term as a symptom and not the root cause of the problem. I am therefore less motivated than you obviously are to devote energy to sorting out the term, but I am happy to work on the other issues.

Richard V. • @Tom

I think we can draw different conclusions from your medical example, You seem to think it demonstrates the need for clearer delineation of medical roles, with stronger barriers to entry for unqualified people. But fully qualified doctors have also done some pretty appalling things, and defining "medicine" is neither necessary nor sufficient to prevent such things happening. I think your example demonstrates instead the need for evidence-based practices and stronger accountability and governance.

As it happens, I think enterprise architecture would also benefit from evidence-based practices and stronger accountability and governance. Surely this is more important than worrying about the meaning of the term?

Tom G. • @Richard - please, you seem to be doing an awful lot of assumptions about my opinions here, and even of what I've said. Sigh...

"I see the lack of an agreed term as a symptom and not the root cause of the problem." - why do you think I believe any different? As I said several times above, I'm not that concerned about which term to use. What I _am_ concerned about is when a subset-usage of a term - or of an entire discipline - actively prevents us from working the whole of the required subset. That's the point that Len was making; that's the point I was making; that I believe is the point Pallab is making; that's the point that you yourself have made many times. So why are you assigning such an absurd straw-man to me, and me alone? Sorry, but this just doesn't make sense.

"You seem to think it demonstrates the need for clearer delineation of medical roles, with stronger barriers to entry for unqualified people." Nope - that's your interpretation. (The person concerned was my grandfather, by the way: not a happy legacy...) Since he was fully qualified in all three disciplines, to me that kinda illustrates the risks and inadequacies of many certification-schemas...

"I think your example demonstrates instead the need for evidence-based practices and stronger accountability and governance." Yep - agreed. Perhaps even more, it demonstrates the very real need for an ability to _think_ broader than the immediate scope, to _listen_ to others' concerns, to acknowledge that evidence may take many forms, and above all to admit the possibility that we may be wrong - none of which were much in evidence in my grandfather's repertoire, and which is why I work darn hard to include them in mine...

'Nuff said, I think?