A Visible Solution Paper

By Alan Perkins,
Vice President, Consulting Services

"The only way an organization can manage strategic information, implement interoperable systems, and establish true data sharing is by using an

Enterprise Information Architecture."

Printable PDF Version

Clive Finkelstein,Chief Scientist,
Visible Systems Corporation

Copyright © 1997, Visible Systems Corporation

Contents

Enterprise Information Architecture

• Enterprise Information Architecture Engineering
• Define New Architecture
  • Identify Enterprise Needs
  • Validate Needs and Measures
  • Resolve Data Conflicts
  • Build the Enterprise Architecture Model
• Reverse Engineer Existing Environment
  • Assess Current Data Architecture
  • Generate Data Dictionaries
  • Develop Physical Data Models
• Map "As is" Physical Model to "To Be" Logical Model
  • Analyze the Gap
  • Develop Transition Plan
  • Engineer a Strategic Information Warehouse
• Transition to New Architecture
• Visible and IES Provide Skills Transfer
• More Information

Enterprise Information Architecture

Linking an enterprise’s strategic plan with its enterprise data architecture, enterprise application architecture and enterprise technical architecture results in enterprise information architecture. A well-documented architecture is a logical organization of information pertaining to the following corporate-level, enterprise-wide elements:

• Strategic goals, objectives, and strategies
• Business rules and measures
• Information requirements
• Application systems
• Relationships between applications and data elements
• Technology infrastructure

Enterprise information architecture also establishes guidelines, standards, and operational services that define the enterprise’s systems development environment. When an enterprise’s architecture is so documented, it can be used to accomplish the following:

• Facilitate change management by linking strategic requirements to systems that support them and by linking the business model to application designs
• Enable strategic information to be consistently and accurately derived from operational data
• Promote data sharing, thus reducing data redundancy and reducing maintenance costs
• Improve productivity through component development, management and reuse
• Reduce software development cycle time

Enterprise Information Architecture Engineering

Before an enterprise information architecture can be implemented, it must be "engineered." This requires a method and approach that is rigorous and repeatable. The Visible approach to engineering an enterprise information architecture is described below.

Define New Architecture

Identify Enterprise Needs

Identifying enterprise needs is the first task in the engineering life cycle for any information system, and it is crucial when engineering an enterprise architecture. When developing operational systems, there is often one single sponsor or one group of users with a clear view of what they need, what the system should look like, and how it should function. Conversely, when developing enterprise architecture, there are normally multiple potential sponsors, each with a different idea of what the enterprise architecture is and what it should provide, and all requesting or demanding action. Because of this lack of a single focused direction, identifying precise enterprise needs is critical to the success of an enterprise architecture project.

Enterprise architecture needs should be expressed in terms of business functions, rules, measures, and critical success factors. An enterprise’s business plans typically provide the basis for defining preliminary enterprise needs. In addition, it may be necessary to interview key enterprise managers and analyze other pertinent documentation in order to ascertain the enterprise’s strategic information needs.

The best technique for defining and refining preliminary enterprise information needs is to conduct a series of facilitated focus group sessions. (If no business or performance plans exist, similar sessions first should be used to create the plans.) The participants in any of these sessions should be decision-makers for whom the information is important.

Validate Needs and Measures

After identifying and defining enterprise needs, it is advantageous to communicate them throughout the enterprise. One of the best justifications for undertaking an architecture project is the synergy achieved through the process of defining and then communicating its critical success factors and measures. Everyone becomes aware of precisely what defines success and how it is measured. In addition, the measures undergo a "reality check" by people who were not involved in their development, but who may be measured by them and who will be involved in creating the raw data from which the measures will be derived. Their feedback is used for refining the measures.

Completely validating enterprise measures includes describing the cycles or time periods used. Are quarters, months, or hours appropriate for capturing useful measurement data? How much historical data will be needed? These vary greatly by enterprise. The United States Federal Reserve Bank views enterprise measures in monthly, quarterly and annual increments and uses years of historical data to determine trends in the economy. An insurance company requires decades of actuarial data for meaningful measures. A telephone sales operation, on the other hand, uses hourly enterprise measures and may keep only a few weeks of information.

Resolve Data Conflicts

A well-defined enterprise architecture model cannot contain homonyms, synonyms, or other data definition conflicts. These data conflicts may exist because most enterprises have one or more major terms that are used by everyone in the enterprise, but mean different things in different organizational units. One of the most commonly misused terms is "customer."

To the Accounting Department, "customer" could mean the organization (or individual) that receives a bill. "Customer" could also mean an individual receiving service or buying a product. To the Sales Department, "customer" could mean the organizations on which the salesperson calls. Additionally, each department may use different names to describe the same data element (Customer vs. Client vs. Prospect vs…). Providing any one of these interpretations as the single enterprise definition of "customer" would not meet the needs of the enterprise and would predispose its information resource management efforts to failure.

