By Leonard Fehskens, The Open Group
In the first part of this series, I proposed distinct meanings of enterprise, business, organization and corporation.
As I noted earlier, you don’t have to agree with the distinctions I am making here. But words are a finite, “nonrenewable” resource – if you treat these four words as interchangeable synonyms, you will not be able to make these distinctions without finding other words to make them for you. In particular, you will not be able to distinguish an endeavor from the means of realizing it (similar to confusing an architecture and a blueprint). You will not be able to distinguish one particular kind of endeavor (for example, a commercial endeavor) from other kinds of endeavors. You will not be able to distinguish one particular kind of organization from other kinds of organizations.
Treating these four words as synonyms makes these words unavailable to describe larger and more inclusive domains for the application of architectural thinking. What’s more, it does so needlessly. This discipline doesn’t need synonyms any more than an organization needs multiple different systems that do the same thing. Synonyms are redundancies that reduce the expressive power of the language we use to talk about what we do. We need to be able to make distinctions between things that are important to distinguish from one another, and there are only so many words available to us to do so.
I acknowledge that for most of the community of practicing business and enterprise architects, most if not all of their practice occurs in the context of business-as-commercial-entities. It is therefore not surprising that many people in the Business and Enterprise Architecture communities would not believe these distinctions are worth making, and be perfectly happy to (if not insistent that we) treat these words as synonyms. But we have to be careful to avoid the example of the six blind men and the elephant, and being able to explain a predisposition to make these words synonymous doesn’t make it the right thing to do.
There’s even a contingent that insists that enterprise doesn’t just mean a commercial business organization, that it means a specific kind of commercial business organization, one that exceeds some critical threshold with respect to its scale, complexity, sophistication, ambition or consequence. This is a bit like insisting that the implied “building” in “(building) architecture” means “commercial building”, or more specifically, “skyscraper.”
The problem with this concept of enterprise arises when one tries to specify the objective criteria by which one distinguishes a mere business from the bigger, more complex, more sophisticated, more ambitious or more consequential business that deserves to be called an enterprise. It is certainly the case that the larger, more complex, more sophisticated, more ambitious and more consequential a commercial business organization is, the more likely architectural thinking will be necessary and beneficial. But this observation about Enterprise Architecture does not mean that we ought to define enterprise to mean a large, complex, sophisticated, ambitious and consequential commercial business organization.
Why have so many naval vessels been named Enterprise? Why was the Starship Enterprise from the Star Trek franchise so named, and why was this thought to be an appropriate name for the first space shuttle? It was not because these vessels embodied some idea of a commercial business organization or because the word connoted a big, complex, sophisticated, ambitious or consequential business. And surely if the latter had been the reason, there would be many lesser vessels named simply “Business”?
There are two significant consequences to basing Enterprise Architecture (EA) on a concept of enterprise that is limited to a particular kind of organization. The first has to do with the applicability of the discipline, and the second has to do with how we educate enterprise architects.
If we restrict the definition of enterprise to a specific kind of purposeful activity, whether the criteria we use for this restriction are subjective or objective, we must either argue that architectural thinking is inapplicable to those purposeful activities that do not satisfy these restrictions, or we have to find a word to denote the larger class of purposeful activities to which architectural thinking applies, a class that includes both the restricted concept of enterprise and all other activities to which architectural thinking applies.
If enterprise means the same thing as commercial business organization, what do we call an entity that is not a commercial business organization (e.g., a church, a hospital, a government, or an army)? Does Enterprise Architecture not apply to such endeavors because they are not created primarily to conduct business transactions? What do we call organizations that are not businesses? If we want to talk about an organization that is a business, why can’t we just use the compound “business organization”, which not only does not erase the distinction, it makes clear the relationship between the two? Similarly, if we want to talk about an enterprise that is a business, as an enterprise, why can’t we just use the compound “business enterprise”?
Similarly, what should we call the architectural discipline that applies to human enterprise in general, and of which any more narrowly defined concept of Enterprise Architecture is necessarily a specialization?
The recent surge of interest in “Business Architecture” is, in my opinion, reflective of both the realization by the community that the historically IT-centric focus of Enterprise Architecture is unnecessarily circumscribed, and the lack of a systematic and internally consistent concept of Enterprise Architecture shared throughout that community.
There is a growing faction within the EA community that argues that most of Enterprise Architecture as practiced is actually enterprise IT architecture (EITA), and calling this practice EA is a misuse of the term. Despite this, the widespread adoption of the egregiously oversimplified model of an enterprise as comprising “the business” and IT, and thus, Enterprise Architecture as comprising “Business Architecture” and “IT Architecture”, has led to the emergence of “Business Architecture” as a distinct if ill-defined concept.
It seems to me that many people consider Enterprise Architecture to be so hopelessly tainted by its historic IT-centricity that they view the best course to be allowing Enterprise Architecture to continue to be misused to mean EITA, and letting Business Architecture take its place as what EA “should have meant.” I note in passing that there are some people who insist that EA “has always meant,” or at least “originally” meant, the architecture of the enterprise as a whole, but was hijacked by the IT community, though no one has been able to provide other than thirty year old recollections to support this assertion.
As I noted at the outset, I think Enterprise Architecture should encompass the application of architectural thinking to human endeavors of all kinds, not just those that are primarily business in nature, including, for example, governmental, military, religious, academic, or medical enterprises. Yes, these endeavors all have some business aspects, but they are not what we normally call businesses, and calling the discipline “Business Architecture” almost unavoidably encourages us to overlook the architectural needs of such non-business-centric endeavors and focus instead on the needs of one specific kind of endeavor.
We have the words to name these things properly. We simply have to start doing so.
In part 3 of this series, I’ll consider the implications of a more inclusive concept of enterprise on the future of Enterprise Architecture.
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. He majored in Computer Science at MIT, and has over 40 years of experience in the IT business as both an individual contributor and a manager, within both product engineering and services business units. Len has worked for Digital Equipment Corporation, Data General Corporation, Prime Computer, Compaq and Hewlett Packard. He is the lead inventor on six software patents on the object oriented management of distributed systems.