schultz@grebyn.com (Ronald Schultz) (11/30/90)
In the November, 1987 volume of the IBM Systems Journal, John
Zachman of the IBM Los Angeles Scientific Center proposed an
Information Systems Architectural Framework he found useful in
communicating to a company what was involved in the design,
implementation, and maintenance of information systems.
"The subject of Information Systems Architecture is currently
receiving considerable attention. The increased design scopes
and levels of complexity of information systems implementation
necessitate the use of some logical construct (or
architecture) for defining and controlling the interfaces and
the integration of all of the system's components. ...
On the assumption that an understanding of information systems
architecture is important to the development of a disciplined
approach, the question that naturally arises is "What, in
fact, is Information Systems Architecture ?"
Zachman's framework was based on his research into the paradigms
associated with the engineering of complex products such as
buildings and aircraft. The framework was presented as a matrix
with columns representing three paradigms:
1. Material/ Structure - Thing / Relationship / Thing
2. Functional / Transform - Input / Process / Output
3. Geographic / Flow - Site / Link / Site
A rough approximation of the information systems framework is
presented below. This is based on Zachman's addressing
organizations with background in COBOL, RDBMS, MIS kinds of
applications.
---------------------------------------------------------------
Data Process Network
Objectives/Scope D1 P1 N1
Model of the D2 P2 N2
Business
Model of the D3 P3 N3
Information
System
In the November, 1987 volume of the IBM Systems Journal, John
Technology D4 P4 N4
Design
Technology D5 P5 N5
Definition
Technology D6 P6 N6
Implementation
---------------------------------------------------------------
The Data Column looks at an information system from a bill of
material, or component perspective.
Objects populating Cell D1 would be things of interest to the
enterprise, such as competitors, products, services, employess,
etc.
D2 would consist of a basic ER model of the business.
D3 would involve fully attributing the ER model, and normalizing
it. Developing it into a "Data Model".
D4 would involve taking the ER model and designing databases to
support it.
D5 would involve the language specific definition of database
tables to implement the above generated models.
And D6 would be the actual system data, stored on media.
---------------------------------------------------------------
The Process column views and information system from an
INPUT --> PROCESS --> OUTPUT view.
Cell P1 would consist of processes of interest to the enterprise,
such as the building of an aircraft, shipping to a customer of
product, or the development of new retail services.
P2 could be a set of Function Flow Diagrams detailing the flow
of information between business processes.
P3 is often seen as Data Flow Diagrams.
P4 as Structure Charts, and
P5 as the actual program.
The Network column views the information system from a
NODE ---- LINK ---- NODE perspective.
I can detail these columns at a later time, if there is any
interest.
The point of this is that the Zachman framework has had a
significant impact on IBM and its dealings with customers. At
one point there was even discussion as to organizing IBM along
the lines of the Zachman framework. IBM has requested that
vendors supplying tools for its AD/Cycle Repository product
directly address the Zachman framework in some as yet
undetermined fashion.
As Zachman is quick to point out, the framework provides an easy
means of classifying many IS products, tools, and techniques.
A brief table of some classifications are:
Tool / Technique / Product Appropriate Cells
ER Modeling D2, D3
Dataflow Diagramming P2, P3
Structured Analysis P3, P4
Structured Design P3, P4
Data Normalization D3
Code Generation P5
COBOL P4, P5
Business Systems Planning D1, P1, N1
Critical Success Factors D1
Information Engineering D1, D2, P1, P2
The above is a rough cut and is arbitrary at best. No flames
please.
In summary, IS professionals have found the Zachman Framework
extremely powerful in aiding communications between residents of
different cells within the framework. For example, a COBOL
programmer views an information system probably from cell P4 or
P5. He sees the system most often as a structure chart. His
view of a system is characterized by modules, paragraphs,
sections, and I/O calls. A CEO views an information system as
somethings that assists him in dealing with objects in D1 and D2,
such as profits, customers, and competitors, and the corporate
organization and structure. A Data Administrator views the
system as a data model. Each cell represents a different
"architectural representation" or set of representations as to
what the system is. By making these representations explicit,
much can be done to overcome, or at least address, the
communication difficulties of translating concept to executing
system.
Finally, my question. I have been asked repeatedly by attendees
at IBM conferences as to how OO techniques impact on the Zachman
framework. Is the Zachman framework even appropriate for an OO
environment ? What would the cells of the framework be populated
with in an OO approach ? What other kinds of frameworks for
information systems are available ? Has anyone done any
enterprise modeling based on this, or any other framework, in an
object-oriented fashion ?
I will post a summary to the net if there is sufficient interest
in this topic.
Ron Schultz
schultz@grebyn.com
614 759-3127