Introduction to
Information Architecture
Informatics Training for
CDC Public Health Advisors
Imagine building a house..

without any architectural plans

with only general sketches as to how it’s supposed to look,
or only detailed diagrams for wiring, plumbing, etc.

with each subcontractor doing whatever they thought best,
without consulting with the owner or other contractors

with no specialized functions for the rooms (e.g., every
room has its own little stove, bed, bathtub…)

where the house had to be torn down to remodel one room
S.O.P. for building information systems in public health.
Information architecture

A metaphor for a systematic, ‘planful’ approach to
building enterprise-wide information systems.
Information architecture refers to the totality of the data,
processes, and technology used in a given enterprise, and
the relations between them.
It includes databases, applications, standards, procedures,
hardware, software, networks, etc.
Attributes of a good architect





Can communicate well with the customer
Can develop general drawings and diagrams based on the
descriptions of customer’s wants and needs
Can develop more specific drawings and diagrams for
communicating with the builders (general contractor and
subcontractors)
Can communicate well with the builders, and help devise
solutions as problems present themselves
Can provide a consistent, overall vision throughout the
project, and work with the customers and the builders to
achieve that vision.
An information architecture …


Provides a guiding plan across projects
Promotes component orientationsmaller units,
more easily upgraded

Eases maintenance, by defining ‘natural
boundaries’ between information systems (e.g.,
budgeting, surveillance)

Simplifies systems, by decreasing redundancy of
data entry, storage
An information architecture …

Breaks big problems into manageable chunks

Allows the efficiency and interoperability inherent
in standards

Promotes planning, clarifies business processes

Facilitates solving a common problem once,
instead of solving it many ways, many times

Allows flexible incorporation of new IT
An information architecture …

Returns locus of control and decision making to
the executive level, away from the IT community.
An information architecture provides the basis of
business control over the distributed development
of information systems.
Information architecture ‘views’

Multiple levels of architectural plans are needed,
from the general (representing overall ‘business’
processes & objectives), to the specific (indicating
specific technology and implementation details)

The specific (technical) views of the architecture
should be based on higher, business views--i.e.,
the IT architecture should be tightly tied to the
business processes and objectives
Information architecture ‘views’

Business views of the architecture What needs
to be automated

Information technology views of the architecture
 How that should be automated

Business views should be relatively stable; IT
views should be able to adapt to improvements in
technology
The Zachman Framework

A two-dimensional structure for describing the
information architecture of an enterprise

1st dimension: the roles involved in information
systems design (planner, owner, designer, builder)

2nd dimension: What, How, Where, etc.
ENTERPRISE ARCHITECTURE - A FRAMEWORK
DATA
OBJECTIVES/
SCOPE
Planner
ENTERPRISE
MODEL
Owner
MODEL
OF THE
INFORMATION
SYSTEM
Designer
TECHNOLOGY
MODEL
Builder
DETAILED
REPRESENTATIONS
SubContractor
What
List of Things Important
to the business
FUNCTION
How
List of Processes the
Business Performs
NETWORK Where
List of Locations in
Which the Business
Operates
ENTITY = Class of Business Process = Class of Business Node = Major Business
Location
Thing
Process
e.g. "Semantic Model"
e.g. "Business Process Model"e.g. "Business Logistics
System"
Node = Business Location
Ent = Business Entity
Proc = Bus Process
Link = Business Linkeage
Reln = Business Relationship I/O = Bus Resources
e.g. "Logical Data Model"
e.g. "Application Architecture"e.g. "Distributed System
Architecture"
Ent = Data Entity
Reln = Data Relationship
e.g. "Physical Data Model"
Proc = Application Function
I/O = User Views
(Set of Data Elements)
e.g. "System Design"
Ent = Segment/Row/etc.
Reln = Pointer/Key/etc.
e.g. "Data Definition"
Node = Hardware/Systems
Proc = Computer Function
Software
I/O = Screen/Device Formats Link = Line Specifications
e.g. "Program"
e.g. " Network Architecture"
Ent = Field
Reln = Address
Proc = Language Statement
I/O = Control Block
Node = Address
Link = Protocol
e.g. FUNCTION
e.g. NETWORK
FUNCTIONING
e.g. DATA
SYSTEM
Node = I/S Function
(Processor, Storage, etc)
Link = Line Characteristics
e.g. "System Architecture"
Info Architecture “pearls”




We need to develop high-level blueprints of our
public health agencies’ information needs, and use
these blueprints to guide systems development
Tools exist to help with this process (e.g., the
Zachman Framework)
New information systems applications should be
developed within the context of a larger, coherent
information architecture
Public health leaders, not technologists, must drive
the process
Info Architecture “pearls” (cont’d)

See Cook’s Building enterprise information
architectures for an excellent review of this area.

More to come: We will revisit the idea of
information architecture on Thursday.