Portals eNewsletters Web Seminars dataWarehouse.com DM Review Magazine
DM Review | Covering Business Intelligence, Integration & Analytics
   Covering Business Intelligence, Integration & Analytics Advanced Search
advertisement

RESOURCE PORTALS
View all Portals

WEB SEMINARS
Scheduled Events

RESEARCH VAULT
White Paper Library
Research Papers

CAREERZONE
View Job Listings
Post a job

Advertisement

INFORMATION CENTER
DM Review Home
Newsletters
Current Magazine Issue
Magazine Archives
Online Columnists
Ask the Experts
Industry News
Search DM Review

GENERAL RESOURCES
Bookstore
Buyer's Guide
Glossary
Industry Events Calendar
Monthly Product Guides
Software Demo Lab
Vendor Listings

DM REVIEW
About Us
Press Releases
Awards
Advertising/Media Kit
Reprints
Magazine Subscriptions
Editorial Calendar
Contact Us
Customer Service

Beyond the Data Warehouse:
EIA Framework Definition, Part 5 - The Devil is in the Details

online columnist John Ladley     Column published in DMReview.com
November 18, 2004
 
  By John Ladley

This article is the fifth in a series on defining, planning and rolling out the appropriate plans, policies and structures to manage information, i.e., information architectures.

Since we are now half way through this series, it is good to review the enterprise information architecture (EIA) process to date.

In general, EIA projects move iteratively from high-level concepts, principles and strategies to specific plans and deliverables. In the project initiation step, we aligned business drivers and EIA objectives. We then moved into discovery, where the emphasis is on future state and vision. The last article was on preliminary designs, where we began to close gaps between current and future state and provide more details that will shape the business IT organization. We are now ready to examine the final two steps: filling in the details of the EIA and the value that will add to the business and the roll out strategy. This article and the next will cover the details of EIA.


Figure 1

Other methodologies, of course, may offer differing sequences or emphasize different deliverables. However, the key with all approaches to EIA is to consistently continue to align business needs (at deeper levels of details) with the appropriate information management 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.

The information asset architecture step pulls all of the details together and develops the comprehensive statement of EIA.

Basic Deliverables

Every EIA project will differ from any other EIA project at this point. For example, in an organization where tools and technology are well established, this phase may emphasize the information value chains, process flows and business model, while another organization will require just the opposite emphasis.

In general, this step must produce the first real tangible picture of what the EIA will resemble. This means the interaction of various components of the EIA must be presented in a form that grasps the EIA vision. Finalization of presenting this vision is obtained by building a series of deliverables:

  • Specify the information delivery framework by analysis of measures (readers of this column have seen this in several previous articles). The previous article (see October column http://www.dmreview.com/article_sub.cfm?articleId=1011657) displayed an abstract presentation of the components of the EIA. Now the interfaces between these must be specified. For example, how does the meta data layer collect and provide meta data? How does the movement of operational data to decisional framework operate? (See Figure 2 for review and example.)


    Figure 2: Sample EIA Components

  • Identify the business value chains of each key subject area, i.e., the processes that create and add value to specific information areas (customer, product, etc.). In certain cases, the EIA will even suggest new business models if the task of alignment and information usage has been done correctly.
  • Lock down a concise presentation of requirements that will drive the EIA, i.e., merge the data from the measures, the value chains and any previous work (data quality, for example) and present a summary of drivers for the EIA. Usually, some sort of affinity analysis and/or matrices to cluster requirements is developed at this point. These requirements and cluster-type analyses will drive technical architecture and suggest applications and technical projects to roll out the EIA.
  • Identify opportunities for hard business returns by examining the potential contribution of the EIA to the business. This is done by prorating business benefits from attaining business objectives across various components of the EIA. The argument that the business will not allow IT to claim credit is not valid. The EIA team should cross-reference business benefits with components of the EIA anyway. For example, if the enterprise wants to reduce customer churn and the objective results in $10 million is cash flow if attained, prorate the $10 million across the components of the EIA that will assist in delivering this objective.

Common errors made at this juncture include:

  • Merging technical recommendations with the other deliverables. This section must be reviewed and approved before technology can be explored.
  • Failure to pursue business results that will result from components of the EIA

At this point, the EIA project is coming together, and there are a lot of details still left to address. Models and other forms of data collection and analysis are blended to extract a series of deliverables that start to deliver a solid picture of how the EIA will look, operate and provide business returns.

The contents of this article are Copyright 2004 by DM Review and KI Solutions. Any use, quotation, r-purpose, duplication or replication of the diagrams, concepts or content without permission of DM Review and the author is prohibited.

...............................................................................

For more information on related topics visit the following related portals...
Enterprise Achitecture.

When John is not writing poetry as a hobby, he is a director for Navigant Consulting, which recently acquired KI Solutions, a management consulting firm specializing in knowledge and information asset management and strategic business intelligence planning and delivery. Ladley is an internationally recognized speaker and, more importantly, hands-on practitioner, of information and knowledge management solutions. He can be reached at jladley@navigantconsulting.com. Comments, ideas, questions and corroborating or contradictory examples are welcomed.



E-mail This Column E-Mail This Column
Printer Friendly Version Printer-Friendly Version
Related Content Related Content
Request Reprints Request Reprints
Advertisement
advertisement
Site Map Terms of Use Privacy Policy
SourceMedia (c) 2006 DM Review and SourceMedia, Inc. All rights reserved.
SourceMedia is an Investcorp company.
Use, duplication, or sale of this service, or data contained herein, is strictly prohibited.