Article summary "A framework for information systems architecture"

FACULTÉ DES SCIENCES DE LA SOCIÉTÉ

A framework for informationsystems architecture

28/02/2017Dejan Munjin

FACULTÉ DES SCIENCES DE LA SOCIÉTÉInstitute of Information Service Science

1. Descriptive, neutral, objective framework for information system architecture2. Define and control the interfaces and the integration of all the components of

the system3. Limits: framework limited to architecture and does not include a strategic

planning methodology

Main issues addressed


• Technology is removing conceptual and financial constraints and allows flexibility in managing business

• Decentralization without structure is chaos and requires a disciplined approach to the management of distributed systems

Technology progress


• A common definition lacks in the community of professionals• Derived concept from architecture itself to classify concepts and definitions

Architectural Concept


• Bubble charts: depict, in gross terms, a basic intent of the final structure• The architect is drawing a transcription of the owner’s perceptual requirements• Each bubble represents a room, its gross size, shape, spatial relationship, etc.

Concept: Bubble charts


• Transcription of the owner’s perceptual requirements, a depiction of the final product from the owner’s perspective

• Level of detail required for the prospective owner to understand and approve the design

Concept: Architect’s drawings


• Translation of the owner’s perceptions/requirements into a product• Designer’s representation of the final product (as opposed to an owner’s

representation)• Explicit specification• Final deliverables prepared by the architect• The architect’s plans are prepared to serve as a basis for negotiation with a

general contractor

Concept: Architect’s plans


• Builder’s perspective• A phased approach is required (phases and technology constraints)

Concept: Contractor’s plans


• Subcontractor’s perspective• Subsection with out-of-context specification

Concept: Shop plans


• Final representation

Concept: The building


• Comparison with military manufacturing

• Bubble charts = Concepts• Architect’s drawing = Work breakdown structure• Architect’s plans = Engineering design• Contractor’s plans = Manufacturing engineering• Shop plans = Assembly and fabrication drawings• + Machine view is an additional representation• Building = Airplane

• Representations/Concepts that are likely to be produced in building any complex product

Generic set of architectural representations


• 3 Fundamental representations, one for each player: owner, designer, and builder

• Each representation displays a level of detail greater than the previous one and represents a different perspective/essence

• Less an architecture than the actual representation of activities

Prerequisites for IS Architecture


Prerequisites for IS Architecture


• Each description is unique and stands alone because each serves quite different purposes

• None of the descriptions explicitly says anything about any of the other descriptions

Different types of descriptions for the same product


Different types of descriptions for the same product

The Framework

A readable image: https://www.zachman.com/images/ZI_PIcs/ZFW1987-7in.jpg

https://www.zachman.com/images/ZI_PIcs/ZFW1987-7in.jpg

https://www.zachman.com/images/ZI_PIcs/ZFW1987-7in.jpg


• Ballpark view: gross size and scope, list of things• Model of business: subset of elements to implement in an Information System• Model of information system: adds “artificial” entities• Technology model: depending on the choice, the meaning of entity and

relationship change• Detailed description: Data Definition Language, This description is “compiled”

to produce the machine language representation

The Framework Views


• Process description• Network description• Data description

The Framework Processes


• There is not an information systems architecture, but a set of them• We are having difficulties communicating with one another about information

systems architecture, because a set of architectural representations exists, instead of a single architecture

• The architectures are different, they are additive and complementary• Research is being done to create more explicit definitions for each of the

architectural representations in this framework

• Possibly rethinking the nature of the classic “application development process” as we know it today

Conclusions


By Marcel Douwe Dekker based on earlier work of Phogg2 et al. - self-made, combination of File:Zachman Framework Basics.jpg and File:Zachman Framework.jpg, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=5590426

Extension and formalizationThe Who, When and Why columns were brought into public view, the notion of the four levels of metaframeworks and a depiction of integration associations across the perspectives were alloutlined in the paper.

https://commons.wikimedia.org/w/index.php?curid=5590426


• Your own experience with the elements of the framework ? (Ex. Communication difficulties, understanding difficulties, etc)

• Any other examples ?

Short Case Study


• First study limited to 3 types of descriptions: WHAT, HOW, and WHERE• Information Systems Architecture does not define in detail what the models

should contain, it does not enforce the modeling language used for each model, and it does not propose a method for creating these models.

Critical view / Limits


• J. A. Zachman, “A Framework for information systems architecture”, IBM SYSTEMS JOURNAL, VOL 26, NO 3, 1987

• https://www.zachman.com/images/ZI_PIcs/ibmsj2603e.pdf• https://www.zachman.com/

Citations and References

https://www.zachman.com/images/ZI_PIcs/ibmsj2603e.pdf

https://www.zachman.com/