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 GISas 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) Architect’s drawings 1) Bubble charts 3) Architect’s plans 4) Contractor’s plans Designer Builder

6. Analogy of architectural concept • Architect’s bubble charts – ballpark view • Mutual understanding between architect and owner • Architect’s drawings – owner’s view • A transcription of the owner’s perceptual requirements • Tasks to be accomplished given resources (time, budget) • Architect’s plans – designer’s view • A translation of the owner’s perceptions/requirements into a product • Tasks translated into a physical product • Constructor’s plans – builder’s view • The plans representing builder’s 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, builder’s 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 owner’s point of view, data entity from designer’s point of view, and data row from builder’s point of view

11. The Framework for Information Systems Architecture Owner’s view Designer’s view Builder’s 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 (m:n 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 (m:n 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 (owner’s perspective) • Process means “business” process • I/O means business resources • e.g. Functional flow diagram • Information systems model (designer’s 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 (builder’s 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