Continue in 2 seconds

EIA Framework Definition, Part 4 – Closing the Gaps

Published
  • October 07 2004, 1:00am EDT

This is a series on defining, planning and rolling out the appropriate plans, policies and structures to manage information, i.e., information architectures. Part 4 focuses on closing the gaps between the current state of business and future vision.

The Discovery step discussed in the August 27, 2004 column provided the enterprise infrastructure architecture (EIA) team with a lot of information about where the enterprise wants to go with information. Inevitably, gaps are identified between current and future states. Therefore, the next step is to take the future state business and scenario/vision information and create a first look at how the gaps will be closed, and what types of structures (a taxonomy as it were) will be required to maintain the EAI as time goes on. Many processes call this step "conceptual architecture" or "preliminary frameworks." What must be delivered at this step is a business-aligned first cut that merges possible applications, technology and organizational components.

Information architecture is the collection of components used to manage valuable enterprise information assets. This includes plans, policies, principles, models, standards, frameworks, technologies, organization and processes that will ensures that integrated data delivers business value and aligns business priorities and technology.

This is done to provide data and guidance to decision-makers while the deeper details of the EIA are being developed. For example, a certain EIA may call for a data integration component. (Which one won't? But, I digress.) The preliminary architecture or high-level EIA design will, therefore, feature some information on data integration. This will tell decision-makers that governance, network bandwidth and staff training may all be required to fulfill the EIA goals. Exactly which integration strategy (EAI, EII, etc.) is used and what vendors are chosen are not relevant. By the way, this step will be very helpful in repressing the urge to go buy stuff RIGHT AWAY, which is perhaps the most common mistake made by companies attempting to manage information better. .

Basic Deliverables

As usual, there are obvious deliverables and some not-so-obvious deliverables. The obvious ones would of course be some presentation of the overall EIA framework (see Figure 1 as an example). This describes the components and taxonomy or relationships of the components.


Figure 1: EIA Framework

Other key deliverables of this step will be:

  • Information principles - Develop a list of principles that will frame and direct how an organization's culture deals with information. Principles must be sponsored from the highest levels. If not, forget using them. Principles must also be specifically measurable or able to point to a specific governance action to sustain them. Some examples are:
    1. Business information needs for customer data will drive the data management architecture.
    2. There will be an identified authoritative master data store for customer data.
    3. All customer data will have an identified business steward.
      (There will be an article dedicated to information principle later this year - it is a large topic on its own.)
  • Draft governance requirements - What processes and organization will be required within the culture and business needs to sustain the EIA?
  • Refinement of information requirements - The metrics, data models and scenarios of the previous steps are used to expand information requirements for the enterprise. Before you say, "OK, I know that," let me relay that the second worst mistake made (buying equipment and tools early being the first) is poor or superficial presentation of information requirements. You must clearly present the extent your company will be fueled by information. What processes, what subjects, and what metrics will be required to meet business plans?

Some of the not-so-obvious deliverables are:

  • Data sources - External and internal to the enterprise. Think of the old-fashioned context diagram - what information touches the enterprise from outside the enterprise. What are the critical production systems that create data? This data is by its nature, existing in mature and/or mission-critical applications. Knowledge of where, what and how they work is valuable at this time in determining any taxonomy components to handle these sources. Let's face it, if they were perfect, we would not be doing the EIA. Another reason to address these issues now is often it is much less expensive to repair data deficiencies in the source applications than to create exhaustive data hygiene processes in the ETL or EAI processes. This is the reason these are addressed now and not during a technical architecture step later.
  • DQ and analysis of sources - The same sources should be scanned or analyzed for data quality issues. Usually at this point an automated tool is most helpful. Why do this level of detail so early? Examining the data sources and getting anecdotal information on quality usually scratches the surface, and our practice has found out that a slight additional effort at this point yields important information on the existing data infrastructure.
  • Measure model refinement - Time permitting, a second pass at the measurements and metrics may result in additional insight into information requirements. In addition, the measurement model can be refined significantly by adding information to metrics regarding volume, latency, historical requirements and additional items. (See a previous article Alignment with the Business Community that appeared in May 2002.)

Common errors made at this juncture include:

  • Over emphasis on technology (again, please don't call any vendors yet).
  • Weak information principles and governance processes - it is common to see "data is an important asset" as a principle. This is pretty weak, hard to measure and has no direct associated governance.
  • Failure to gather support from various IT sectors (applications, DBMS, operations, etc.). - The taxonomy will include many components. IT is key to include areas affected by or responsible for those components at this time to review any proposed architecture.
  • Poor business involvement - Always the big pain, but it must be said - without business involvement, the EIA will be misaligned.

As the EIA moves into richer levels of detail and taxonomy, the gaps between the current state and the future must be clarified, and a vision that will close those gaps needs to be formed. Once that happens, it is easy to flesh out the details of the vision into technology choices and a roll-out strategy.
The contents of this article are Copyright 2004 by DM Review and KI Solutions. Any use, quotation, repurpose, duplication or replication of the diagrams, concepts or content without permission of DM Review and the author is prohibited.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access