John Zachman, of course, is the creator of the Zachman Framework*, and is broadly recognized as the father of Enterprise Architecture. He’s been on the speaking and consulting circuit now for several decades, pushing his eponymous framework and working with partners to certify architects. We’re not sure of the details, and ZapThink’s role is not to report on such events in any case, but the facts of the matter, claims, and counter-claims are available on the Web for anyone who’s curious.

From ZapThink’s perspective, however, the question is less about the disagreement between Zachman and Locke or the Zachman trademark or even Zachman’s succession plan. The real question has to do with the value of the Zachman Framework now, and in the future. And given that other popular EA frameworks, including TOGAF and DoDAF, descend from the Zachman Framework, this upheaval in the Zachman camp suggests further upheaval in other quarters, what ZapThink calls a Crisis Point.

The Pros and Cons of Zachman

ZapThink has referred to the Zachman Framework in our Licensed ZapThink Architect SOA & Cloud Boot Camp for several years now, as it’s a useful way of organizing concepts that are relevant to the enterprise. While this ontology, or organization of concepts, does serve an important role, we also point out that it has limitations as well. Fundamentally, the Zachman Framework is an ontology rather than a methodology. That is, it helps you organize concepts without telling you what to do with those concepts.

The focus on defining terms and organizing concepts to the exclusion of actually taking actions that will solve business problems is at the core of the Frameworks Crisis Point. Too many architects find themselves immersed in such framework-related tasks, including creating models, developing standards, and communicating various concepts to other people in the organization. Eventually, CIOs will come to realize that the money they are spending on EA could be better spent elsewhere.

Zachman’s entire approach to EA reinforces the unfortunate belief that ontologies are central to the practice of EA. They are important, to be sure, but they are nothing more than a starting point. If we spend a year discussing EA we might spend the first day defining our terms, and the rest of the year figuring out how best to actually do EA. From our perspective, too many EA frameworks are focused on the first day.

The Framework itself has taken on a kind of cult status in the world of IT. Architects still worship at the altar of EA frameworks as though the masters of the frameworks have a special kind of wisdom that only they are able to impart. In reality, however, the entire framework approach to EA is largely obsolete, and too many EA framework masters are unwilling to change with the times.

In fact, the sorts of changes Zachman is willing to make to the Framework are indicative of this lack of progress in the approach. He recently hired a team of linguists to improve the Framework. These experts in language and communication recommended the removal of all adjectives from the Framework. Now, instead of “logical system model” there is a “system logic” row, and instead of “physical system model” the row below now has the label “technology physics.” Sure, perhaps the terms “logical” and “physical” were confusing, but so is the phrase “technology physics.” So, let’s get all the architects together and have a lovely argument over which is better, “physical technology model” or “technology physics” – while meanwhile, our enterprise continues to struggle with cost overruns, regulatory compliance challenges, and marketplace pressures. Arguing about terminology is just so much easier!

Methodologies to the Rescue?

If ontologies don’t give us effective Enterprise Architectures, then maybe we need a methodology as well. TOGAF, in fact, fleshes out a detailed methodology they call the Architecture Development Method (ADM), but the ADM is little more than a methodology for creating an Enterprise Architecture – in other words, an ontology. The end result of following the ADM is still an organization of concepts, rather than an approach for architecting an organization that will actually help the organization solve its problems.

Perhaps the missing piece to today’s EA is an effective methodology, a recipe of sorts that lays out everything an enterprise must do in order to achieve its goals. Methodologies, after all, have provided a good measure of value in the software development world, where formal methodologies like IBM’s Rational Unified Process (RUP) or Agile methodologies like Extreme Programming or Scrum have helped software development organizations of various sizes lower the risks inherent in creating software. Should we create such a methodology for EA? Would such a methodology even be possible to create?

Clearly, the notion of a methodology as a recipe, even a hyperlinked, customizable recipe like RUP, for example, is overly simplistic for describing how a large organization should better meet its goals. Even if you were able to write down such a recipe, step-by-step instructions for everyone in your entire enterprise to follow, and even if you were able to convince everyone to follow those instructions – both implausibly Herculean tasks in and of themselves – you would still have the problem of change.

Long before everybody had the chance to learn and follow their parts in this gigantic play you’ve written for them, the needs of the organization will have changed. Change, after all, is constant and never-ending, so no recipe will ever be suitable, since you always need to know what you want to make before following a recipe. Imagine following a recipe for a chocolate cake only to learn halfway through the process that you want a blueberry pie instead. How would you write a recipe to accommodate such a change, without it simply being a recipe for disaster?

The ZapThink 2020 Poster illustrates how to address the Frameworks fall from Grace Crisis Point (sponsorships for the ZapThink 2020 Poster are still available). We place this Crisis Point squarely in the Complex Systems Engineering Supertrend, because the only approach that makes sense is to treat the enterprise as a complex system. ZapThink has written about complex systems before, so we won’t go into the background here. Instead, let’s rework the changing recipe example into a complex system example.