Great pains should be taken to resolve all data conflicts in the enterprise architecture before attempting to implement applications that support the new architecture.

Build the Enterprise Architecture Model

Creating an enterprise architecture is a lot like creating a building architecture. Both involve a disciplined development cycle, use rigorous techniques, and require the right tools.

A building is constructed using architectural diagrams (blueprints) that clearly depict the building's infrastructure (structural elements, walls, electrical wiring, plumbing, etc.). Enterprise architectures include architectural models of enterprise infrastructure (policies, goals, measures, critical success factors, data elements, etc.).

Blueprints are also used to enlarge a building or make any significant modifications. Without a diagram of the infrastructure, such changes are quite difficult and very costly -- and can even be dangerous. It is the same with enterprise architectures. Managing change means first updating the enterprise's architecture model so that it reflects changes (new product lines or services, for example) and then modifying the information systems to support the changed enterprise.

Enterprise architecture engineering is easier and less costly when based upon an accurate architectural model of the enterprise. Further, strategic information based upon the architecture is easier to use and consistently produces desired outcomes when decision-makers have access to an enterprise architecture that accurately reflects enterprise infrastructure.

It is imperative that an enterprise information architecture reflects both strategic information requirements and day-to-day operational data requirements. The architecture must be closely linked to the enterprise strategic plan and corporate performance measures. The framework for the architecture is described in the illustration below:

 

Enterprise information needs, corporate performance measures, and critical success factors should be documented in a central repository, along with a corresponding logical data model. The logical model should include operational data entities as well as strategic information data entities that will tell executives and managers how well their enterprise is performing.

Activities critical to capturing a clear understanding of an enterprise’s information architecture include providing a clear and unambiguous definition of every data entity, describing the way each is used, defining derivation formulas and aggregation categories, and documenting data collection and retention time periods. The resulting enterprise architecture model, which links enterprise needs with data entities and enterprise rules, becomes both requirement documentation and a source for communicating the contents of the architecture (and its metadata) to its users.

Reverse Engineer Existing Environment

While the architecture is being defined and modeled, the existing operational data should be reverse engineered to provide an "as is" data architecture containing physical data models and data dictionaries.

Assess Current Data Architecture

An enterprise has an architecture, whether documented or not. Before an enterprise can implement a new architecture, it must document its existing architecture. With the focused and committed involvement of enterprise managers, there must be a detailed assessment of the current data architecture. This helps to develop the scope and schedule for all follow-on activity. In order to complete eventual transition to the new architecture, it is necessary to determine the relative condition of the current data. The factors to consider are the "popularity" of the file management systems, the physical implementation (pages of code, reports, screens, data structures/schemas, and business rules), and the existence and relevance of investigative evidence to be included in the detailed assessment.

Generate Data Dictionaries

This effort can be facilitated through the use of automated tools. There are various sources for these tools, many of which are being used to solve Year 2000 problems. Even with automated tools, however, this activity will be resource-intensive. Detailed reverse engineering should be performed only when a particular data collection has been identified for conversion.

Develop Physical Data Models

There should be a model for each application/database/data store that includes the tables, columns and table relationships derived from its data dictionary. Every model should include a CRUD matrix identifying under what conditions the elements are created, read, updated and deleted.

Map "As Is" Physical Model to "To Be" Logical Model

When both architectures are available, the physical data models (and data dictionaries) of the old architecture should be mapped to the logical data model of the new architecture. This mapping should include the relationship between operational elements and strategic information, including requirements for data cleansing, summarizing and transformation. Mapping existing data elements to those desired will help establish the corporate value of current operational data elements and will allow gap analysis.

Analyze the Gap

Once mapping is complete, the gap between the "As Is" and "To Be" architectures should be analyzed. Elements in the old architecture that match elements in the new architecture will provide indicators of current operational data value (elements that should be converted). Any shortfall in current data will indicate a need for new applications. Identifying data elements in the old architecture that do not map to the new will help determine applications and files that will not need to be converted during transition.

The analysis of the two architectures also will help identify data problems that can be fixed immediately with limited resources and that will result in early, significant return on investment.

Develop Transition Plan

Once analysis of the relationship between the old and new architectures is complete, a plan for transition to the new architecture should be defined. The plan should be based upon the needs and priorities identified during the development of the new architecture, and should include tasks, timetables, deliverables, costs, and other resource requirements.

Engineer a Strategic Information Warehouse

The transition from current applications to new applications that support the new architecture can be facilitated through the implementation of a strategic information warehouse. This special-purpose database will provide executive and decision-support information in the near term, while providing a bridge for migrating to new applications that implement the new architecture. The physical warehouse database is designed based upon the strategic information elements defined in the new enterprise architecture model. Graphical, user-friendly executive information and decision support applications are implemented for management use.

