Enterprise Information Architecture

Overview

The primary objective of an “architected” environment is to deliver higher quality, integrated systems and information at a significantly reduced cost, over time. Some of the ways this objective
is achieved by the “architected” environment are:

• By eliminating/minimizing data redundancy within the operational systems environment
• By eliminating/minimizing process redundancy within the operational systems environment
• By greatly reducing the complexity of extracting data from the operational environment into the data warehouse environment

The Enterprise Information Architecture (EIA) is the vehicle which provides the “roadmap” to the “architected” environment. The EIA is comprised of 3 “sub-architectures”, namely, the:

“Business Architecture” – which includes a:

• Corporate Data Model – A business-oriented (i.e., independent of technology and current systems), integrated view of the data that is important to the organization (aka,
  a “logical” data model).
• Function Model – A business-oriented (i.e., independent of technology and current systems) decomposition of the core business functions performed by the organization.
• Interaction Model – A matrix which depicts what data is used (Created, Read, Updated, Deleted (aka, CRUD)) by each of the processes within the Function Model. Processes
  with similar data needs are typically implemented within the same operational system.
• Current Systems Model – An inventory of the current systems environment. As one example, data and process redundancy within the current systems are brought to attention
  via matrices which “map” the current systems to entities within the Corporate Data Model and processes within the Function Model.

“Technical Architecture” – Depicts the current technical environment and the desired future technical environment which facilitates development of a migration plan. Also,
includes inventorying of the current technical environment (e.g., number of DBMSs supported in-house, etc.). Current systems can also be “mapped” to technical components.

“Organization Architecture” – Depicts the processes (from the Function Model) performed by each organizational unit within the organization. Also, depicts the
organizational structure, at a high-level.

The diagram below presents the breakdown of the EIA:

Some other benefits of building and maintaining an EIA are:

• facilitates assessment of packaged applications for “fit” within the organization (assuming a Corporate Data Model and Function Model is developed)
• eases integration of acquired companies’ data into our systems environment because the data can be “mapped” into a “logical” Corporate Data Model (rather than directly into physical
  tables)
• facilitates development of a common language (and understanding) amongst our lines of business because the models are developed from an enterprise-wide perspective
• speeds the orientation process of new employees because they can quickly become acquainted with the business through analysis of selected portions of the models
• provides a “roadmap”, via the Corporate Data Model, for assessing existing (in-house built) operational data structures and planning for their re-engineering into an integrated set of
  structures

It is not mandatory to implement all components of the EIA. Nor is it necessary to implement a given component with a “big bang” approach. For example, as a natural part of the data warehouse
development process, we are going to be incrementally developing the Corporate Data Model.

What Do We Do With the EIA?

To be worth the effort and cost of construction, the Enterprise Information Architecture can and should be used during the following activities / for the following purposes:

• Project Prioritization – one of the deliverables of an EIA is an “optimal” new system development sequence, based on interdependencies between the functions performed by
  the organization. This “natural” sequence is “optimal” because it maximizes the opportunity for data and process sharing, which results in the most streamlined systems environment possible.
  For example, a “natural” sequence may recommend construction of “Product Management” and “Customer Management” systems before an “Agreement Management” system that sells specific Products
  to specific Customers. If constructed in this sequence, the already built Product and Customer data structures could be used by the Agreement Management system, rather than the Agreement
  Management system having to create its own redundant Product and Customer data. In reality, business-driven priorities may sometimes lead to deviation from this “natural” sequence. However, the
  availability of this “natural” sequence will allow management to make informed decisions because the impact of shifting project sequences, on achieving an optimally integrated environment, will
  be known up front. In fact, cost/benefit analyses, which balance sequence vs. priority, can be undertaken to determine the optimal project prioritization.

• Data Warehouse Design – the Corporate Data Model provides an integrated, enterprise-wide view of the organization’s data. This integrated view is used to guide the design
  of the warehouse so that cross-functional information requirements can be delivered quickly and accurately. For example, the ability to integrate shipment, invoice, and claims data (from our
  non-integrated operational systems) for a National Account, will be modeled within the Corporate Data Model which will expedite the delivery of that information by the warehouse.

