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

View all Portals

Scheduled Events

White Paper Library
Research Papers

View Job Listings
Post a job


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

Buyer's Guide
Industry Events Calendar
Monthly Product Guides
Software Demo Lab
Vendor Listings

About Us
Press Releases
Advertising/Media Kit
Magazine Subscriptions
Editorial Calendar
Contact Us
Customer Service

Beyond the Data Warehouse:
Starting the EIA, Part 2 - Project Initiation

online columnist John Ladley     Column published in DMReview.com
July 15, 2004
  By John Ladley

This series of articles focuses on defining, planning and rolling out the appropriate plans, policies and structures to manage information, i.e., information architectures. Part 2 describes key tasks to ensure a good start.

For this third article on enterprise information architecture (EIA) will assume that the go-ahead has been given from management to, at minimum, explore the business case and start to plan the management of information as an asset. Rarely does a CIO/CEO authorize the implementation of EIA without some initial consideration of the business impact. As a result, initiating the EIA project has extra tasks in addition to the normal start-up activities.

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 normal start-up activities are, of course, identification of scope, definition of project objectives, identification of champions/steering bodies, selection of the team/consultants and completion of a project plan. It must be noted that even though these are "typical" of any project, the EIA effort project plan may require explanation to many of the stakeholders before it is signed off. At this point, the EIA team may as well adopt a mind-set that they will constantly be selling and explaining this project. This will factor into the project communications plan, which although typical, is often poorly detailed and not followed.

A normal activity for project initiation, but one we see overlooked often in EIA efforts, is the need to create standards around how things are going to be organized. This includes work files, deliverables, team procedures and policies. For example, projects often start without really collecting past artifacts and getting them in order (let alone read them). Plan to get them if at all possible.

Finally, many projects start with some inventory of current technology and legacy applications. This is encouraged, although we prefer to see an emphasis on a high-level data quality view of the inventory. In any EIA, the sooner data issues surface, the sooner they can be factored in. Extra activity to initiate an EIA effort often stems from the cultural and business impacts of EIA. Several events must happen at this time to present the team with additional information about where to focus extra marketing, education and risk management efforts.

Understand the Culture

First, the team must understand what type of culture is in place at an organization and define how that culture views, treats and uses information. This is crucial. At first blush, one may want to say, "Hey, we are in the same industry as our competitors, so we can use the same EIA approach." This is a mistake. Most often, companies within the same industry have very different information cultures, e.g., insurance company A may be dominated by actuaries and insurance company B may be dominated by marketing. This presents two different information cultures.

In general, the team must classify the culture as to its degree of centralization of information management, its maturity in managing information and how its processes depend on information. For example, again, insurance company B may view information as a lubricant, i.e., make jobs easier in functional silos, whereas A may view information more as fuel for the business engine. (See Part 2 of the series.)

Develop a Business Case

Most of the time, the team is tasked to do a business case that will justify proceeding with the EIA. If done during project initiation, the team has a good grasp of what costs are (they are developing the project plan), and they are positioned to gather business objectives and benefits. Therefore, during this step, the team needs to gather business objectives and goals, and translate those into benefits associated with managing information. This exercise is best done via researching documents (i.e., annual reports, budget documents, etc.) vs. interviews. Interviews at this time will "put off" the executive team.

The business case should be a collection of examples of how information will generate bottom-line benefits and present cash flows, internal rates of returns and Net Present Values of the IT portfolio.

The business case aligns the usage of information to achieve corporate goals with the associated cash flows from the processes that will use the managed information. Yes, you naysayers are now saying, "But we never get the credit for the benefits when information is used to improve the business." That statement is irrelevant at this time. The business case is for enterprise benefits; we will cross the "who gets credit" topic in a future article.

Threat Analysis

The final, unusual step for many projects is a formal analysis of threats and risk to project success. It is best to break these risks into our old comfortable classifications of people, process and technology. Who are the people, internal and external, who can threaten the EIA project? This means taking a hard look at the politics in IT and the company in general. A classic example of risk is the clash between information managers and applications developers, whereas the latter will tend to view the information managers as slowing down the delivery process of applications to users.

Process risks usually stem from companies being very siloed. Many companies are built around hand-offs to other processes, and the cultural view of data integration tends to be one of data synchronization, vis--vis integration of processes via good information.

Technology risks will stem from the degree that data is dispersed through the organization, copied and replicated as well as infrastructure challenges, such as geography, time zones, etc. For example, many companies are replication crazy, with redundant subsets of core domain data living in every single department. This presents a risk to EIA given that these departments will not want to surrender their data fiefdoms.

The goal of the threat analysis is to be able to correlate business benefits to the perceived impact on culture. Culture change becomes much more likely if there is a chance to miss tremendous opportunity due to cultural issues.

The project initiation step for EIA must feature the typical steps that happen in any project, but must also pay attention to the cultural and risk components that tend to derail these types of projects. The final PI deliverable will not only feature the EIA project plans and deliverables but also a series of tactics to mitigate the cultural and political barriers. These tactics will affect the choice of techniques and facilitation that occur in the upcoming discovery and design steps.

The contents of this article are Copyright 2003 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.


For more information on related topics visit the following related portals...
DW Design, Methodology.

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.

Solutions Marketplace
Provided by IndustryBrains

Design Databases with ER/Studio: Free Trial
ER/Studio delivers next-generation data modeling. Multiple, distinct physical models based on a single logical model give you the tools you need to manage complex database environments and critical metadata in an intuitive user interface.

Data Quality Tools, Affordable and Accurate
Protect against fraud, waste and excess marketing costs by cleaning your customer database of inaccurate, incomplete or undeliverable addresses. Add on phone check, name parsing and geo-coding as needed. FREE trial of Data Quality dev tools here.

Free EII Buyer's Guide
Understand EII - Trends. Tech. Apps. Calculate ROI. Download Now.

dotDefender protects sites against Web attacks
30-day evaluation period for dotDefender, a high-end cost-effective security solution for web servers that protects against a broad range of attacks, is now available. dotdefender supports Apache, IIS and iPlanet Web servers and all Linux OS's.

Click here to advertise in this space

E-mail This Column E-Mail This Column
Printer Friendly Version Printer-Friendly Version
Related Content Related Content
Request Reprints Request Reprints
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.