The key differences between Domain Analysis and Information Engineering are first of all differences in defining the problem scope. These scope differences reflect the origins of DA and IE in different client communities, and their consequent focus on different but related problem spaces.
The optimum scope of an Information Engineering initiative is an entire enterprise. Ideally, sponsorship of the IE initiative should reside with the enterprise's chief information officer or equivalent [#!Mar90!#] (in practice, narrower sets of interrelated functions are often studied initially, with significant benefit). The scope of the initial planning project is broad and shallow. This results in multiple, carefully scoped candidate follow-on projects; each is increasingly narrow in scope and deep in its level of detail.
IE, which spearheaded the "enterprise modeling" discipline, was developed in response to the integration problems facing Management Information System (MIS) developers and the collaboration problems facing their end-users. Coordination, collaboration, and information exchange among separate business activities (e.g. accounting, payroll, benefits, personnel, etc.) is vital to the effectiveness of a complex business enterprise. However, the separate systems supporting each of these business activities tend to be designed and developed in isolation. Frequently, each system is designed for use by customers representing a single organization within the enterprise. Because these systems function as stand- alone vertical slices through the enterprise, often impeding rather than supporting collaboration, they are sometimes described as "stovepipe systems".
The gaps and overlaps among these "stovepipe systems" present both their maintainers and end users with enormous difficulties. Their shared information is often defined and captured in multiple systems and files. These redundant and inconsistent stores and definitions escalate system life-cycle and usage costs and increase developer and user frustration. Since many systems are designed to support organizations whose functions overlap, similar functionality is also redundantly and inconsistently defined and maintained. Structural and dynamic interfaces among these systems are frequently non-existent, or added on an ad hoc basis.
Information Engineering results in integrated systems, composed of reusable assets that are planned, architected, and designed to support enterprise-wide collaboration. IE stresses the value of creating enterprise-wide architectures, carefully partitioning shared information and functionality to create reusable "information assets," and capitalizing on combining these reusable information asset components to compose sets of interoperating systems.
The recommended scope for a Domain Analysis initiative is a group of similar systems representing both significant commonality and variability. Generally, these are functionally similar systems [#!Bai!#], but this is not strictly necessarily [#!ODM!#]. What is necessary is that they represent an opportunity for reuse that offers a clear business advantage. Ideally they should be under the control of a single development organization or a single sponsoring higher-level manager [#!ODM!#].
Domain Analysis originated in response to the needs of software development organizations with core competencies in one particular functional area (e.g. accounting). Their lines of business frequently consist of scores of similar systems, each "developed to spec" for a different client (or sometimes for the same client). This multiplicity of unplanned system variants results in escalating system life-cycle and usage costs and increasing stakeholder frustration. Therefore, Domain Analysis asserts that reuse is most likely to be successfully implemented and adopted by capitalizing on commonality, and understanding and controlling the variability, within sets of functionally similar systems (system families).
DA architectures may describe current system commonality and variability, and, in some cases, prescribe the range of variability to be supported in the asset base. To do this, DA models generally describe variants as "features" embodying the concerns of "stakeholders." These "stakeholders" may represent not only the user community but, for example, varying development standards, and development and operating environments. To fully understand the history of and reasoning behind system variants, several DA branches also stress the capture of system genealogies, noting the decisions, trade-offs, and rationale behind each feature.
To summarize these differences, IE focuses on reuse that supports collaboration among related functional areas (such as accounting, payroll, benefits, personnel), often ignoring the nastiness of modeling the variability among multiple systems supporting any one function (e.g. accounting). The result of IE's emphasis on commonality sometimes flies in the face of real-world requirements, and misses enormous opportunities for reuse. On the other hand, DA focuses on reuse that supports the commonality and required variability among multiple systems supporting any one function (e.g. accounting), often ignoring the nastiness of modeling the collaborations among related domains (such as accounting, payroll, benefits, personnel). The result of such isolated DA projects could very well replace "stovepipe systems" with "stovepipe domains."