The Visible definition of an information warehouse expands the concept of data warehouse. An information warehouse is more than an archive for corporate data and more than a new way of accessing corporate data. An information warehouse is a subject-oriented repository designed with enterprise-wide access in mind. It provides tools to satisfy the information needs of enterprise managers at all organizational levels — not just for complex data queries, but as a general facility for getting quick, accurate, and often insightful information. An information warehouse is designed so that users can recognize the information they want and access that information using simple tools.

An information warehouse is a blending of technologies, including relational and multidimensional databases, client/server architecture, graphical user interfaces and more. Operational (legacy) systems create, update and delete production data that "feed" the information warehouse. The principal reason for developing an information warehouse is to integrate operational data from various sources into a single and consistent architecture that supports analysis and decision-making within the enterprise.

For those enterprises that believe information is a valuable resource, an information warehouse is analogous to a physical warehouse. Operational systems create data "parts" that are loaded into the warehouse. Some of those parts are summarized into information "components" and stored in the warehouse. Information warehouse users make requests and receive information "products" that are created from the components and parts stored in the warehouse.

Information warehousing is one of the hottest industry trends — for good reason. A well-defined and properly implemented information warehouse can be a valuable competitive tool. For more detail, please see the Visible Solution, "A Strategic Approach to Data Warehouse Development."

Transition to New Architecture

Programs need to be developed that transform critical key performance data from the existing operational systems and use the data to populate the information warehouse. This will provide executives with strategic information immediately. Because the operational data has already been transformed to meet new information requirements, it will be easier to transition the current operational systems from the "As Is" to the "To Be" architecture and allow them to be migrated or replaced one at a time in priority order.

As each new application is implemented, appropriate strategic information collection from current applications will be discontinued and replaced with information from the new application. For some new applications, there will be data from existing systems that must be converted to provide historical data.

The conversions may be manual, partially automated, or fully automated, depending on the accessibility and integrity of the data. Regardless of the conversion method, a strategy for improving data integrity should be developed, when required to cleanse operational data.

isible and IES Provide Skills Transfer

Although "Information Warehouse" and "Enterprise Information Architecture" are relatively new terms, many Executive Information Systems (EIS), Decision Support Systems (DSS) and Management Information Systems (MIS) were developed by Visible and its clients using the underlying concepts described in this paper long before the terms existed. Visible perfected its approach to information architecture and warehouse development through years of experience.

The Visible methodology and tools are uniquely suited to support development of an enterprise information architecture and strategic information warehouse. Visible Advantage™ is the only integrated CASE tool that allows enterprise needs and measures to be linked directly to the information warehouse data model, data dictionary, integration and transformation process models, and the information warehouse database design in a single relational architecture.

Just as a powerful word processing system is not very useful to someone who does not write, Visible Advantage is not useful without appropriate knowledge and skills. The skills include the acquisition, interpretation and representation of all the details that go together to make up a model of an enterprise and transform the model into an information warehouse architecture. Visible helps clients gain the necessary expertise to use Visible Advantage effectively for information warehouse development through facilitation, training, education, and consulting. Visible prides itself on its ability to transfer the skills and knowledge that allow clients to gain mastery of Visible’s methodology and tools. Generally, this requires three complete development cycles of defining and modeling enterprise needs, designing the information warehouse architecture, applying appropriate technology, and implementing a data mart.

1. During the first cycle, one or more Visible consultants help the enterprise complete a prototype data mart for the information warehouse while training enterprise personnel on an information warehouse "Action Team." Visible consultants are actively involved in every aspect of this initial development cycle. During this and every phase of information warehouse development, enterprise analysts, developers and information warehouse users receive appropriate training to ensure they have the skills and knowledge to participate effectively. This "just-in-time" training is a hallmark of Visible.
   
2. In the second cycle, Visible consultants closely monitor and coach enterprise personnel as the Action Team completes the next information warehouse element.
   
3. Finally, internal enterprise personnel perform a complete information warehouse development cycle with minimal assistance from Visible, typically in the form of progress and quality assurance reviews. By the end of this third cycle, enterprise personnel are fully capable of developing information warehouse components on their own.

The enterprise is ultimately responsible for ensuring its information architecture and supporting warehouse are developed, and implemented and become enterprise assets. Visible provides the guidance and expertise that allows the enterprise to develop a superior information warehouse effectively and efficiently.

The Visible approach results in useable, effective information management tools that exactly meet the needs of an enterprise, public or private, large or small. More information about our methodology and tools can be found in the Visible Solution, "Enterprise Engineering."

More Information

For more information concerning this Visible Solution please contact: