[comp.software-eng] ZOOM, an OO Information System Modeler

schultz@grebyn.com (Ronald Schultz) (08/17/90)

The Object-Oriented Information Systems Architecture Modeler


The following documentation introduces the The Object-Oriented
Information Systems Architecture Modeler (ZOOM for short).

In the November, 1987 volume of the IBM Systems Journal, John
Zachman of the IBM Los Angeles Scientific Center presented an
Information Systems Architectural Framework he found useful in
communicating what was involved in the design, implementation,
and maintenance of information systems.

In the article abstract Zachman states:

     "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."

If understanding information systems architecture is important to
the development of information systems, the question that
naturally arises is "What, in fact, is Information Systems
Architecture, and of what use is it?"

ZOOM was developed to assist the information systems planner,
developer, and manager in exploring system architecture; that
combination of goals, strategies, requirements, hardware, and
software that must be coordinated to provide an enterprise with
information.  ZOOM provides facilities for the modeling of
information systems and their relationships using the Zachman
Framework.  This modeling includes data, process, and network
components.  ZOOM allows one to selectively, or globally,
evaluate the impact of new or changed information system
components on the overall information systems architecture.  The
outputs of ZOOM demonstrate the ties between a proposed system
and the defined user requirements, strategic business goals, and
business function.  These outputs can be formatted to support
system lifecycle documentation such as system and subsystem
specifications, unit or program specifications, data dictionary
specifications.

ZOOM can also be used independently of information systems
planning to perform such activities as business strategic
planning and organization analysis.

WHY ZOOM ?

ZOOM extends existing CASE technology.  While many CASE tools
have extensive facilities for data modeling, data flow
diagramming, and structure charts, few provide facilities for
system modeling within a corporate architectural framework.  ZOOM
complements existing CASE technology by linking business goals to
business functions to information system requirements to possible
implementations of the requirements.  These links can then be
animated via scripts.  The execution of these scripts allows
anyone, analyst and end-user alike, to view how requirements will
be satisfied by a new or existing system.

The scripting facility of ZOOM can be tailored to the unique
requirements of the effort.  This scripting allows the analyst
and end user to communicate interactively about candidate
implementation approaches.  

In addition, ZOOM allows one to look at a particular information
system component, i.e. a screen or report or file, and trace the
component to the information system requirement, and then to the
business function, and finally to the business strategic goal.

ZOOM has import facilities that allow the user to import
information from existing files directly into ZOOM.  Most CASE
vendors provide export facilities for their products.  These
exported files can by processed by a user-developed program to
format it for ZOOM use.  ZOOM has been used with both IEW and
EXCELERATOR in this manner.

The availability of a CASE tool is not required for ZOOM.  If
CASE is available, ZOOM can leverage the existing investment
without having to rekey.

ZOOM HISTORY

ZOOM represents the author's research into the application of the
Zachman framework into real life information system problems. 
The author has been involved in the reengineering of a number of
large systems, in both the commercial and Federal areas.  In
these efforts, the author was tasked to present an approach that
would provide, in advance of actual development, a model that
would assure the funders of the system that the new system would
better meet user requirements.  

In these efforts structured analysis and design graphics were
prepared to provide these models.  In one instance the system
being reengineered was only 18 months old.  Its implementation
had been a fiasco.  While functionality was there, online data
entry transactions often took 3 minutes to complete. During a
presentation of the new design graphics to an audience of end-
users and funders of the proposed reengineered system, the
Comptroller of the enterprise commented: 

     'We saw all these wonderful graphics with the previous
     contractor.  They look great.  But all they talk to is data. 
     They are 'data flows'.  When the previous system was
     delivered, the data was right, but performance and the
     internal processes themselves were flat out terrible.  We
     don't want to be taken down the primrose path again.  What
     can you come up with that will show our requirements taken
     down, step by step, to actual code within your proposed
     system ?

From listening to similar comments from end-users and funders for
a number of years, and seeing presentations of an Information
Systems Framework as presented by John Zachman of IBM, came the
approach now represented in ZOOM.      

THE ZACHMAN INFORMATION SYSTEMS ARCHITECTURE - AN OVERVIEW

The reader is referred to the November 1987 IBM Systems Journal
article for a full presentation of the architecture framework.   
In summary 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 paraphrasing of Zachman's framework graphic is presented
below.  
---------------------------------------------------------------

                         Data           Process        Network

Objectives/Scope          D1              P1             N1

