The Framework as it applies to Enterprises is simply a logical structure for classifying and organizing the descriptive representations of an Enterprise that are significant to the management of the Enterprise as well as to the development of the Enterprise’s systems. It was derived from analogous structures that are found in the older disciplines of Architecture/Construction and Engineering/Manufacturing that classify and organize the design artifacts created over the process of designing and producing complex physical products (e.g. buildings or airplanes.)

The older disciplines of Architecture and Manufacturing have accumulated considerable bodies of product knowledge through disciplined management of the "product definition" design artifacts. This has enabled enormous increases in product sophistication and the ability to manage high rates of product change over time. Similarly, disciplined production and management of "Enterprise definition" (i.e. the set of models identified in the Framework for Enterprise Architecture) should provide for an accumulation of a body of Enterprise knowledge to facilitate enormous increases in Enterprise sophistication and accommodation of high rates of Enterprise change over time.

Although the Framework for Enterprise Architecture is an application of Framework concepts to Enterprises, the Framework itself is generic. It is a comprehensive, logical structure for descriptive representations (i.e. models, or design artifacts) of any complex object and is neutral with regard to the processes or tools used for producing the descriptions. For this reason, the Framework, as applied to Enterprises, is helpful for sorting out very complex, technology and methodology choices and issues that are significant both to general management and to technology management.

For example, out of the context of the Framework, it is becomes clear why management and the users are in many cases so frustrated with the current inventory of existing applications, "the legacy." The frustration clearly is not because there are too many applications. Or too few. Or because they are not strategic enough. Or because they are mainframe, or hierarchical, or COBOL, or whatever. The "legacy" is not a technology problem. It is an architecture problem.

The "legacy" frustration arises from three fundamental, architectural deficiencies.

First, in general, Rows 1, 2 and 3 models were seldom built ... and in many cases, Row 4 models were not even built. The models which are not explicitly produced are implicitly assumed by default, and a lot of assumptions were made which have since proven to be, or have become, erroneous. Furthermore, the Rows 1 and 2 models can change as fast as Management can change their minds, whereas the Row 5 implementations are "poured in concrete," resembling hundred story buildings. There simply is no way to keep the Row 5 reality in synch with the Row 2 perceptions without explicit formalizations and configuration control of the intermediate Row models as is done for physical products.

Second, the functional aspect of the systems was optimized at the expense of the data and the network for implementation expediency, that is, the data and hardware/systems software were tailored to the application and therefore disintegrated with regard to the Enterprise. Semantic and network discontinuities were created such that now, files can’t be related nor nodes connected and as a result, "maintenance" of the "legacy" now consumes the "lion’s share" of the I.T. resources. Worse, the energy of the Enterprise is consumed attempting to reconcile the semantic discontinuities and overcome communication complexities.

Third, the Enterprise has simply changed around the existing applications and these applications were built under the assumption that nothing would ever change. This is clear because the only application models that are left in many cases are those that are machine readable ... Row 6. If anything changes in Rows 1, 2, 3, 4, or 5 above, those models in which the change occurs have to be "reverse engineered" from whatever information remains in Row 6. Some people liken this process to Archeology, that is, it is very costly and there is questionable confidence in its accuracy or even "do-ability."

then, we are clearly building more " legacy." We may well gain some temporary respite

from the stress that is inherent in the existing inventory of systems, but the frustration and aggravation, not to mention the cost and complexity of maintaining the "legacy" and the Enterprise’s inflexibility and unresponsiveness to change, is bound to intensify as the Enterprise presses on into the dynamic, turbulent, "Information Age." All the innovative technology "solutions" in the world including very good things like Data Warehouse, Object-Oriented, Client-Server, Parallel Processing, etc., etc. serve only to help build more "legacy" faster. We have to satisfy short term demand, but at the same time, it becomes obvious from looking at the "legacy" in the context of the Framework, if we ever intend to be free from the "legacy" problem, WE MUST FIRST ADDRESS THE ENTERPRISE ARCHITECTURE ISSUES!!