World Applied Sciences Journal 3 (Supple 2): 43-49, 2008
ISSN 1818-4952
© IDOSI Publications, 2008
A Methodology to Create Data Architecture in Zachman Framework
1
Reza Rezaei and 2 Fereidoon Shams
1
Computer Engineering Department,
Faculty of Engineering,Islamic Azad University of Saveh Branch, Saveh, Iran
2
Computer Engineering Department, Shahid Beheshti University, Tehran, Iran
Abstract: Lack of methodology for applying Zachman framework is a challenge that an architect who use
it will face. Although there have been methodologies which were some how mapped with this framework
but until now no methodology has supported one or more columns of this framework completely and in an
integrated way. In this paper, we proposed an integrated process for developing Data Architecture views in
Zachman framework. One of the most important advantages of this approach is its property which is based
on the enterprise's strategic plan, goals and responsibilities, Business and applications Architecture.
Key words : Zachman framework • methodology • data architecture • enterprise architecture framework •
modeling.
INTRODUCTION The rest of this paper is organized as follows.
In Section 2, we introduce Zachman Framework.
It goes without saying that nowadays utilizing Next, the problem was defined in section 3. We discuss
information and communication technologies in our proposed approach in section 4 and present a
enterprises is one of the most challenging tasks. An case study in section 5. Finally, in section 6, we
enterprise is considered a set of elaborate physical and make conclusions and suggest some comments for
logical processes in which information flow plays a future works.
crucial role. The common way to comprehend
procedures in an enterprise is to provide views of Zachman framework: In 1987, an IBM researcher,
components within that enterprise, which is called named John A. Zachman, proposed a framework for
architecture. Architecture, such as Data Architecture Information System Architecture, which is now called
represents only a single view of an enterprise, but Zachman Framework (ZF) [1-5]. Zachman borrowed
Enterprise Architecture refers to a collection of the term architecture from the building trades and
architectures which are assembled to form a discussed the various types of drawings and blueprints a
comprehensive view of an enterprise. Organizing such building architect typically developed in order to create
great amounts of information requires a framework. a house. He then suggested parallels in software
Among various proposed frameworks, the Zachman development. He stressed that an organization does not
Framework (ZF) is one of the most considerable ways have a single architecture, but has, instead, a whole
of conceptualization. ZF is widely accepted as the main range of diagrams and documents representing different
framework in EA. Compared to other proposed aspects or viewpoints and different stages. In the years
frameworks, it has evident advantages, nevertheless; since he wrote his original article, Zachman has worked
there are challenges to overcome, among them is the to refine and elaborate his framework. Figure 1
absence of a methodology to specify modeling provides an overview of the current Zachman
approach. Framework. ZF is a two dimensional information
The challenge we referred to is also addressed in matrix consisting of 6 rows and 6 columns.
other researches. Several solutions have been The vertical dimension (the rows) describes the
proposed in order to create a methodology, however perspectives of those who use the models or
achieving no success in thoroughly covering all descriptions contained in the cells. The top row
aspects of the framework. The proposed approach in represents the most generic perspective of an
this paper represents a methodology to create Data organization, while lower rows are successively more
Architecture in ZF. concrete. The bottom row represents a description of
Corresponding Author: Reza Rezaei, Computer Engineering Department, Faculty of Engineering,
Islamic Azad University of Saveh Branch, Saveh, Iran
43
World Appl. Sci. J., 3 (Supple 2): 43-49, 2008
Zachman refers to it as a sub-contractor’s perspective
and this makes sense to software developers when the
design is implemented with modules or components
acquired from others.
The functioning enterprise: The bottom row
represents the actual deployed or running elements, data
and people of the organization. It isn’t a perspective, as
such, but the “real world,” in all its complexity, that
underlies all of the more or less abstract perspectives
above it.
The horizontal dimension of the framework (the
column s) describes the types of abstractions that define
each perspective. These abstractions are based on the
widely used questions that people have historically
asked when they sought understanding. The six
Fig. 1: Zachman framework questions or types of abstractions are as follows:
the actual data, code and people that make up the Data: What is it made of? This focuses on the material
enterprise. composition of the product. In the case of software
The perspectives, starting from the top of systems, it focuses on data. Zachman has proposed a
Fig. 1, are: simple, illustrative model for each of the columns. In
this case, the model is: Thing-Relationship-Thing.
Scope: (Contextual) The Planner’s Perspective. This
Function: How does it work? This focuses on the
describes the models, architectures and representations
functions or transformations of the product. The model
that provide the boundaries for the organization and
is: Process-Input/Output-Process
describe what senior executives must consider when
they think about the organization and how it interacts
Network: Where are the elements located relative to
with the world.
one another? This focuses on the geometry or
connectivity of the product. The model is: Node-Line-
Business model: (Conceptual) The Owner’s
Node
Perspective. This describes the models, architectures
and descriptions used by the individuals who are the People: Who does what work? This focuses on the
owners of the business process. They focus on the people and the manuals and the operating instructions
usage characteristics of the products. or models they use to perform their tasks. The model is:
People-Work-People
System model: (Logical) The Designer’s Perspective.
This describes the models, architectures and Time: When do things happen? This focuses on the life
descriptions used by engineers, architects and those cycles, timing and schedules used to control activities.
who mediate between what is desirable and what is The model is: Event-Cycle-Event
technically possible.
Motivation: Why do things happen? This focuses on
Technology model: (Physical) The Builder’s goals, plans and rules that prescribe policies and ends
Perspective. This describes the models, architectures that guide the organization. The model is: End-Means-
and descriptions used by technicians, engineers and End
contractors who design and create the actual product.
The emphasis here is on constraints and what will The problem space: ZF is widely accepted as the main
actually be constructed. framework in EA. Compared to other proposed
frameworks, it has evident advantages to list: (1) using
Detailed representations: (Out-of-Context well-defined perspectives, (2) using comprehensive
Perspective) A Sub-Contractor’s Perspective. This abstracts, (3) normality and (4) extensive usage in
describes the actual elements or parts that are included practice, nevertheless; there are challenges to
in, or make up, the final product (e.g. software overcome, among them is the absence of a
components). Using the construction metaphor, methodology to specify modeling approach.
44
World Appl. Sci. J., 3 (Supple 2): 43-49, 2008
Although some methodology were suggested for information analysis
data analysis of
ZF, but none of them succeed to cover all aspects of the start
enterprise strategic
of enterprise goals
framework. We can refer to EAP as the best and missions
methodology suggested for ZF, however, it addresses
two rows of the framework and can't support the lower information analysis
ones. of enterprise goals
ZF expresses what information must be created for and missions
each cell of the framework; however, it doesn't indicate
how this information must be created. We are not
information analysis
intended to address this as ZF weak points, since ZF is
of enterprise goals
just a framework, not a methodology. Anyhow, an
and missions
architect who uses ZF has to overcome this problem.
Due to importance of data in an enterprise, an
approach is proposed to show how Data models can be A
È
created in ZF. This approach contains steps that are
required to create a Data Architecture in the framework.
Each step indicates how the required information Fig. 2: Planner-data cell extract process
should be gathered and how they should be used to
create appropriate models for each cell in ZF. extract important describe important
We use strategic planning, goals and functions to A data entities information entities
extract data architecture. Hence, this approach is Data-
centric and will align Data architecture to Function
architecture. Proposed approach can be used as an
extract important
integrated process to cover all cells from Planner to data entities relations
Sub-contractor's perspective. Note that we will drop the
Function Enterprise row, since it is not a model but a
real world. Figure 2 depicts the problem space.
describe important
information entities
Proposed approach: In this section we define the Data
relations
column cells and present our approach to extract Data
architecture.
B
Planner-data cell ("List of Things Important to the
Business")
Define: This is simply a list of things (or objects, or Fig. 3: Owner-data cell extract process
assets) that the Enterprise is interested in-the
"universe of discourse" relative to things. It is probably Solution: In this perspective important data entities and
adequate that this list is at a fairly high level of their relations extract base on planner's perspective
aggregation. It defines the scope, or boundaries, of the outputs [2-10] Fig. 3.
Rows 2-5 models of things that are significant to the
Enterprise [5]. Designer-data cell ("Logical Data Model")
Define: This is a model of the logical (implementation-
Solution: Data hierarchy can be extracted based on data technology neutral) representation of the things of the
analysis of enterprise strategic plan, enterprise goals Enterprise about which it records information (in either
and enterprise missions [2-10] Fig. 2. automated or non-automated form). It would be
represented as a fully attributed, keyed, normalized
Owner-data cell ("Semantic Model") E/R-type model reflecting the intent of the Semantic
Define: This is a model of the actual Enterprise things Model [5].
(objects, assets) that are significant to the Enterprise. It
typically would be represented as an “E/R”-type model Solution: first, E/R model extracts based on owner's
and would be at a level of definition that it would perspective outputs. Next, this model will be
express concepts (terms and facts) used in the normalized. After normalizing, data entities will be
significant business objectives/strategies that would crossed with process entities. Finally, data entities
later be implemented as "Business Rules" [5]. identifications will be extracted [2-10] Fig. 4.
45
World Appl. Sci. J., 3 (Supple 2): 43-49, 2008
create database
B extract E /R model normalize E /R model management define data, access
D system and levels, and data
database control instructions
architecture
cross data entities describe data
with process entities definition/
manipulation
program and design
user interfaces
extract data entities
identifications define maintenance
scenarios , and
database
performance
C
E
Fig. 4: Designer-data cell extract process
Fig. 6: Subcontractor-data cell extract process
convert E/R model normalize data
C
to data model model
Subcontractor-data cell ("Data Definition")
Define: This would be the definition of all the data
objects specified by the Physical Data Model and would
questions and include all the data definition language required for
transactions analysis implementation[5].
Solution: first, database management system and
database architecture will be created. Next, data and
Specify files
structures and
their control and access levels instructions will be
indexes defined. After that, data definition and data
manipulation program will be described. Finally, user
interfaces, maintenance scenarios and database
performance will be defined [2-10] Fig. 6.
D
Case study: In previous section, an integrated way for
creating various views of data architecture within
Fig. 5: Builder-data cell extract process Zachman framework was presented. Since the
suggested solutions in the field of enterprise
Builder-data cell ("Physical Data Model") architecture are less supportable by formal methods, it
Define: This is a technology constrained, or physical is common to examine their creditability through case
representation of the things of the Enterprise. The studies. Conducting case studies through suggested
representation style of this model would depend on the solutions will evaluate the efficiency of the proposed
technology chosen for implementation. If relational method as an actual criterion.
technology is chosen, this would be a model of the table Ports & shipping organization of Iran (Shipping
structure required to support the Logical Data Model in and Marine affairs authority) is the organization that we
a relational-style model. In an Object-Oriented notation, aimed at study its data architecture based on the
this would be the class-hierarchy/association style suggested method.
models [5]. It must be noted that as the constructor and the
subcontractor views require designing and
Solution: In this perspective, the E/R model converts to implementing the physical model and definition of
data model. Next, data model will be normalized. After organization data, they were not addressed in this study.
that, questions and transactions will be analyzed and
will be improved if require. Finally, files structures and Creating programmer cell: The strategic plan and
indexes will be specified [2-10] Fig. 5. organization goals are presented in Table 1.
46
World Appl. Sci. J., 3 (Supple 2): 43-49, 2008
Table 1: Strategic plan and organization goals
Type Title
Strategy Programming for most compliance with regulations of adjoined international conventions
Strategy Continuous establishing and issuing national standards regarding security, search and rescue
Strategy Improving the coordination between local, provincial and national operational potentials,
preventing and dealing with security issues, security and protection of marine environment
Goal Improving security level in marine transportation and shipping subdivision
Goal Improving the level of health and protection of marine environment Better compliance with
international conventions and membership in them
Goal Improving the ability of rescuing natural disaster casualties
Table 2: Hierarchy of data issues
Field Data issue
Marine Information about vessel transportation in the canal Information
about delivering services to the vessel and marine units
Coastal stations and transitional equipments information
Hydrography and dredging information
Shipping Information about marine training and shipping certifications
Information about vessels registry
Security Information about canal security
Information about vessel security control and inspection
Information about marine search and rescue
Information about ship and merchandise salvation in the sea
Environmental protection Information about pollution prevention and avoidance
Information about de aling with marine disasters
International relationships Information about membership in international conventions
Information about membership in international communities
Table 3: Important data issues
Issue Entity
Information about vessels registry Information about vessel flag registry
Information about canceling vessel registry
Information about repairing and changing vessel user
Information about manufacturer and vessel repairing companies
Information about issuing technical and security certification for vessels which are under the flag
Information about vessel mortgage registry
Organization goals and roles, data issues and their Each of important information entities are
hierarchical structure are extracted by analyzing extracted after identifying and describing the
strategic plan data and information which is shown in relationships between important data entities. Then,
Table 2. each of these relationships are described. For example,
In the fourth step, the identified and extracted data the relationship between a given entity with other
issues are explained generally. entities is shown in Table 4.
Creating the owner cell: In this section, Creating the designer cell: In this view, an integrated
important data entities of organization are extracted relationship-entity model is extracted based on
based on data issues created in the programmer view. extracted entities and relationships in the owner view
For example, extracted data entities which are and initial normalization is conducted on it. In the third
important for marine vessels registry data issue are step, the extracted entities are adapted with processes to
shown in Table 3. check and analyze entities validation and to identify
47
World Appl. Sci. J., 3 (Supple 2): 43-49, 2008
Table 4: Relationships between entities
Entity Related entities
Information about vessel flag registry Information about issuing technical and security certifications for vessels which are under the flag
Control and inspection of the vessel security
Information about radio services
Informatio n about issuing the vessel license
Information about servicing to the vessel
License for transmission equipments and assigning codes
Information about the vessel mortgage registry
Information about repairing and changing user vessel
Information about canceling long term vessel registry
Information about manufacturer and vessel repairing companies
Table 5: Adaptation of entities with processes
Entities
--------------------------------------------------------------------------------------------------------------------------------
Vessel Inspecting the vessel Information about Information about
Functions manufacturing request being constructed vessel temporary registry vessel administration
Recording vessel registry request CRU
Vessel temporary registry R R CRU
Canceling vessel temporary registry U
Change in vessel administration RU
Table 6: Results of questionnaires
Products answer Complete (%) Acceptable (%) Incomplete (%) Absolutely no (%) White (%)
Data issues 7 83 7 3 0
Data entities 12 78 7 1 2
Data entities relationships 13 77 5 2 3
Entity-relationship model 10 78 9 11 2
Adapting entities with processes 11 74 7 3 5
Data entities identification card 10 73 8 2 7
required application systems. Then, the data entities • The suggested method for creating data
identification card is extracted. For example, a part of architecture based on Zachman framework has
entities adaptation with the processes is presented in been des igned and implemented as a known
Table 5. framework.
In order to evaluate the accuracy and • The suggested method will present in detail the the
correctness of the presented method for creating process of creating all data architecture views.
integrated data architecture and examining outputs • One of the other suggested method is that
and manufactured products, some questionnaires organizations architects can create their own data
were provided for the organization architects and architecture using this method.
managers. • In the third step, the suggested method for creating
The results of these questionnaires that are shown data architecture considers the process of creating
in Fig. 6, will prove the accuracy and correctness of the data architecture designer view, data architecture
method presented for creating all data architecture equivalence and the function through adapting
views. entities with processes.
• The suggested method for creating data
CONCLUSION architecture considers the equivalence of data
architecture with the organization strategic plan by
Generally, the benefits of the suggested method for data analysis of the organization strategic plan and
creating data architecture in Zachman framework can information analysis of the goals in the
be explained as follows: programmer level.
44
World Appl. Sci. J., 3 (Supple 2): 43-49, 2008
• The suggested method make the data architecture 4. Sowa, John F. and A. Zachman, John, 1992.
inclusive through creating all data architectures in Extending and Formalizing the Framework for
Zachman framework. Information Systems Architecture. IBM Systems
• Examining data architecture in each step of its Journal, 31 (3): 590-616.
creating process is possible through using the 5. Zachman, J.A., 2003. The Framework for
suggested method and following the steps defined Enterprise Architecture. Cell Definitions. ZIFA.
for each data architecture views. 6. Popkin’s System Architect, 2004. Building
• Since in Zachman framework the criterions are Enterprise Architecture: The Popkin Process,
well defined and all required activities are exactly Popkin Company.
defined, lower time and cost is required to create 7. Villiers, D.J.De, 2001. Using the Zachman
various data architecture views and this can be Framework to Assess the Rational Unified Process.
considered as one of the other benefits of this IBM Rational Edge.
method. 8. Dennis, M. Ahern, Clourse Aaron and Turner
Richard, 2003. CMMI Distilled, A practical guide
REFERENCES to integrated process improvement, Second Edn.,
Addison Wesley, Part1, Chapter 1.
1. Spewak Steven, H., 1993. Enterprise Architecture 9. Blueprint Technologies, 2004. Best practice
Planning: Developing a Blueprint for Data, approach to enterprise architecture. 8618
Applications and Technology, John Wiley and Westwood Center Suite. 310, Vienna, VA 22182,
Sons. United States. 2. NASA-ESDIS, Bldg 32, Rm
2. Zachman, J.A., 2003. The Zachman Framework: A S224C Mail Code 423.
Primer for Enterprise Engineering and 10. Martin, James, 1990. Information Engineering,
Manufacturing. Prentice Hall.
3. Zachman, J.A., 1987. A Framework for
Information Systems Architecture. IBM Systems
Journal, Vol; 26 (3).
44