Model of the              D2              P2             N2
Business

Model of the              D3              P3             N3
Information 
System

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, or a
conceptual data model.

D3 would involve fully attributing the conceptual model, and
normalizing it.  Thus developing a Logical Data Model of the
enterprise.

D4 would involve taking the logical data 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 some form of
magnetic, or possibly optical, media.

---------------------------------------------------------------
The Process column views the 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 program source code for the systed, and

P6 as the compiled object code of the system.

The Network column views the information system from a 

     NODE ---- LINK ---- NODE perspective.

Please refer to the article for elaboration of this column.

As Zachman is quick to point out, the framework provides an easy
means of classifying many information system 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, D3, P1, P2, P3

To date, this classification has been the primary use of the
framework.  In addition, information systems 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 or blocks of COBOL code.  His view of
a system is characterized by modules, paragraphs, sections, and
I/O calls.  A CEO views an information system as something 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.  

What the Zachman Framework highlights is that each cell
represents a different "architectural representation"  or set of
representations as to what the system is.  By making these
representations explicit, the Zachman Information Systems
Architecture Framework does much to address possible
communication difficulties that may occur between residents of
different cells.

The Zachman framework has had a significant impact on IBM and its
dealings with customers.  At one point there was even rumor as to
organizing portions of IBM and GUIDE itself along the lines of
the Zachman framework.  

By capitalizing on this framework, ZOOM extends the power of the
Zachman framework into routine system analysis and design
activities.

WHAT IS ZOOM ?

ZOOM is a Smalltalk application program written in Digitalk's
V/286 for MS-DOS compatible machines.  ZOOM requires a 100% IBM
compatible 286 or 386 central processor and a mouse.  ZOOM can be
loaded onto a machine with 2 megabytes of memory and at least 10
megabytes of free hard disk space.  4 megabytes of random access
memory is the recommended configuration for the serious user. 
ZOOM will run with LAN software operating, but since ZOOM runs in
DOS protected mode, no extended memory managers can be present,
such as QuarterDeck's QEMM and similar products.  These must be
removed from the CONFIG.SYS of the PC, and the PC rebooted prior
to ZOOM being brought up.  ZOOM is not Windows compatible.

Since ZOOM is a Smalltalk V/286 application program, the user is
required to own a copy of Digitalk's Smalltalk/V 286.  This can
be procured directly from Digitalk, or through a number of
software resellers.

ZOOM presents to the user a graphical user interface consisting
of an information systems architecture framework graphic, pull
down menus to select actions, and a Cell Browser that provides
for the inputting and updating of classes and operations loaded
to ZOOM.

ZOOM is engineered in an object-oriented programming language,
but ZOOM does not enforce any object-oriented analysis and design
methodology.  ZOOM is methodology independent, and has been used
in process-centered as well as data-driven development efforts.  

GETTING A COPY OF ZOOM

ZOOM Version 1.0 will be made available on COMPUSERVE and BIX
information networks by September 1, 1990.  This is a full
implementation of ZOOM, not a scaled down demonstration copy. 
Additional functionality may be incorporated at a later date.  If
enough interest is expressed, ZOOM may be extended into a shrink-
wrapped product and marketed through conventional distribution
channels, with an appropriate support base and ongoing updates. 
ZOOM is not FREEWARE or PUBLIC DOMAIN software.  It is being
placed on these networks to explore user interest, as well as to
provide information systems professionals a tool to expand
communication both internal to their department and with the end-
users and funders of their systems.

All comments and suggestions are welcome, and can be E-mailed on
USENET to schultz@grebyn.com, on COMPUSERVE to 72247,1270, and on
BIX to ronschultz, or sent to the address given later in this
document.

ZOOM is made available on these networks in PKZIP EXE files
downloadable via any binary protocol such as XMODEM or KERMIT. 
These file are self extracting and do not require that the user
own a copy of PKZIP.

USENET users may request a copy by sending 2 3-1/2 inch 1.44 meg
floppies, or 3 5-1/4 inch diskettes, to the following address:

     Ron Schultz
     5634 Claire Court
     Dublin, Ohio
     43017

Also enclose a self-addressed stamped envelope with the
appropriate postage attached.  I also request you include a
business card, and a brief description of your current job
activities and interests.

All documentation is supplied on the diskettes in ASCII format,
and in WordPerfect 5.0.  The WordPerfect documentation contains
extensive graphics and sample problems.