An Agile Approach to the Zachman Framework

The Zachman Framework (ZF), www.zifa.com, was first proposed more than a decade ago, but is just now gaining popularity in the IT community; in particular, among IT architects. It defines a collection of perspectives pertinent to software architecture and typically follows a traditional, prescriptive approach; however, it is possible -- and advantageous -- to apply the framework an agile manner.

The ZF is depicted as a spreadsheet (an example can be found at www.agiledata.org/essays/enterpriseArchitecture.html#ZachmanFramework) in which the rows represent the views of different types of stakeholders and the columns represent different aspects or views of your architectural modeling efforts.

The framework's rows include the following stakeholder views:

1. The planner's "Objective/Scope" identifies your organization's direction and purpose, setting the boundaries of your enterprise architecture efforts.
2. The business owner's "Enterprise Model" defines, in business terms, the nature of your company, including its structure, processes and organization.
3. The architect's "Model of Fundamental Concepts" defines the enterprise in more rigorous terms than the business owner (see "Enterprise Model" above), ensuring the model grows in detail. This row was called "Information System Designer's View" in the first version of the framework.
4. The designer's "Technology Model" determines how the technology will be applied to address the needs defined by the architect, business owner and planner.
5. The builder's "Detailed Representation" sets the detailed design, taking implementation language, database storage and middleware considerations into account.
6. The "Functioning System" row represents the actual systems within your organization.

The columns of the ZF comprise the following architectural modeling views:

1. The Structure (What) column focuses on your organization's significant entities, object or components, and their interrelationships. This column was called "Data" in the original version.
2. The Activities (How) column focuses on what your organization does to support itself and its customers. This column was originally called "Function."
3. The Locations (Where) column focuses on the geographical distribution of your organization's activities. This column was first named "Network."
4. The People (Who) column focuses on who is involved in your organization's business.
5. The Time (When) column focuses on the effects that time, such as planning and events, has on your organization.
6. The Motivation (Why) column focuses on the translation of business goals, strategies and constraints into specific implementations.

The ZF is based on a threefold structure. First, the models are evolved to greater levels of detail as you move down a column (and summarized as you move up a column). Second, the models in a single row should be consistent with each other, with one caveat: If you're following an agile instantiation of ZF, the models may not be perfectly consistent, as agile models aren't as detailed by design. Third, the ZF doesn't define an architecture process; instead, it defines the various perspectives that an architecture should encompass. You'll need to define your own process around the ZF -- hopefully, an agile one.

Strengths
The Zachman Framework explicitly reveals the many views that an architecture must address, and can serve to remind you of those issues, whether or not you decide to adopt it.

Also, since one model doesn't fit all -- as AM's Multiple Models principle reminds us -- a single level of detail isn't sufficient, either. For example, in the first column, you could use several styles of data models (conceptual, logical, physical) or several styles of class models for various levels because your audience changes in each row.

The ZF's holistic view is another great strength: Its wide focus reaches beyond architects and developers, demanding that you involve all the stakeholders in your architecture's development to ensure that it meets their needs.

The Tricky Part
Is ZF agile? It depends on how you implement it. The framework can lead to an over-complicated modeling effort in which you write more documentation than you really need. For example, you could easily apply the principles and practices of AM to the Zachman Framework to make it agile, or you could use the framework to justify a complex and documentation-heavy modeling process that requires a large enterprise architecture group to administer and control.

A strategy for applying the ZF technique in an agile manner is to:

1. Keep it simple.
2. Adopt the concept that your enterprise architecture efforts must reflect a wide range of perspectives.
3. Adopt the augmented form of the ZF to avoid methodology bias.
4. Avoid documentation-heavy, bureaucratic processes centered around the ZF -- remember, your goal is to develop working software, not to create lots of fancy models and documentation.

Recently on the Agile Modeling Mailing List:

The Model-Driven Architecture (MDA)
The Object Management Group (OMG)'s Model-Driven Architecture separates a system's functionality from its implementation on a specific technology platform. This modeling approach promises that a single model specifying system functionality could be realized on multiple platforms through auxiliary mapping standards, or through point mappings to specific platforms. MDA also supports explicitly relating different application models, therefore enabling integration and interoperability and supporting system evolution as platform technologies come and go. Although MDA is theoretically sound, I'm simply not convinced that it will succeed in the mainstream development community. A few MDA supporters didn't see things this way, but the final consensus was that time will tell. Look for a future column on this topic.

Agile Business Modeling
A conversation started when one poster wasn't sure how business modeling fit into the overall AM picture. There seems to be a misconception in the community that AM principles and practices apply only to technically oriented artifacts such as UML sequence diagrams or physical data models. This isn't the case: You can and should apply AM to all aspects of modeling, including situations in which stakeholders are highly involved. An argument was made for the importance of finding modeling techniques and tools that are inclusive for your stakeholders. These techniques (such as low-fidelity UI prototypes and user stories) do exist, as do stakeholder-friendly tools, such as flip-chart paper and index cards -- you need only to choose to use them.

Test-First Modeling
A very interesting conversation evolved regarding how a test-first approach to modeling can be combined with AM techniques. Test-first modeling is similar conceptually to test-first programming, in which you write your testing code before your business code. The basic idea behind test-first modeling is that a test should be defined before you add a new element to your model.

Hot Links:

The Agile Alliance Home Page is the best starting point for anyone interested in learning more about agile software development:
www.agilealliance.org

My essay, "Agile Analysis," reveals how you can take an agile approach to analysis and explores the concept of an agile business analyst in greater detail:
www.agilemodeling.com/essays/agileAnalysis.htm

My article, "Agile Enterprise Architecture," describes how to take an agile approach to your enterprise architecture, arguing for a more people-based approach, and suggests ways that you can apply the Zachman Framework in an agile manner:
www.agiledata.org/essays/enterpriseArchitecture.html

Sign up for the Agile Modeling Mailing List and get involved with the AM methodology:
www.agilemodeling.com/feedback.htm

For Agile Modeling training resources, go to
www.agilemodeling.com/training.htm

David C. Hay, in his book, Requirements Analysis: From Business Views to Architecture (Prentice Hall, 2002), reveals how to take a data-driven approach to implementing the Zachman Framework. For more information, go to www.amazon.com/exec/obidos/ASIN/0130282286/ambysoftinc

Jason Gorman's "Test First Modeling" describes a modeling-oriented approach to testing:
http://www.objectmonkey.com/dev/index.php?Action=get_resource&Arguments=artid=105

Terry Moriarty's article, "To Unify Architecture with Methodology: The Rational Unified Process Meets the Zachman Information Systems Architecture" (Intelligent Enterprise, Apr. 16, 2001), does exactly what the title says -- it shows how to use the ZF on a RUP project:
www.intelligententerprise.com/010416/metaprise1_2.shtml

For more information on the Zachman Framework, visit the Zachman Institute for Framework Advancement online at www.zifa.com