After working in the trenches of enterprise architecture since its birth (and before), I should probably not be surprised by anything. Nevertheless, I am continually surprised by the range of subliminal definitions of enterprise architecture that people seem to be carrying around with them, and in some cases laboring under.
Is enterprise architecture primarily an IT discipline? No — I thought we dispensed with that misconception years ago! Is enterprise architecture a glorified accounting task, essentially inventory with a million-dollar budget? No (if that is what you are doing, you are not doing enterprise architecture). Following the principle of "when concepts are not clear, add mud," the community has further confused things by arguing the distinctions among "enterprise architectures," "solution architectures," "systems architectures," and so forth.
If we could for a moment ignore the terms "enterprise architecture" and what does or does not constitute one, and "solution or system architecture" and what does or does not constitute one, we might reach some agreement on the concepts that underlie enterprise architecture. In that spirit, here is my take on enterprise architecture, without using the word (until the end).
In order to make sure an organization or other entity is in the right business, performing the right activities, using the right people, sending the right information and objects around to the right places at the right times, using the optimal technology (if any!) and other resources to assist in the activities and to effect the flow of information and objects — all in order to meet its goals — people engage in a process or discipline of holistic business analysis (see what I did there?).
This discipline examines all the above aspects of a business, organization, or other endeavor; analyzes how well it is doing; and makes recommendations on how (or if) to improve. One way people conduct this analysis is by building representations of the organization (or business, etc.) or aspects of it and examining those representations.
It is useful to have an overall representation of the whole organization, in all its aspects, to be sure that you have not omitted any important factors, and to keep this representation current. However, it is impractical to have every fact in this representation that could ever be needed to support any analysis of every problem, including those that have not yet been identified. And it would be very expensive to try to do this.
So, the practitioners of this discipline also build more focused representations of certain aspects of the organization (or business, etc.) that are relevant to a particular problem as the problem crops up. To do this, they consult the overall model for information that is relevant, and also gather additional, specialized information that relates to that problem.
These problem-focused representations are of various types, but all should be guided by an overarching framework (a "how-to" manual) that provides rules that ensure that representations of multiple types relate to each other in certain ways, just as a set of grammar rules dictates that parts of speech relate to each other in certain ways.
In this way, a "family" of representations develops, consisting of the overall representation and several problem-focused representations. They are all factually consistent because the problem-focused representations started with the overall representation as the basis, and they are all "grammatically" consistent because they were built following the same guiding framework.
If the organization chooses to, it can add the newly derived information contained in the problem-focused representations into the overall representation, increasing its size and level of detail.
To my mind, the resulting collection of representations is, collectively, "the enterprise architecture," or the "enterprise architecture representation," to be more specific. And the process of holistic business analysis that was performed to derive and analyze that collection of representations is the discipline we call enterprise architecture.
