Enterprise effectiveness
Enterprise-architecture is dead.
As a term, anyway.
Although it had been dying for quite a while, we do have some certainty now about when it died; we know how it died, and even why it died. And whilst some of us may hope that there might yet be some way to revive the corpse, reality is that it just ain’t gonna happen now – or at least not within any kind of timescale that we’d need. Oh well.
The problem, though, is that we don’t have any other term that would do that job: nothing else that would mean the literal ‘the architecture of the enterprise’.
Some have pushed for ‘Business architecture’ as a possible substitute. But it doesn’t have the same meaning: it’s literally ‘the architecture of the business’, not ‘of the enterprise’ – and despite some people’s assumptions, ‘business’ and ‘enterprise’ are not the same thing. In part because of that, business-architecture tends to focus too easily upon commercial concerns alone, ignoring all other forms of enterprise. Hence, to use an old quote, “Close, but no cigar”.
Then there’s ‘Enterprise Design’, promoted by Milan Guenther and some others. I can see why folks might push this – at least it has ‘enterprise’ in the term, and it is related to architecture. The catch is that architecture and design are not the same: it’s the same spectrum, but they point in opposite directions – architecture ‘upwards’ toward a family of options, design ‘downwards’ toward a single option. So again, “Close, but no cigar”.
The only term that would work properly for this is ‘Enterprise-architecture’.
Which we can’t use any more.
Bother…
Yet how about we look at this from a whole other direction?
Instead of squabbling over a label for what the discipline is or does, why not focus instead on the outcomes of the discipline?
And in that sense, what this discipline really exists to do is to help create greater effectiveness across the whole of an enterprise.
Or, in short, enterprise-effectiveness.
The nice bit is that we don’t even need to fight about the meaning of ‘the enterprise’. Whatever the scope and scale, it’s still ‘the enterprise’ – the same desired-outcomes still apply, whichever way we choose to define ‘enterprise’ itself. A lot simpler, really.
And ‘effectiveness’? – well, there might be a few minor arguments over definitions, but in essence that’s straightforward enough too. For example, to keep it simple, I define effectiveness as the intersection between five main themes: efficient, reliable, elegant, appropriate, integrated. There are a fair few nuances, of course – perhaps in particular that efficiency is a subset of effectiveness, and not a contrast to it – but in essence that’s probably all that we’d really need to start on.
Hence, for example, we can take even an overly-simplistic strategy-tool such as SWOT, and refocus it towards enterprise-effectiveness. That should give us something such as SCORE – Strengths, Challenges, Options, Responses, impacts on Effectiveness:
Following the principles of the enterprise-architects’ mantra, we start off by accepting that we don’t know; then we explore the interdependencies, iterating back and forth between each of those SCORE themes until we have ‘just enough detail‘ on which to build the decisions that we need. It’s still simple, yet it’s not simplistic – a very big difference, and a powerful difference too.
So perhaps take a look at your existing tools, methods and frameworks for enterprise-architecture, business-architecture, enterprise-design or whatever, and think about what would happen if you reframed them in terms of enterprise-effectiveness. What difference would it make? For example, would it make it easier to ‘sell’ to executives and suchlike?
Comments / responses / suggestions, perhaps, anyone?
Effectiveness architecture?
Yes, in a sense – except that I’m trying to avoid the ‘A-word’, because it’s been so much ‘poisoned’ by the IT-obsessives that business-folk won’t go anywhere near it… 🙁
Hi,
I really like it! I find it much easier to use with C-people as “Architecture” doesn’t mean anything for them. On the opposite, “Effectiveness” conveys the idea of LEAN which is well known (and accepted).
Regarding “Enterprise (IT) Architecture”, I once met someone who struggled to explain what it was and at the end renamed it “Business/IT Alignement”. Not so bad in this context.
Thanks, JB!
And yes, as I just said to Alexander above, one of the main aims – and advantages – of avoiding ‘the A-word’ is that it makes it much to explain to execs what it is that we do.
(I need to write a follow-on blog-post to go into a little more of the amended sales-pitch, but even this small part works much better for that purpose than ‘Enterprise-Architecture’. Sad but true… 😐 )
Hi Tom,
I like. Funny thing is, the more I’ve avoided using the “A-word” with “the Business”, the more they seem to want to use it! I’m now being asked by the COO to develop a Smart Grid – Distributed Intelligence architecture. Most importantly, he sees this as important intellectual property for the business that will help us be technology vendor neutral. He also understands that the “architecture” needs to cover People (Values/Trust), Policy, Process and Technology.
Enterprise Effectiveness would work well as a label to describe what my colleagues and I do – much of which is more like internal Consulting/Facilitation than TOGAF-like EA.
I also like the less grandiose job title implied – maybe: Enterprise Effectiveness Advisor rather that “Enterprise Architect” (which has virtually no meaning at all according to job adverts)!
Cheers,
Nigel.
That’s a really good point, Nigel – that if we try to push ‘the A-word’ onto others, it doesn’t work, but if they claim it as their own, it does. (And yes, I’m noticing that, increasingly, people outside of IT understand the literal ‘the architecture of the enterprise’ much better than the IT-folks do…)
Likewise re “would work well as a label to describe what my colleagues and I do – much of which is more like internal Consulting/Facilitation than TOGAF-like EA”.
And yes, taking out the implied grandiose vacuity of those ghastly ‘Gosh You Too Can Be Important As The SomethingOrOther Architect‘ job-adverts would really help, too…
Very useful – thanks again!
Tom, thanks for this article. While I agree with the core arguments I see “enterprise effectiveness” as the ultimate goal of “enterprise architecture”. The emphasis tends to stray towards “enterprise description”, resulting in massive overheads that may not always be relevant to the effectiveness objective. Nevertheless, in order to achieve effectiveness there is some minimal set of description required to inform the process and validate the outcomes. Perhaps this minimal set varies per project. Hope to read more!
@Philip: “I see “enterprise effectiveness” as the ultimate goal of ‘enterprise architecture'”
So do I. The point of this post is that there’s so much confusion around the meaning of ‘enterprise-architecture’ that it’s easier, and probably wiser, to refocus our attention more on the outcomes than on the means via which we get there.
@Philip: “The emphasis tends to stray towards ‘enterprise description'”
Yes, agreed, that’s been a huge problem, leading to a huge amount of wasted effort, as you say. This does unfortunately seem to be an all-too-typical effect of most current ‘EA’ frameworks: TOGAF is not good on this, but DoDAF, for example, essentially does almost nothing else. We need to keep the focus on the real outcomes of improved effectiveness, rather than, again, the means via which we get there.
@Philip: “in order to achieve effectiveness there is some minimal set of description required to inform the process and validate the outcomes”
Yes, there is. The trick – as every experienced enterprise-architect will know – is to find the right balance, the right ‘Just Enough Detail’. And I’d also agree with your note that “Perhaps this minimal set varies per project” – because, yes, there’s a crucial “It depends” throughout all of this, and, unfortunately, the frameworks don’t give much if any guidance on how to find it.
@Philip: “Hope to read more!”
More coming over the next few days, if sanity and work-overload would permit? 🙂
I’ve just branded myself Consulting Enterprisographer. I think I’m the first ever. This by no means includes everything that anyone has ever tried to stuff into the portmanteau of EA. But it gets to the heart of a unique value proposition that doesn’t step on the toes of other professions and disciplines.
I can hear the trending clamor for certification rising in the background. Queue starts here, no pushing, no cutting in line!
Uh… certification??? You’re jokin’, right? 🙂
(Yes, I know, I’ve ranted rather too much about ‘the over-certainties of certification‘ etc, but even so… 🙂 )
Yes. I’m joking about certification (on a role that I just made up) 🙂
I am serious, though, about a focus on using a whole range of tools and concepts to be able to see many views, from many viewpoints, of rippling joined-upness, and knowing which approaches to use for what purposes.
@Doug: “I am serious, though, about a focus on using a whole range of tools and concepts” (etc)
Yep – very strong agree on that. Very much needed. We’ll keep in touch on that one, yes?
I’ve been tending towards using “design” as a descriptor, but I find your point about the difference in direction between architecture and design very interesting; architecture presenting options, design selecting (or constraining itself) to one of those options. To achieve your “enterprise effectiveness” you need someone to provide options AND someone to actually choose one to go forward with, but it’s a good distinction.
I also like “efficiency as a subset of effectiveness” rather than a contrast; they are too often perceived to be mutually exclusive, which is the wrong approach to take to either.
@Ric: “To achieve your “enterprise effectiveness” you need someone to provide options AND someone to actually choose one to go forward with”
…and yes, they’re not necessarily the same people. That’s a really good point, Ric – many thanks for that.
Good comments and discussion. I like Enterprise Effectiveness. I’ve always liked the concepts in the book “Enterprise Architecture as Strategy” by Ross, Weill, and Robertson – the concept being to build a “Platform for execution”. But…I gave copies to the executive team, followed up by asking them to read the first chapter, offered a 4 page summary, then 2, then a single page – and finally stuck a slide on the end of an unrelated slide deck. Never did get traction – and I think it was because of the “A” word.
@Terry: “Never did get traction – and I think it was because of the “A” word.”
Yep, very probably.
The other reason might be that Ross, Weill and Robertson, whilst less IT-centric than most ‘enterprise’-architecture materials, is still too easily interpreted as ‘just IT stuff’. Which is pretty much a kiss-of-death for most executives. Kinda sad / ironic that the IT-folks have done such a great job of arguing for their own irrelevance to strategy, but there ’tis – a classic ‘hoist by their own petard‘, really. Oh well.
Tom writes:
“it’s easier, and probably wiser, to refocus our attention more on the outcomes than on the means via which we get there.”
It’s certainly easier, but I’ll question the “wiser”. The thing that makes something a profession is not only the outcomes its practitioners are able to achieve, but the fact that they have the means to do so. The proper role of the word “architecture” in a compound noun like “enterprise architecture” is not that the outcome is architecture, but rather that architectural thinking is the means by which some other stakeholder-defined outcome is achieved. It is in fact the means to defining the acceptable, desirable and effective means for achieving said outcome. Some such means may be effective but undesirable because they are unacceptable. Some means may be acceptable but undesirable because they are ineffective. Etc.. Architectural thinking is a particular way of approaching a design problem, i.e., a problem whose solution entails the making of a system of decisions that reflect our intent.
To the clients of a professional practitioner, the means by which the practitioner achieves a desired outcome is largely a mystery. This too is characteristic of a profession — the stark asymmetry with respect to the client’s and practitioner’s understandings of the skills, knowledge, and experience that are required for practitioners to be considered competent in the practice of the profession. The client can only, indeed must, trust that a professional can reliably effect the desired outcomes. The net of all this is that a professional practitioner’s conversations with a client must be “outcome-centric”, while conversations with other practitioners are unavoidably “means-and-outcomes-centric”. This is another way of saying that the way we speak to clients cannot be the same way we speak to one another, and the way we speak to one another cannot be the way we speak to clients. It is troubling that we have to remind ourselves of this so frequently, but it is also to be expected given that so few members of the community understand (or even care) what it means to be a profession(al), and that we aren’t even an immature profession, we at best aspire to be one.
len.
Thanks, Len.
The comment about “probably wiser” was not about renaming enterprise-architecture, but simply and solely about how we present or describe the disciplines to others – particularly executives.
As you’ll see from the post, I strongly believe that the term ‘enterprise-architecture’ is the only one that properly describes the discipline – or, at least, the discipline that is needed for the context we usually describe. The practical problem is that the term ‘architecture’ has become so ‘poisoned’ that it’s almost of kiss-of-death to use it (unless execs use it first, as in Nigel’s example above). It’s also definitely true that, as you say, the term is ‘means-focussed’ rather than ‘outcome-focussed’, which again doesn’t help with execs.
Yet, once again, the term ‘enterprise-architecture correctly describes the disciplines required to work on and with ‘the architecture of the enterprise. We don’t have a terminology-problem here (other than that certain groups are still pushing for a rigidly IT-centric or money-centric or something-centric view of EA, which is a different problem and a different story – though it is a large part of where the ‘poisoning’ of the term comes from, of course).
What we do have here is a marketing-problem: our market doesn’t understand us when we talk about ‘enterprise-architecture’. For them, in practice, it proves useful to use an outcome-oriented description, such as ‘enterprise-effectiveness’.
That’s all I’m suggesting here: that for marketing-purposes – for those outside of the EA-disciplines – it may be useful to use an outcome-oriented term such as ‘enterprise-effectiveness’.
For our own purposes – for those within the EA-disciplines, and related disciplines – we should continue to use and emphasise the literally-correct meaning of the discipline/activity-oriented term ‘enterprise-architecture’.
Is that distinction acceptable to you?
Tom replies to me:
“The comment about “probably wiser” was not about renaming enterprise-architecture,”
I didn’t take it that way; I took it as being about the nature of the conversations we have with non-practitioners.
Tom continues:
“As you’ll see from the post, I strongly believe that the term ‘enterprise-architecture’ is the only one that properly describes the discipline”
A sentiment with which I absolutely agree, and was not arguing against.
Tom continues:
“It’s also definitely true that, as you say, the term is ‘means-focussed’ rather than ‘outcome-focussed’”
But that’s going to be unavoidably true of the names of most professions. The problem is that we talk about EA in “means-focused” ways, rather than “outcome-focused” ways.
Tom continues:
“What we do have here is a marketing-problem: our market doesn’t understand us when we talk about ‘enterprise-architecture’”
No, I hear you saying much more than this. It’s not our “talking about” EA that is the problem, it is the very use of the term “EA” that shuts them down as engaged listeners. If it were only the way we talk about EA, we could talk solely about outcomes, and address means, in a suitable manner, only when they ask the “How?” question.
What’s troubling me here is what happens when I apply a tool I have found to be very useful — apply an idea about EA as a profession to some other profession and see if it makes sense. Would doctors call what they do one thing amongst themselves and something else to their clients? Would lawyers call what they do one thing amongst themselves and something else to their clients?
No, of course not. So the interesting question becomes “why?”. What’s different about EA as a profession?
I suggest that we are running into the consequences of thirty years of means-oriented IT-centric “marketing” of the concept of EA, not as a profession, at best as an occupation, but mostly as a role. And what kind of people have historically presented themselves to act in that role? IT guys. Seriously, does a C-level person want to listen to an IT guy about anything? Maybe it’s not so much the message as it is the messenger?
len.
Tom writes:
“is still too easily interpreted as ‘just IT stuff’. Which is pretty much a kiss-of-death for most executives”
Sorry, I don’t buy this. Following up on my previous comment, what causes executives’ collective eyes to glaze over is not “IT stuff” but “means-focused” conversations about “IT stuff”. Executives are very interested in “outcome-focused” conversations about “IT stuff”. And our goal should not be a concept of EA that casts “IT stuff” into the outer darkness, but one that considers “IT stuff” to be just one of many things that contribute to the success of ambitious undertakings, and considers the roles of these many other things as being of equal importance.
len.
Len, point taken – no question, for execs we do need to keep the emphasis on outcomes rather than means.
The practical concern is that whilst the eyes of the execs you work with may not automatically glaze over at the first mention of IT, it’s certainly my experience that they usually do – and from the comments above and elsewhere, a fair few other people experience the same reaction too. There is a real problem here – and it does not help to purport that it doesn’t exist…
@Len: “our goal should not be a concept of EA that casts “IT stuff” into the outer darkness, but one that considers “IT stuff” to be just one of many things that contribute to the success of ambitious undertakings, and considers the roles of these many other things as being of equal importance”
Again, very strong agree. We must, must, must emphasise the importance of IT or other related themes in enterprise-architectures: no present-day architecture is going to be able to work unless the IT concerns are fully integrated into the architecture. You won’t get any disagreement from me on that point.
The practical problem is how we enable that inclusion and integration. And, to be blunt, the IT-obsessives have so frequently shot themselves in the foot over this that we cannot simply rush in and go “IT! IT! IT!” – even though that’s the way that so many of them still try to do it. It does not work. (Okay, maybe they can, sort-of, for a short while, when an over-hyped IT-driven management-fad like BPR is in full flood – but it always backfires badly later for the poor sods who have to tidy up the resultant mess…) Instead, as you say, we need to start from the outcomes first. Which means context first; then, some way down the track, information, independent of any implementation; and only then – and again, some way down the track, the specific technologies required to implement the information needs for that context. In other words, for many if not most contexts, consideration of specific IT should come last – and not first, as the IT-obsessives far too often still do.
(Yes, I know that in principle TOGAF is supposed to follow that sequence – described there respectively as ‘Business Architecture’, ‘Information-Systems Architecture’ and then ‘[IT] Infrastructure-Architecture’. But in practice that isn’t how TOGAF works, primarily because the BDAT-stack acts as a filter to constrain all of the views to the subset related to classic ‘big-IT’, with almost everything else excluded from scope. Until the BDAT-stack is dropped from TOGAF, and a proper open-scope metaframework used in its place, its incipient IT-centrism means that TOGAF will continue to be an active hindrance to anyone attempting to do a literal ‘the architecture of the enterprise’. There really is no possible argument on that point any more.)
Very strong agree that “‘IT stuff’ [is] just one of many things that contribute to the success of ambitious undertakings”. How we get the IT-obsessives to stop pretending that IT is the only thing that “contributes to the success of ambitious undertakings” – and how to sidestep the damage they cause when they do so pretend – is a very large, very real problem that we face. I’d love to know how you would set out to tackle that problem – rather than, yet again, merely telling me that I’m ‘wrong’ for trying to find solutions that do work for this?
Tom replies to me:
“TOGAF will continue to be an active hindrance to anyone attempting to do a literal ‘the architecture of the enterprise’”
I don’t agree with you about this. TOGAF’s widespread acceptance reflects its fitness for purpose for a widely accepted specific class of needs. It is not being forced on a resistant marketplace. It meets a market need. The problem is not with TOGAF but with the “marketplace” for EA. This is why for the past year I have pursued a line of inquiry framed as “the success of ambitious endeavors”, that I ultimately connect with EA by concluding “this is what EA could be”.
Again, look at any other profession. The general practitioners don’t consider the specialists to be a problem, or their specializations “to be an active hindrance” to general practice. Most professions started out as what became specializations; as I wrote in a LinkedIn thread about this subject of the naming of EA as a discipline: “It is inherent in the nature of professions for them to change, often substantially, as they evolve and practitioners and society in general come to a better understanding of what’s at stake and how the profession can contribute to the betterment of the human condition”.
What we need to do is help advance that understanding, not bicker amongst ourselves about who’s wrong or whose fault something is.
len.
Tome replies to me:
“The practical concern is that whilst the eyes of the execs you work with may not automatically glaze over at the first mention of IT, it’s certainly my experience that they usually do”
This assumes that in order to talk about IT-effected outcomes, one must talk about IT. Doing so is not outcome-centric, it is means-centric. This is where the art of “story telling” comes into play.
len.
An unfortunate if amusing typo got by me — I appreciate that you write a lot, but that’s no reason to refer to you as “Tome”…
Apologies,
len.
Tome replies to me:
“I’d love to know how you would set out to tackle that problem – rather than, yet again, merely telling me that I’m ‘wrong’ for trying to find solutions that do work for this?”
C’mon Tom, I’m not telling you you’re wrong; I’m saying we have to be careful how we say things, otherwise we create opportunities for people to misinterpret us.
And my approach to solving these problems is to come at them from the perspective of creating a solid foundation for a true profession.
Sorry, did it again…
len.