Let’s say that instead of a chocolate cake, you want to build an oak tree. The recipe for oak trees are in the DNA in acorns, so you plant an acorn. But this recipe is quite different from the cake recipe; the DNA doesn’t specify ingredients or steps for assembling the tree. Instead, the DNA provides general rules for how to create the trunk, roots, branches, and leaves, and also gives the tree a way to deal with forces in its environment, like how to deal with too little water, or how to maximize the sunshine hitting its leaves. But there are no “branch goes here” or “leaf goes there” instructions that would characterize the DNA instructions as a methodology.

The challenge for the Enterprise Architect, by analogy, is in helping to create a set of rules or policies that encourage desirable behavior for the enterprise while discouraging undesirable behavior. The architect must then place these policies into a framework that coordinates them across the organization. If this approach sounds like governance, you’re right. But governance alone doesn’t address the broader problem of how to architect an enterprise for change.

We can find the answer to this question in our DNA example as well. Nobody sat down and deliberately coded the pattern of amino acids in the oak tree’s chromosomes; rather, millions of years of natural selection did that. The enterprise architect must take a page out of nature’s playbook and establish a governance framework essentially based on the principle of natural selection: of all the rules and policies that an organization might enact, keep the ones that move the organization toward its goals and retire the ones that don’t. Over time, the inherently dynamic governance framework will be optimally suited to support the strategic goals of the organization.

The ZapThink Take

Hopefully this ZapFlash leaves you wanting more, as we’ve only scratched the surface of how we envision Enterprise Architecture formalizing the approach for architecting the complex systems of people and technology that constitute the modern enterprise. What we have done, however, is pointed out that many EA frameworks are emperors with no clothes.

Of course, ZapThink offers an alternative. Our Licensed ZapThink Architect program also offers a certification, but not an EA framework certification that may have decreasing value given the Sturm und Drang happening in the industry today. We don’t dwell on ontologies or methodologies that fail to address how to be effective at what you do. Instead, we approach the role of the architect with a focus on practical, effective techniques for helping your organization be successful in the face of ongoing change. We hope to see you in an upcoming course soon!

* Zachman and The Zachman Framework are registered trademarks of John Zachman and Zachman International.

Great post.
I would add that we are not only missing effective methodologies but also methodologies grounded in deep knowledge/theories. A lot of work has been done around socio-technical systems as well as other frameworks which could ground an EA methodology in science/fact.

Today, it is fare from clear what is grounding EA frameworks/methodologies.

I can understand your doom and gloom, but that is only because you have not looked at PEAF.

Of course, I am not saying its a silver bullet (which of course is one of the risks associated with EA that needs to be mitigated) but more and more people are beginning to see that it does provide real value in a pragmatic way.

Have a good detailed look at it, couch the opinions of others and see if your doom and gloom is lightned a little.

In my 12+ years of doing EA work, no one could ever demonstrate to me how to use the Zachman framework for anything but posterware. In the early days, it was Meta Group that really turned EA into actionable ideas and practices. But the race of technology has blurred any and all boundaries, to the point where frameworks are more ilustrative than being useful to organize a program around. A conceptual framework cannot be used as a filing folder plan for the functional technical parts anymore, since they move around regardless of concept boundaries.

And be very careful about using the evolution of species as a guideline for adaptation. There are millions of extinct species in the fossil record and very few, if any, transitional forms. The ideas of natural selection and evolution do not show us how to adapt! Adapting to local conditions with incremental changes in no way guarantees your survival. To survive in a complex system that is changing rapidly, you need to determine how the rules are changing. Without that understanding, you have no idea how to improve your organization's fitness.

Just because of the Zachman crisis, there is zero reason to attack TOGAF. I have deep knowledge of TOGAF (and other frameworks as well) and know that thousands of people around the world are planning on getting TOGAF training over the next year around the world.

This is because many organizations and individuals are seeing value in TOGAF as an organizing methodology, not just for the concepts/terms. They also are seeing it as the most accessible and meaningful EA framework around, largely because it is being evolved by hundreds of people from organizations worldwide in different industries/sectors. While this also has drawbacks (having so many involved), the TOGAF body of knowledge is not being fought over by two individuals, such as in the Zachman law suit.

Anyway, I do not agree with your assessment of TOGAF at all. It is far better than anything else openly available for a foundation for doing EA. In addition, most people who get training find they benefit in terms of moving forward with more confidence.

Implying everyone should run from all EA frameworks because of the inadequacy of the Zachman approach, is really not reasonable, esp. given that TOGAF now has market share in terms of EA frameworks and interest is expanding globally at a rapid rate.

Having taken the ZapThink certification course, I would even suggest that it could benefit greatly from linkage to TOGAF, given that TOGAF is meant to be tailored to different styles and contexts and other EA approaches.

Overall, I have found a lot of folks commenting on TOGAF without having thoroughly learned what is in the TOGAF 9 spec/book. I strongly encourage all architects (enterprise, business, SOA, data, applications, and technology/infrastructure/network) and project managers be grounded in TOGAF and join the global community building a foundational and free framework usable for all sectors and all sizes of organizations. The TOGAF spec. can be downloaded free from http://www.opengroup.org.