Saturday 3 September 2011

Zachman Framework, New and Improved


Last week John Zachman released v3.0 of his Zachman Framework (ZF).  More on that shortly, but it certainly closes out an eventful year for John.
Last summer, John Zachman created some waves by suing his long-time Canadian colleague Stan Locke for $10 million.  Stan initially said he would close up shop and retire, not wanting to challenge the lawsuit.  At the time, there was some musings in the industry about the future of the framework, and especially the value of the certifications Zachman had been issuing.
Now that a year has passed, I can’t find any statements from either party as to what has transpired.  From my reading of the California court records, it appears Stan did in fact fight the lawsuit and had it dismissed on jurisdictional grounds.  John and Stan’s names appear side by side again on the Zachman International website, and over the past few weeks John and Stan have been teaching ZF courses again in Toronto, although they appear to be teaching separately.  It would seem that they kissed and made up to some extent, and life goes on in the ZF world like nothing ever happened.  And if that’s the case, good for them.
Almost a decade ago, I took a course on the Zachman Framework taught by both of these gentlemen.  The ZF has developed a bit of a cult following in the enterprise architecture world, but in my travels I have yet to work in an organization that is deriving any real benefit from it.  That doesn’t mean such organizations don’t exist – but it probably means there can’t be too many of them!
What Is The Zachman Framework?
The Zachman Framework is a grid that organizes different types of modeling artefacts, and is helpful in terms of clarifying how those different models relate together within an organization.  John Zachman created the grid while working for IBM in the 1980’s.  Across the top, he put the 5 W’s (and 1 H):  What, How, Where, Who, When, and Why.  Down the left side, he placed five levels or perspectives within the organization:  Planner, Owner, Designer, Builder, and Sub-contractor.  The premise is that a sub-contractor working on the minutiae of a system will require different models than a high-level planner would.  For instance, a low-level detailed model of “who” might be a user list for a particular computer system, while a high-level view of “who” might be a management organization chart or a list of competitors.  Both are valid models of “who” but they fit into different slots on the grid.
There have been a few versions of the framework, including last week’s brand new version 3.0.  All of the original cells of the framework are still there, but additional descriptions have been added around the edges and some names have been revised.  For instance, the What column originally contained Data artefacts, which limited the perspective to what data architects typically worked with.  Now it contains Inventory artefacts, which is a different perspective on an organization’s answer to the What question, but it’s equally limited.  The original Builder row is now called the Engineer Perspective (which I like), but the models the Engineer makes are now called Technology Physics.  I have no idea what a Technology Physics model is!  It sounds like what my university physics professors built in the machine shop when they wanted to measure cosmic rays or microgravity.
Given the structure of the model can never really change (unless you create a new question word to make it 6 W’s), all that John can do is describe more clearly what’s already there.  I’d say version 3.0 only brings partial progress towards that goal.  There is still a need for a version 4.0 someday, and Technology Physics should definitely not be in it!
Strengths and Weaknesses
So what is the Zachman Framework good for in an organization?  I’ve found it helpful to see how the various types of models in an organization fit together, and which models haven’t been built yet.  It is a simple structure so it’s easy to remember, unlike Scott Ambler’s modified version of ZF which is far more thorough but also far more difficult to understand.
After taking Zachman’s course, I immediately realized it wasn’t going to help my organization with the challenges we were facing.  Developing more models, or slotting the models we already had into the grid would not change how our organization functioned.  While it gives the data architects and modellers a false sense of progress in filling up the pigeon holes with models, it doesn’t affect the troops on the front lines.
Ultimately, the Zachman Framework is just another Dewey Decimal System.  As Melvil Dewey helped organize information in libraries, Zachman helped organize models in an organization.  Dewey organized all the knowledge contained in books, but it did not specify any methods for transmitting that knowledge to people.  That required education methodologies, and Dewey’s system wasn’t a methodology.  Neither is Zachman’s.  As he now puts at the top of his v3.0 diagram, it’s “The Enterprise Ontology™“.  An ontology is a structure for organizing concepts, not a methodology for improving an organization.
In order for models to change an organization, they need to be operationalized.  The easiest way to do that (but not the only way) is to embed the model in a computerized process.  For instance, if you have a policy to control spending by getting everyone’s immediate superior to approve each office equipment purchase, you can implement an organization chart (a “Who” model in ZF) into a purchasing system so that whenever an employee enters a request for new furniture, it looks up their name in the org chart and automatically sends the request to their immediate boss for approval.  An implementation of such a model might eliminate some unnecessary spending, but having the organization chart alone will not save the company anything.
Zachman often repeats this platitude in his courses and articles:
“Someday, you are going to wish you had all those models made explicit, Enterprise-wide, horizontally and vertically integrated at excruciating level of detail.”1 
The only problem with that assertion is that the “someday” never comes.  I’ve been in departments and organizations that have gone through some major crises, and no one has ever said, “If only we had all those models!”  A lack of explicit models can sometimes cause challenges, but the cost of building and maintaining all these models “at excruciating level of detail” across the organization is simply not justified.
The Zachman Framework is a helpful structure for organizing models, but not for transforming organizations.




John A. Zachman, “Enterprise Architecture Artifacts Vs Application Development Artifacts”, © 2000 Zachman International, downloaded from http://www.hl7.org/documentcenter/public/wg/secure/Zachman%20Enterprise%20Artifacts.rtf

No comments:

Post a Comment