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.
3Entire contents © 2005 Forrester Research, Inc. All rights reserved.
Agenda
• Drivers for information architecture
• How: overview of frameworks and methodologies
• Best practices
4Entire contents © 2005 Forrester Research, Inc. All rights reserved.
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
» …
5Entire contents © 2005 Forrester Research, Inc. All rights reserved.
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
6Entire contents © 2005 Forrester Research, Inc. All rights reserved.
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.
7Entire contents © 2005 Forrester Research, Inc. All rights reserved.
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
8Entire contents © 2005 Forrester Research, Inc. All rights reserved.
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
10Entire contents © 2005 Forrester Research, Inc. All rights reserved.
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
11Entire contents © 2005 Forrester Research, Inc. All rights reserved.
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.
12Entire contents © 2005 Forrester Research, Inc. All rights reserved.
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
13Entire contents © 2005 Forrester Research, Inc. All rights reserved.
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
14Entire contents © 2005 Forrester Research, Inc. All rights reserved.
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
15Entire contents © 2005 Forrester Research, Inc. All rights reserved.
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.
16Entire contents © 2005 Forrester Research, Inc. All rights reserved.
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
17Entire contents © 2005 Forrester Research, Inc. All rights reserved.
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.
18Entire contents © 2005 Forrester Research, Inc. All rights reserved.
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.
19Entire contents © 2005 Forrester Research, Inc. All rights reserved.
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.
20Entire contents © 2005 Forrester Research, Inc. All rights reserved.
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.”
21Entire contents © 2005 Forrester Research, Inc. All rights reserved.
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
22Entire contents © 2005 Forrester Research, Inc. All rights reserved.
Alex Cullen
+1 617/613-6373
www.forrester.com
Thank you
23Entire contents © 2005 Forrester Research, Inc. All rights reserved.
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”