Alexander Cullen Principal Analyst Forrester Research

Simplifying Information ArchitectureAlexander CullenPrincipal AnalystForrester Research

November 9, 2005. Call in at 12:55 p.m. Eastern Time

2Entire contents © 2005 Forrester Research, Inc. All rights reserved.

Theme

Information architecture enables better decisions to enhance IT delivery. It is

an essential deliverable of an EA.


Agenda

• Drivers for information architecture

• How: overview of frameworks and methodologies

• Best practices


Drivers for information architecture

• Business operating model change/enhancement

» Improving customer focus/responsiveness

» Changing distribution models

» Supply chain efficiencies

» …

• Business management needs

» “Know the customer”

» Product and channel profitability

» Financials and compliance

» …


Drivers for information architecture cont.

• Information accessibility» Complete and accurate

» Consistent

• Information quality» “one version of the truth”

» Accurate/action-oriented business metrics

• New business applications» Data sourcing

» Data formats and definitions

» Cross-referencing structured data and unstructured content

• IT storage and processing costs» Proliferation and redundancy

» Batch cycle windows


Definition

• Information architecture is a framework providing a structured description of an enterprise’s information assets and the relationship of those assets to business processes, business management, and IT systems.


Business process and business management model

Business information conceptual entities

Structured data Content

Conceptual data model – major entities, attributes, relationships

Taxonomy

Information entity mapping to applications and repositories

Data flows and systems of record

SchemasLogical data model – major entities, attributes, relationships

Physical data stores and repositories

Operational and analytical data Content

Customer Product Financial Sales Email Documents Images Web

Storage

Policies governing ownership and access

Principles

Standards

Structure of information architecture


Relationship of information architecture to business and application architecture

Business architecture

Ap

p. a

rch

. (d

om

ain view

)

Infrastructure architecture

Info

. arc

h.

App arch. (design view)

App arch. (portfolio view)

Business process architecture

How: overview of frameworks and methodologies


IA mapped to Zachman framework

Data – “What”

Function – “How”

Network – “Where”

People – “Who”

Time – “When”

Motivation – “Why”

Scope – “Contextual”

Enterprise – “Conceptual”

System model – “Logical”

Technology model – “Physical”

Components

Source: www.zifa.com

Information Architecture


TOGAF architecture development method (ADM)Prelim:

Framework & Principles

Architecture Vision

Business Architecture

InfoSystemArch.

TechnologyArchitecture

Opportunities & Solutions

Migration Planning

Implementation Governance

Change Mgmt.

Requirements

Information Architecture

SystemArch.


The Open Group Architecture Framework (TOGAF) v8.1

Prelim:Framework & Principles

Architecture Vision

Business Architecture

InfoSystemArch.

TechnologyArchitecture

Opportunities & Solutions

Migration Planning

Implementation Governance

Change Mgmt.

Requirements

Baseline Description

Principles Reference Models

Viewpoints Tools

ArchitectureModels

Architecture Building Blocks

Stakeholder Review

QualitativeCriteria

CompleteArchitecture

Gap Analysis


NASCIO information architecture templates

Process Component Definition

Name Description Rational Benefits

Component Classification Classification

Related Domain / Subject Area Business Domain Information Subject Area

Business Rules Owner Classification Rule Statement

Critical References

Related Business Components Business Architecture Relationship BusArch Component Relationship

Related Information Components Supplier Input component Output Component Consumer

Related Gap Component Gap Component

Information Meta Component - Conceptual Definition

Name Industry Desc. Rationale …

Critical References Data Element Concept Relationship

Process Component Relationship

Application Relationship

Conceptual Information Model Link or Identifier

Logical and Physical Content Entity / Class Definition

Entity/Class Name Description Source Name

Critical References Logical Information Model Link or Identifier

Related Attributes

Name Description Sample Class Security Rules


IA within US federal enterprise architecture — reference models

Business Reference Model (BRM)• Lines of business• Agencies, customers, partners

Service Component Reference Model (SRM)• Service domains, service types• Business and service components

Technical Reference Model (TRM)• Service component interfaces, interoperability• Technologies, recommendations

Data Reference Model (DRM)• Business-focused data standardization • Cross-agency information exchanges

Bu

siness-D

riven A

pp

roach

Performance Reference Model (PRM)

• Inputs, outputs, and outcomes• Uniquely tailored performance indicators

Federal Enterprise Architecture (FEA)

