Enterprise architecture is getting a lot of attention these days. Google “enterprise architecture” and you’ll get some 13 million hits. Pretty impressive, as a search on Paris Hilton gets 46 million, only three-and-a-half-times as many.
There’s only one Paris Hilton, but there seem to be a lot of different notions of what enterprise architecture is or should be. Too often, what I read and hear about enterprise architecture reminds me of the fable of the blind men and the elephant: A half dozen or so blind men encounter an elephant and try to identify what it is. Each touches a different part of the elephant—an ear, a tusk, the trunk, a leg, a side, the tail. They are unable to agree on what they confront, each defining the whole in terms of the part that they know.
The role of the IT architect has become important enough that there are multiple efforts afoot to train, certify and professionalize architects as such, including (but surely not limited to) the U.S. Department of Defense, Federated enterprise architecture Certification (FEAC) Institute, the International Association of Software Architects (IASA), the IT Architect Certification (ITAC) program, the TOGAF certification program, the Microsoft Certified Architect (MCA) program, and The Association of Open Group Enterprise Architects (AOGEA).
Given that enterprise architecture promises to be such an important concept and is generating such a frenzy of activity, I’m surprised, and a bit dismayed, by how blithely we assume not only that we all know what it is, but that we all know it as the same thing. Worse, that assumption too often takes the form of, “Everybody means what I mean, and everybody does what I do,” or the insistence that “Everybody should mean what I mean, and everybody should do what I do.”
Why it Matters
Assuming that others use the same words to mean the same things you do can lead to misunderstandings with possibly serious consequences. For example, the legal, medical and engineering professions are critically dependent upon consistent and shared vocabularies. If we wish to establish the practice of enterprise architecture as a legitimate profession, we need just such a vocabulary ourselves.
Most people understand that we use words to represent and express the ideas that we have, and we take for granted that the words we use accurately reflect the things we think. But we often overlook that the words we use, to some extent, determine how and what we think. So, as long as we talk sloppily about architecture we will think sloppily about it, as well.
But aren’t these issues pretty much settled? I think not.
Over four years ago, Martin Fowler wrote in IEEE Software : “In a sense, I define architecture as a word we use when we want to talk about design but want to puff it up to make it sound important.”
More recently, Frank Hayes wrote: “In IT, we love titles and metaphors that come from the construction world. Of course, many of our ‘software engineers’ don’t know the first thing about engineering, and the quality of IT infrastructure that we casually call ‘plumbing’ would make a union plumber cringe. And architects? In IT, we think that means people who design systems.”
I think it’s worse than that; I think many practitioners believe that if you’re really good at