Continue in 2 seconds

Starting the EIA, Part 3 - Discovery

Published
  • August 26 2004, 1:00am EDT

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 3 discusses the key components of requirements and gap analysis.

Once the enterprise information architecture (EIA) team gets started (with project initiation and support from management), the first order of business is what we call discovery. You may see this process called visioning, strategic requirements or some similar name.

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 crucial goal during this step is to begin to align the business with information usage and information management. Then using the cultural research and business facts gathered previously, (see Part 2) develop a Gap Analysis.

Many strategic planning processes contain this type of step. It is really nothing new. There are pitfalls, however, if you fail to address certain key aspects unique to EIA:

  • Overemphasis on technology
  • Alignment with hip and chic vs. culture
  • Failure to take culture into gaps
  • Poor business involvement
  • Poor consideration of processes
  • Failure to consider regulatory and other legal risks as a portion of alignment

However, like our other steps, there will be some special additions to make the EIA safe from prior pitfalls of strategic engagements.

Basic Deliverables

During this step, the EIA team will work to align the business with the concepts if EIA. In addition they will develop conceptual visions of information architecture that allow the business to see the benefits and the "day-in-the life" after the EIA becomes real. Finally, the team will develop baseline (or conceptual) models that provide objective descriptions of the business' information requirements.

Again, other processes may place different labels on these steps, but the essence here is alignment of the business to information strategy. Please do not overlook the importance of an objective, methodical exercise for alignment. We have seen too many so-called "strategies" that have been nothing more than implementation plans for a particular technology or architecture.

The conceptual vision usually takes the form of a high-level series of scenarios, or processes, that are derived from business objectives married to information usage. For example, one insurance company may do business in a market that requires in-depth knowledge of customers for underwriting purposes, while another may require in-depth knowledge of customers for creasing more effective distribution channels. While customer information is featured in both cases, these are two different alignment circumstances and, most often, will result in two different strategies.

The models at this point take the form of conceptual data models (a conceptual model is usually at the subject area level and defines core, or primary definitions, of subjects. If possible, identify key identifiers for these subjects and basic, but not normalized, cardinalities. In essence, a shell is created to hold additional information requirements as they evolve. The subject areas provide an agreeable list of high-level information requirements that can be cross-referenced to the vision, or usage, scenarios (see Figure 1). Finally, this level of data model serves to confirm scope and context of the EIA effort.


Figure 1: Subject Areas Provide List of Requirements

Metrics-based models should be initiated at this stage as well. A metrics model provides two crucial elements. It describes the means by which the business objectives will be measured by providing a list of these key measures. The metrics model also provides a list of data elements required to produce these metrics. The term "model" may be misleading, as it is a list of measures and required data components. The term model is used at this point to remove an uneasiness from business users of finality.

The lists of metrics, subjects and business objectives can be used to from the basis for a variety of alignment analyses. For example, abstract the classic affinity analysis to a higher level, and you have a fine tool to show where information is required to satisfy business needs. (See Figure 2.)


Figure 2: Affinity Analysis

There are a wide range of concepts, philosophies and techniques to exercise during the discovery or visioning portion of an EIA project. However, it is key to remember that you are striving for objective alignment. Again, it is key to not even mention schemas, frameworks, tools or software at this point.

Regardless of technique, there need to be three core models:

  • Information (conceptual data model) - represents content and context
  • Measurement - represents required content and attributes by documenting metrics
  • Scenario/Process Vision - represents value-added usage and ties the business needs to the evolving EIA vision

These deliverables develop a series of shells, or templates, to further develop more detail that will objectively support your EIA design, road map and detailed business changes.
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