By Leonard Fehskens, The Open Group
Many people have commented that one of the most significant consequences of the Internet is the “democratization of commentary.” The ability to comment on subjects of interest to a community is no longer limited to those few who have access to traditional methods of broadcast communications (e.g., printed media, radio and television). At the same time, membership in such communities is no longer limited to those who are physically proximate. The result is everyone has a wide-reaching public voice now (even this blog is one such example).
The chorus of public voices speaking about Enterprise Architecture has created something of a din. Over the past several years my listening to this chorus has revealed an extraordinary diversity of opinion about what we mean by “Enterprise Architecture.” I have tried to sort out and categorize this diversity of opinion to try to understand how the Enterprise Architecture community could think so many different things about the idea that unites it. Creating a true profession of Enterprise Architecture will require that we come to some sort of convergence and agreement as to what the profession is about, and I hope that understanding the roots of this wide diversity of opinion will facilitate achieving that convergence.
At The Open Group Conference in Cannes, France later this month, I will be speaking on this subject. Here is a preview of that talk.
Assumptions and Approaches
In many discussions about Enterprise Architecture I have seen preliminary apparent agreement rapidly disintegrate into disagreement bordering on hostility. People who initially thought they were saying the same things discovered as they explored the implications of those statements that they actually meant and understood things quite differently. How can this happen?
There seem to me to be two things that contribute to this phenomenon. The first is the assumptions we make, and the second is the approaches we adopt in defining, thinking about and talking about Enterprise Architecture. As important as the nature of these assumptions and approaches is the fact that we are almost never explicit about them. Indeed, one of the most widespread and consequential assumptions we make is that we all share the same assumptions.
To keep this article short and to avoid “stealing my own thunder” from my upcoming conference presentation, I’m going to step from the tip of one iceberg to the next, hopefully whetting your appetite for a more in-depth treatment.
How We Approach the Problem
There are an even half dozen ways that I have observed people approach the problem of defining Enterprise Architecture that have, by their use, created additional problems. They are:
- The use of ambiguous language – many of the words we have borrowed from common usage to talk about Enterprise Architecture have multiple meanings.
- Failing to understand, and account for, the difference between denotation and connotation – a word denotes its literal meaning, but it also connotes a set of associations. We may all agree explicitly on what a word denotes, but at the same time each hold, probably implicitly, very different connotative associations for the word.
- The use of figures of speech (metaphor, simile, metonymy, synecdoche) – figures of speech are expressive rhetorical gestures, but they too often have very little practical value as models for reasoning about the subject to which they are applied.
- Conflation – the inclusion of a related but distinct discipline as an integral part of Enterprise Architecture.
- Mixing up roles and job definitions or job descriptions – jobs are defined to meet the needs of a specific organization and may include parts of many different roles.
- The “blind men and the elephant” syndrome – defining something to be the part of it that we individually know.
The Many Things We Make Assumptions About
The problem with assumptions is not that we make them, but that we do so implicitly, or worse, unknowingly. Our assumptions often reflect legitimate choices that we have made, but we must not forget that there are other possible choices that others can make.
I’ve identified fifteen areas where people make assumptions that lead to sometimes radically different perspectives on Enterprise Architecture. They have to do with things like what we think “architecture,” “enterprise,” and “business” mean; what we think the geography, landscape or taxonomy of Enterprise Architecture is; how we name or think we should name architectures; what kinds of things can have architectures; what we think makes a good definition; and several more. Come to my talk at The Open Group conference in Cannes at the end of the month if you want to explore this very rich space.
What Can We Do?
It’s tempting when someone comes at a problem from a different perspective, or makes a different choice from among a number of options, to conclude that they don’t understand our position, or too often, that they are simply wrong. Enterprise Architecture is a young discipline, and it is still sorting itself out. We need to remain open to alternative perspectives, and rather than focus on our differences, look for ways to accommodate these different perspectives under unifying generalizations. The first step to doing do is to be aware of our assumptions, and to acknowledge that they are not the only assumptions that might be made.
In the words of St. Augustine, “Let us, on both sides, lay aside all arrogance. Let us not, on either side, claim that we have already discovered the truth. Let us seek it together as something which is known to neither of us. For then only may we seek it, lovingly and tranquilly, if there be no bold presumption that it is already discovered and possessed.”
Len Fehskens is Vice President of Skills and Capabilities at The Open Group. He is responsible for The Open Group’s activities relating to the professionalization of the discipline of enterprise architecture. Prior to joining The Open Group, Len led the Worldwide Architecture Profession Office for HP Services at Hewlett-Packard. Len is based in the US.
Len,
Thanks for the post. It is enlightening as all of your posts are and I am looking forward to the full presentation.
My apologies if this comment is a bit of a hijack of your post but I do get exasperated sometimes at the relentless focus of our community on self-definition. I just feel that there is far too much focus on it generally and that brilliant minds like yours could be applied to more meaningful (i.e. value delivering) aspects of EA.
I tend to feel that if we, the EA community, spent 1% as much time & energy focussing on sharing effective methods for delivering value as we do talking about what EA means, our profession could have made even greater progress than it already has.
We have much to be proud of, but for a profession that claims to offer a path to optimisation, I think we collectively have not concentrated our time & focus optimally. The endless self-referential discussion is surely distracting us from discussion about application and method.
Agree with Alex in that it was a thoughtful eloquent post as is all that Len posts. Loved the quote at the end.
Also agree on the endless circle of definition-a-thons.
There are probably as many definitions of art as there are artists. That doesn’t appear to have prevented civilisation from creating countless works of great art.. or the establishment of countless institutions, academies, galleries etc.
Call the differences schools, accept that we will never all agree on everythibg and seek to move on to the interesting stuff.. sharing.. methods approaches experiences etc.
Who knows, in the process of doing that we may find out we have more in common with each other after all!
The confusion is increased by Vendor certifications on technologies such as Java and .Net which are also termed “Certified Enterprise Architect” because they refer to the Enterprise edition of the Technologies as against Open Group’s understanding of Enterprise Architecture which is about architecting IT for the Enterprise to implement strategy in a vendor, product and technology agnostic approach, two different things. I believe the Open Group should clarify this and also urge Vendors such as Microsoft, Oracle and Sun to issue similar clarifications in their certifications.
The main issue is not about collaboration but rather about the expectation of employers when they hear the term “Enterprise Architect”.
As the principal of a company which is a member of the Open Group and as some one who is involved in the projects of the Architecture Forum, I hope I can provide some inputs towards this.
Great article Len. I’m looking forward to the talk in Cannes (and what those 15 areas of assumption are).
I do agree with Alex that it appears the EA community wastes an enormous amount of energy on fighting over definitions and that perhaps the best way to get beyond that is to put more emphasis on what we can produce and why it might be useful to someone who isn’t an EA.
I think definitions are very risky things anyway. They can be a useful way for someone (or a group of people) to explain what they mean by their use of terms. The trouble is that they so often lead to virulent discussions about the one and only correct definition. So definitions tend to become exclusive rather than inclusive. And the original topic that led the author(s) to place their definition gets lost in the discussion.
It would be great if people could just accept a particular usage in context and get on with the discussion. On the other hand those offering the definitions have to accept that they can’t simply hijack a term in common usage and expect people to simply accept their specialized usage.
So back to Alex’s point. Maybe we should just refuse to define and concentrate on explaining our methods and their value – and develop an inclusive practice.
The main reason is that reputed organisations with large followships, not only that have not come with convincing definitions but their approaches continue to compete.
Thank you all for your comments, and my apologies for taking so long to respond.
There’s clearly a recurring theme here – debating the definition of enterprise architecture is wasted effort better spent on improving its practice.
I was careful when writing this piece to frame it as being about the diversity of opinion on what it is that we as enterprise architects do, and why and how we do it, rather than about our inability to agree on a single concise definition of enterprise architecture. I think I did a pretty good job of that; there are only two places where I actually use the word “definition”; one refers to job definitions and the other to the problem of definition in general. I did use the phrase “defining … enterprise architecture” twice, but if you look at the larger context of what I wrote, it’s not about “defining EA” as such, it’s about the community’s inability to agree on a widely shared concept of EA, regardless of exactly how that concept is expressed as a “definition”. That said, I’ll be the first to admit that even if we had such a consensus, there would still be seemingly unending argument about the details of the wording of a definition that expresses that consensus, and a small part of my talk addresses that part of the problem.
So, while I’m sympathetic to the intent of this common reaction to the question I asked, I have to disagree with two of its premises – that we spend an undue amount of time debating the meaning of EA, and that this effort is unnecessary and thus wasted.
The first of these is the more difficult to argue with. It’s just about impossible to estimate how much time is spent debating what enterprise architecture is about, and what fraction of the total effort expended by the EA community on EA-related activities that time represents. But my guess is that it’s insignificant, less than 1%. I suspect it seems much larger to people who see it as wasted effort, largely because they see it as wasted effort.
It’s the second premise that I really want to push back on – that any time spent trying to forge a community-wide consensus on what enterprise architecture is about is wasted effort. How can we call this a professional discipline without such a consensus? Does anyone want to make the case that we have such a consensus, and these “unnecessary and time-wasting” discussions are about irrelevant marginalia?
I have heard people argue that other professions don’t waste time on such discussions. Doctors don’t debate what medicine is about. Lawyers don’t debate what the law is about. Engineers don’t debate what engineering is about. If we too aspire to be a profession, we should follow their example. This confuses cause and effect. Of course doctors, lawyers and engineers don’t debate what their professions are about. These are professions that have had hundreds of years to converge on a shared consensus. Perhaps more importantly, this shared consensus manifests itself as practically universal agreement as to what constitutes undergraduate and graduate curricula in these disciplines. Enterprise architecture is not even close to such a consensus.
I think the example of art is a red herring. While enterprise architecture shares the “every work is one of a kind” property of art, the consequences of failure to address the stakeholders’ needs are much more serious for enterprise architecture.
I am confident that over time, the practice of this profession will sort this out. There is at least as much sharing of “effective methods for delivering value” as there is discussion of what kind of value EA should or does deliver and what that implies about methods for doing so. The question for me is whether we can make this happen faster by explicitly designing the profession, rather than waiting for some sort of process of natural selection to shape it, especially since such trial and error processes can lead to dead ends. Arguing about what it is that we as enterprise architects do, and why and how we do it, is a model of that process.
len.