Geog 463: GIS Workshop

1
Geog 463 GIS Workshop

• May 15, 2006
• Information Systems Architecture
• Reading Zachman 1987

2
Outlines

• Introduction
• Architectural representations
• Types of descriptions
• Framework for information systems architecture
• Conclusions

3
Introduction

• GIS as an information system (IS)
• One of difficulties in understanding IS
  architecture is that constituent components do
  not share the same terminology any way to unify
  the term in a semantic level?
• The purpose of this lecture is to provide
  framework in which different representation
  scheme of those components are understood and
  communicated (i.e. semantically interoperable)
• Multiple spectrums are needed to view what
  constitutes GIS as an information system

4
Why do we need interoperable terms for
information systems architecture?

• What businessman meant differs from what
  programmers meant
• The same term, but they refer to different things
  depending on who they are
• What things look like differs from how things
  work
• The same term, but they refer to different things
  depending on what you describe
• Necessary to define the term based on
  participants view and types of description
• Participants view owner, designer, builder
• Types of description data, process, network

5
Three main participants- analogy of
architectural concept -
Owner
2) Architects drawings
1) Bubble charts
3) Architects plans
4) Contractors plans
Designer
Builder
6
Analogy of architectural concept

• Architects bubble charts ballpark view
• Mutual understanding between architect and owner
• Architects drawings owners view
• A transcription of the owners perceptual
  requirements
• Tasks to be accomplished given resources (time,
  budget)
• Architects plans designers view
• A translation of the owners perceptions/requireme
  nts into a product
• Tasks translated into a physical product
• Constructors plans builders view
• The plans representing builders perspective
• How tasks are accomplished given technology
  constraints

7
Architectural representations of information
systems

• Each of the architectural representations differs
  from the other in essence, not merely in level of
  detail

8
Different types of descriptions

• The same product can be described differently
• Data model What things are made of,
  entity-relationship-entity
• Process model How things work,
  input-process-output
• Network model Where the flow exists,
  Node-line-node

9
Matrix of IS architecture

• Two axis of the framework for information systems
  architecture are identified
• (1) Architectural Representations
• It represents different perspectives of the
  different participants
• Owner, designer, builders view
• Business, information system, technology model
• (2) Types of Descriptions
• The same product can be described, for different
  purposes, in different ways
• Structure, transform, flow
• Data, process, network (connectivity)

10
Matrix of IS architecture

• Each element on either axis of the matrix is
  explicitly differentiable from all other elements
  on that one axis
• Different in content, meaning, motivation, and
  use.
• E.g. In the data column, entity is seen as
  business entity from owners point of view, data
  entity from designers point of view, and data
  row from builders point of view

Data Process Network
Owner
Designer
Builder
11
The Framework for Information Systems Architecture
Owners view
Designers view
Builders view
Zachman 1987
12
1. Architectural representations for describing
the data

• Business scope (ballpark perspective)
• A list of all the things that are important to
  the business (e.g. product, part, supplies,
  employee, promotion, customer order, shipment)
• It supports strategy/resource investment
  decisions
• Business model (owner perspective)
• Entity means business entity (e.g. DEPT, PROJ)
• Relationship means the relationship between
  business entity (mn relationship is allowed)
• Information systems model (designer perspective)
• Concepts independent of specific technology
• Entity means data entity (e.g. DEPT, DEPTPRJ,
  PROJ)
• Relationship means the relationship between data
  entity (mn relationship is not allowed)
• Technology model (builder perspective)
• Technology constraints are being applied
• Entity means technology-constrained equivalent
  (e.g. row, segment)
• Relationship means technology-constrained (e.g.
  key, pointer)

13
2. Architectural representations for describing
the process

• Business scope (ballpark perspective)
• A list of business process not definitive about
  I/O
• Business model (owners perspective)
• Process means business process
• I/O means business resources
• e.g. Functional flow diagram
• Information systems model (designers
  perspective)
• Process means application process
• I/O means user views (i.e. some aggregation of
  data elements that flow into and out of the
  application processes)
• e.g. Data flow diagram
• Technology model (builders perspective)
• Process means computer function
• I/O means device formats
• e.g. Structure chart

14
3. Architectural representations for describing
the network

• Business scope (ballpark perspective)
• A list of locations in which the business
  operates
• Support strategy/resource investment decision for
  selecting the subset of locations in which to
  actually location technology
• Business model (owner perspective)
• Node means business units at some geographic
  locations
• Line means logistics connections or flow
• Information system model (designer perspective)
• Node means information system function
• Line means characteristics of communication line
• Technology model (builder perspective)
• Node means physical hardware and software
• Line means specifications of line

15
Conclusions

• Information system architecture can be understood
  in two aspects type of description and
  architectural representation
• Architecture can be described differently based
  on type of description data, process, and
  network
• Architecture can be viewed differently based on
  participants view owner, designer, and builder
• Role of designer is to bridge perception
  structure of owners to that of builders