The Beginning of the End for Enterprise Architecture Frameworks
Little did we know here at ZapThink when we published our ZapFlash on The Crisis Points of the ZapThink 2020 Vision just two weeks ago that one crisis point would manifest itself mere days after the article hit inboxes. The Crisis Point in question is the Enterprise Architecture (EA) framework’s fall from grace. The precipitating event that heralds this fall is a $10 million lawsuit that John Zachman has filed against his long-term colleague, Stan Locke, which according to Stan Locke, essentially dissolves their multi-year relationship and forcing Stan into retirement.
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?
Effective Enterprise Architecture: Beyond Ontologies and Methodologies
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.