• Operational Database Design – the Corporate Data Model provides a “head start” in terms of the development of integrated operational databases, because the important data
  concepts to be implemented as part of a given system will already be modeled. The data design effort will be one of refinement, rather than discovery and refinement. Also, we will be ensuring
  ourselves of the opportunity of implementing our data structures with an eye towards integration with other systems.

• Operational System Scope Determination – the Interaction Model shows the data used by the processes performed within the organization. This knowledge can be used to
  identify “clusters” of processes that act on similar data and thus are candidates to be implemented within the same system. It can also be used to draw attention to processes that should
  probably not be implemented within the same system due to a lack of synergy.

• Data Redundancy Assessment – the Current Systems Model contains a “Current Data Store to Entity Type” matrix that highlights the redundancy of data within our existing
  operational data structures. This information can be used to initiate projects aimed at eliminating the redundancy, where possible, to incrementally improve the quality and integrity of our
  existing operational data.

• Process Redundancy Assessment – the Current Systems Model contains a “Current System to Process” matrix that highlights the redundancy of functionality within our existing
  operational systems. This information can be used to initiate projects aimed at consolidating the processes within a single operational system, where possible, to incrementally improve the
  quality and lower the cost of maintaining our existing operational systems.

• Organizational Redundancy Assessment – the Organization Model contains an “Organizational Unit to Process” matrix that depicts the processes performed by each of our
  functional areas. Unknown redundancies in functional responsibility may be uncovered and result in initiation of business process re-engineering efforts or organizational restructuring to improve
  processing efficiency.

• Technology Redundancy Assessment – the Technology Architecture provides an inventory of currently used technical components within the organization (e.g., DBMSs, Operating
  Systems, Programming Languages, Application Development tools, Query tools, etc.). This information may identify the use of multiple products within the same product class, and thus, provide us
  the opportunity to optimize our product portfolio by eliminating unnecessary product (e.g., upgrades), maintenance (e.g., product fixes), training, and support (e.g., monitoring) costs.

• Packaged Application Assessment – a package’s data models / structures can be compared against our Corporate Data Model to quickly assess how well the package meets our
  data needs. The package’s function model / functional components can be compared against our Function Model to quickly assess how well the package addresses the business processing requirements
  of our targeted functional area. Mergers / Acquisitions Data Integration – integration of acquired companies’ data into our systems environment can be expedited because the data can be
  “mapped” into our “logical” Corporate Data Model (rather than directly into physical tables). Integration issues and the subsequent business impact would be identified and understood much
  more rapidly.

• Common Business Language Development – development of a common language (and understanding) amongst our lines of business can be facilitated because the models within the EIA are
  developed, and approved, from an enterprise-wide perspective. New Employee Orientation – new employees can learn our business more quickly through analysis of selected portions of the models.
  They can easily gain a general understanding of what Allied does and formulate specific questions to increase the depth of their knowledge.

Prerequisites for Success

The following criteria must be met for an EIA implementation to have a chance of being successful:

• Identification and Quantification of “Real Life” Examples where EIA will make a Difference – a quick analysis of the existing systems environment should be done to identify
  tangible benefits that can be achieved via an “architected” environment.

• Recognition of the Need for Change – The organization, including the business community and I/S, must have a desire to improve their existing ways of doing business. There must be a
  common desire to streamline business processes by thinking corporately, rather than departmentally. This is why business process re-engineering (BPR – analysis of existing business processes
  to identify new ways of doing things more efficiently and / or with more quality) is often done in conjunction with EIA.

• Top-level Management Education and Support – Senior Management, including the business community and I/S, must be thoroughly educated regarding the costs and benefits of, and the
  organizational change required by, EIA so they can make an informed decision regarding their support for such an initiative. The effort should not even be started unless it is completely
  understood and supported by top management. Top management must act as the unified champion of the effort.

• Availability of Qualified Resources – Business community and I/S resources must be trained in the skills required for and purpose of EIA implementation. Consulting assistance is
  usually necessary. Without commitment from the business community to describe their core business processes and information requirements, EIA will fail.

• Acceptance that Significant Improvement does not Happen Overnight – The strategic “roadmap” provided by EIA can not be implemented all at once. It must be developed one piece at a
  time, in an evolutionary manner. However, the long-term objective of higher quality systems at a reduced cost will be achieved, over time, if management commitment is sustained.