Enterprise Architecture is an Enterprise issue, NOT an IT model-building exercise

The common perception (or more appropriately, mis-perception) of Enterprise Architecture in the general marketplace today is that it is one of an Information Technology (IT), model-building exercise. There is validity to that perception because, in order to engineer the Enterprise, the engineering design artifacts (the descriptive representations of the Enterprise) have to be created as they are the "raw material" for doing engineering work and the IT community seems to have the skills to produce those engineering design artifacts. 

The engineering design artifacts include the transcription of what the end-owners of the Enterprise, the people responsible for the operation and performance of the Enterprise, have in mind as to what the Enterprise is or is to be. These "requirements" for the Enterprise have to be articulated in such a fashion that engineering kind of work can be done to transform the Enterprise as it is conceived into an operating reality and to maintain that reality consistently as the requirements dynamically change. Although the IT community may have the skills to transcribe the "Requirements" for the Enterprise and transform them into a dynamic reality, the implied descriptive representations are not IT conceptions, only IT transcriptions and transformations. That is, Enterprise Architecture is an Enterprise issue, NOT an IT model-building exercise.

A problem occurs because, from the origin of the modern information industry in the 1950's, descriptive representations of the Enterprise have been perceived by the Information Technology community from a manufacturing perspective as opposed to an engineering perspective. Historically, IT is a manufacturing operation, "building and running systems." Manufacturing work requires multi-variable, holistic descriptions of PARTS of the object. In contrast, engineering work requires single-variable, ontologically-defined descriptions of the WHOLE of the object.

If the engineering work is done prior to the manufacturing work, the parts can be designed in the context of the whole object and thereby designed "integrated" into the whole. If no engineering work is done before manufacturing, the parts can be successfully manufactured in and of themselves but will not be designed for integration into the whole. This is especially obvious if the parts are made of physical material as for an airplane or a building or a computer, etc. The parts simply don't fit together, that is, they are DIS-integrated. What do you do if you have manufactured parts and they don't fit together? Scrap and rework! Throw that stuff away and start over again! There is no way to fix that problem after the fact.

In an Enterprise, if the parts (systems) are not engineered to be "integrated" into the context of the whole (Enterprise), they will be DIS-integrated, that is, they won't "fit" together. However, it is not as visibly obvious in the systems because the systems, in and of themselves, are "invisible" and can be successfully implemented, embodied in the "legacy", the manual and/or automated collection of running systems of the Enterprise. The systems are perceived to be invisible, but they don't physically work together as a whole Enterprise. They are discontinuous, inconsistent, costly to maintain, costly to "interface" (the after-the-fact attempt to post-integrate), difficult to change. The DIS-integration is painfully obvious to the Enterprise operationally as the systems, though "invisible" and successfully operating asynchronously, are no less tangible than metal or wooden parts of industrial products that don't "fit" together.