Zachman Framework: My Experience

As a rule of thumb, when I approached for business process improvements or systems development request, I ask the 6 W questions (What, How, Where, Who, When and Why). As I got better with this methodology, I came across SDLC best practices and finally found the Zachman framework.

What is the framework?

The Zachman Framework is a comprehensive, logical structure for descriptive representations (i.e., models) of any complex objects. It is neutral with regard to specific processes or tools used for producing the descriptions. The Framework, as applied to enterprises, is helpful for sorting out complicated technology and methodology choices and issues that are significant to general and technology management and identifying the kinds of models for a given project.

The Zachman Framework provides a common context for understanding a complex structure. The Framework enables communication among the various participants involved in developing or changing the structure. Architecture is the glue that holds the structure together. The Framework defines sets of architectures that contain the development pieces of the structure.

The Zachman framework gathers and refines principles from older methods. It has a structure (or framework) independent of the tools and methods used in any particular IT business. The framework defines how perspectives are related according to certain rules or abstractions. A framework takes the form of a 36-cell table with six rows (scope, business model, system model, technology model, components, and working system) and six columns (who, what, when, where, why, and how) as shown in the figure below.



The rows of the Zachman Framework define the various perspectives of the enterprise and the various roles in the enterprise using that information.
1. Scope (Contextual/Planner view): Definition of the enterprise’s direction and business purpose. It includes enterprise’s vision, mission, boundaries and constraints. Usually these are textual artifacts/definitions providing the context for each column for e.g. the “Why” column cell will contain the business goals, performance measures for each function. The “What” would contain the various high level data classes required etc. The idea here is to identify the requirements and the external drivers affecting the enterprise and perform business function modeling.
2. Enterprise Model (Conceptual/Owner’s view): At this level more focus is towards the business and the associated processes. At each column level information is gathered with the business processes in perspective. For e.g. to answer “Why” you will define the policies and procedure for the processes, the “How” would be the Business process definition itself, the “Who” would be the roles and responsibilities for each of these processes.
3. System Model (Logical/Designer’s view): This defines the business described row 2, but in more details. At this level the logical models are defined for each row cell. For e.g. A logical data model is created to identify the data flow for achieving the business data requirements specified in row 2. Similarly logical network models are created to understand the network setup required.
4. Technology model (Builder’s view): This describes how technology may be used to address the high level needs identified in the previous rows. Various technology related decision like decision for the DBMS type to use, the network elements required, and the access privileges for the users etc. are identified.
5. Detailed Model (Sub Contractor view): As we can understand at this level its is the deployment phase where the details are low level like database specifications constrained as per the physical models, network configuration, detailed user privileges and so forth produced.
6. Functioning system (User’s View) : Here the final implementation of the various systems is depicted and its impact to the users is mapped. Information like what data is being entered by users and getting stored in the database or the actual message flow happening over the deployed network and so forth is considered at this stage. The idea is to use this information for operations management, evaluation of the systems deployed etc.

I have spent some time reading about the weakness of this framework (for e.g. process/documentation heavy, little or no acceptance from development community), but I favor a business process centric approach. In my mind, all development activities should have a business value and justification. One way to clearly ensure that all stakeholders and departments understand the overall development program is through a visual display of the interactions of process, systems, data and business rules.

"Disclaimer: The views and opinions expressed here are my own only and in no way represent the views, positions or opinions - expressed or implied - of my employer (present and past) "
"Please post your comments - Swati Ranganathan"