Co

mp

on

ent-B

ased A

rchitectu

re

Ownedbyline ofbusinessowners

Owned byfederalCIO council


Forrester’s best practices

• Build an iterative plan focused on pain points

» Incremental build-out with limited scope per iteration

» Structure iterations around business and IT pain points.

» Define your pain-solving strategy.

» Target deliverables to stakeholders’ needs.

» Gain stakeholder agreement on scope and deliverables.


Defining IA deliverables

What is being documented How to show it

Business view Information in relationship to key business concepts and processes

Conceptual data model Business process – to – CDM Data life cycle Conceptual DFD

Information in relationship to applications

Application inventory – to – CDM Logical and physical DFD Logical data model for applications Data and metadata standards Data sourcing and source of record Road maps

IT view

Information Infrastructure Architecture patterns for key data store, service, and application types

Tool/technology/physical design standards PDM for applications Policies and processes Road maps


Example: building the plan

Building the plan Hypothetical example

• Plan for incremental build-out

Initially focus on product profitability and information on product cost, selling price, and service cost.

• Structure iterations around pain points

Business can't accurately understand product profitability due to multiple definitions for products, costs, and prices.

• Define your pain-solving strategy

Develop end-to-end architecture for product information, and work with business and AD to incorporate into projects.

• Target deliverables to stakeholders

End-to-end solution architecture that business understands, plus road map and detailed models for AD.

• Gain stakeholder agreement

Product management, AD teams for manufacturing, order management, and customer service systems, IT portfolio management office all agree on iteration scope, goals, and deliverables.


Forrester’s best practices cont.

• Use a top-down approach to sustain focus

» Model the in-scope business areas.

» Define “logical target state” before investigating current state.

» Develop multiple alternatives for closing gaps.

» Address policy and process gaps.

» Identify metrics that link IA deliverables to results.

» Couple IA implementation to business functionality.


Example: sustaining the program

Sustaining the program Hypothetical example

• Start at high level with model of in-scope business areas.

High-level process and information model for manufacturing, sales, and customer service

• Define logical target state before investigating current state.

Target state architecture for product information capture, aggregation, and reporting

• Develop alternatives to close gap between current and target states.

Alternatives for how information is extracted and aggregated for reporting, such as using data abstraction layers

• Address policy and process gaps. Data ownership defined for product manufacturing, sales, and service data

• Identify metrics which link IA deliverables to results.

Metrics reported for conversion of existing systems to common data definitions

• Couple IA implementation with specific business functionality.

Implementation coupled with upgrades to manufacturing ERP application and enhancements to service applications.


Diagnostic: How do you know you’re on the right track?

On the right track Cause for re-evaluation

Program scope Iterative across businesswide problem space, with each iteration producing timely, useful deliverables.

“Boil the ocean” – tackling too much breadth across business and depth of detail before useful deliverables are complete.

Stakeholders Identified, broadly based, regular check-in with sponsors.

Stakeholders not identified or narrowly based. Check-ins ad hoc or absent.

Business and IT drivers – “pain points”

Specific, measurable, solv-able: “improve quality of customer data as measured by.”

Nebulous – “Information is our most important asset.”


Diagnostic: How do you know you’re on the right track?

On the right track Cause for re-evaluation

IA program priorities and goals

Clear and validated by stakeholders

Unclear or not validated

Approach for driving change

Clear outcomes that IA deliverables direct

Unclear outcomes or unclear linkage to IA deliverables

Deliverables Targeted to stakeholders’ needs

Stakeholders don't find deliverables clear or relevant

Program metrics Outcome as well as progress-based

Lack of or progress-based metrics only

Value message Elevator pitch – crisp, relevant, succinct: “solve this problem by … which will produce the following results …”

Fuzzy


Alex Cullen

+1 617/613-6373

[email protected]

www.forrester.com

Thank you


Selected references

• September 9, 2005, Best Practices “Simplifying Information Architecture”

• June 16, 2004, Best Practices “Creating the Information Architecture Function”

• May 12, 2004, Forrester Big Idea “Organic Information Extraction”

• September 9, 2004, Quick Take “The Revival Of The Enterprise Data Model”

• August 18, 2004, Best Practices “Data Warehousing Architecture Alternatives”

• May 7, 2004, Best Practices “From Defect Inspection To Design For Information Quality”

• March 17, 2004, Best Practices “Standards For Enterprise Architecture”