Published in TDAN.com October 2002
Overview
The endeavors most commonly seen today in the IT world have a wide coverage are usually departmental or enterprise wide. Either a Data Warehousing effort or the consolidation of many disparate
applications into an integrated system, such a project is usually characterized by a long duration and a large number of resources utilized.
Enforcing order in a wide area project is a huge task in itself. Combined with a lack of enterprise perspective when the systems were initially built, the data integration and consolidation
problems complexity increases exponentially. For both companies building a new IT structure, or re-building the existing one, the need for a systematic approach is obvious.
Many methods and methodologies attempt to solve the organizational issue. Most of them, especially the ones derived from software development methodologies, tend to focus too much on the technical
side, without considering much the human resource involved. But the most common causes of failure for large projects reside in the human aspect and business environment, rather then in the
methodologies, technologies or techniques used.
Introduced by John A. Zachman in 1987, its Enterprise Architecture Framework provides a blueprint to organize the information and study the interactions between the various components involved. The
generic classification scheme defined by John Zachman is based on analyzing the contributing factors at each defined level of abstraction, for each of the defined activity layers. The Framework was
extended in 1982 to respond not only to what, how and where, but also to who, when and why (see Figure 1 below or www.zifa.com/frmwork2.htm).
Architecture Framework Extension
Our consulting and software development practice led us to customize the initial framework to better reflect current architectural standards and best practices. We applied the Zachman’s
Framework to Rational Unified Process and to Oracle’s Custom Development Method, our main software life-cycle methodologies for Java-based and Oracle-based projects, respectively.
Even during the theoretical integration it became quite obvious that the framework artifacts only displays what have to be done and further detailed definition of each
cell is required to streamline the framework usage in real-life projects. Applying the framework’s paradigm for each of its cells, we reached a complete definition of each artifact consisting
of:
- what have to be performed;
- how the information will be presented;
- where is the information captured;
- who will perform the work required;
- when is the activity located in the project time line;
- why do we have to do it?
Each of these subjects map to the original framework structure, so we defined the following topic-based frameworks:
- Development Framework, describing what has to be done for each artifact;
-
Metadata Framework, containing the description of the information to be collected and how will it be organized (what data elements are sufficient to ensure that the
information is completely described); - Documentation Framework, displaying the standard documents where the information will be captured;
- Responsibility Framework, showing who (from the development team) will perform the required activities;
- Life Cycle Framework, showing when the artifact occurs during the project duration;
- Purpose Framework, describing why we need to include that artifact in the framework.
The above topics define another dimension for the Zachman’s framework, transposing it into a tri-dimensional analytical cube, where the axis are defined by the abstraction level (height), the
activity layer (width) and the topic layer (depth). The Extended Analytical Framework resulted from this exercise is presented in the figure below:
Figure 2: Extended Architecture Framework
The framework’s height represents the abstraction levels used to perform the analysis:
- Business Environment is the highest abstraction layer, usually represented by fuzzy ideas or idealistic concepts (contextual level).
- Enterprise Model represents the conceptual level, defining the business concepts the enterprise operates with.
- System Model includes a complete logical specification of the concepts defined at Enterprise Level.
- Technology Model defines the physical objects that will represent the logical structures.
- Detailed Representation layer is composed by the description of the physical implementations of each category.
- Functioning Enterprise is the physical layer where the systems become “real”, usable from the user’s point of view.
The main enterprise activity layers are represented on the framework’s width:
- Data layer reflects information representation.
- Function column is concerned about actions performed with the data.
- Hardware layer is an encompassing column for all the computers, networking and other supporting equipment.
- People column shows the actors involved in the process.
- Time represents the scale associated with the time elements on each abstraction level.
- Motivation is the engine of getting the things done.
The framework’s depth is composed by the topics detailing the original framework:
- Development describes what will be performed for each artifact;
- Metadata is the description of the information to be captured;
- Documentation shows where the information will be located;
- Responsibility specifies what member(s) of the team will perform the work;
- Life Cycle places the artifacts alongside the project timeline;
- Purpose reflects the reason to perform the work required.
3D Framework Layers
Both Rational Unified Processâ and Oracle’s Custom Development Method, as well as most software development methodologies, are focused on deliverables and tasks required to deliver the
final product. As an information classification matrix, the Generic Analytical Framework ensures that we do not lose the sight of the whole picture while focusing on details. The structured
approach guarantees not only that no detail will be overlooked, but also that the effort is synchronized across all its perspectives.
The following figure presents the Software Development Framework, showing how all the pieces of the puzzle fit together to reflect the complete development endeavor. It defines what will be
performed throughout the project development cycle, without necessary sequencing them based on the time line or any other criteria.
The how question is responded by the Metadata Collection Framework, that describes the pieces of information to be collected to specify the corresponding what artifact. Of
course, based on the specific project requirements, how we describe each architectural piece may vary, sometimes significantly. The framework below presents some ‘standard’ metadata
topics, without exhaustively covering the topic.
The how artifacts (metadata) about the what artifacts (architectural components) are captured during the software development cycle through a more or less formal documentation process. In
the where framework we propose a formal set of documents that is consistent with both Oracle CDM and Rational Unified Process methodologies.
It is of equal importance to identify the right people to do perform the tasks required by the architectural artifacts (what). Very often the roles in a software development team have many
overlaps, or the same person may play different roles, to a point where it is difficult to distinguish between who is supposed to do what. The Responsibility Framework
presented below uses the most generally accepted role titles to define who performs the activities related with each architectural component.
When certain tasks have to be performed it is not easy to specify. The new software development methodologies like the Boehm spiral model (iterative development) and RAD
(Rapid Application Development) induce much more flexibility then the classic waterfall model. The only common denominator that spans across most of the development methodologies is the almost
universal compliance with the PMI project management principles. For this reason, the Life-Cycle Framework is based on the project phases and processes defined by the Project Management Institute
in the PMBOKâ.
Last but not least we considered the driving force behind the success of any development project, and even any human endeavor: peoples motivation. Why are we performing an
activity is proven to be much more important then the working conditions or the tools available. But much too often the motivational component is put aside by managers faced with
“burning” budget or schedule issues. The Purpose Framework presented in the figure below was therefore included in the complete architectural approach to reflect once more its integral
role in a completed methodology.
Conclusions
The Zachman’s Framework for Enterprise Architecture is one of the most useful analysis tool, especially because of its neutrality versus the development methodology used during the software
life-cycle. As presented above, it can actually be customized to encompass in a unified view multiple methodologies.
The 3-dimensional extension proposed in this article expands on the concepts introduced by John A. Zachman by applying the what, how, where,
who, when and why to each artifact from the initial framework. Each layer can be used as a separate framework, but the spatial model adds the
perspective needed for a completeness point of view.
Applying the presented framework to all the projects, either enterprise wide or subject oriented, ensures a conceptual consistency across the entire information processing structure. It also
enables a completeness check for the project in itself and for its integration in the overall enterprise system.
Further definitions of each artifact are in progress and will be published in future editions of this publication, as well as on Open Data Systems web site (www.opendatasys.com). This article was previously published in The Journal of Conceptual Modeling located at www.inconcept.com/JCM/index.html.
