John Zachman’s Framework for Information Systems Architecture, later renamed as the Zachman framework for Enterprise Architecture, is a commonly used taxonomy of business elements and artifacts used by Enterprise Architecture teams. It is clearly in rapid decline as the TOGAF framework, derived from TAFIM, is being widely adopted as the Enterprise Architecture framework of choice.
Unfortunately, many of the concepts of Enterprise Architecture were established by adopters of the Zachman Framework. This is a shame, because the Zachman Framework is fatally flawed.
What is the fatal flaw? As you can tell from the title of the post, the flaw is an “Inside-Out” perspective on the enterprise. The flaw is the description of an enterprise from the viewpoints expressed in the rows of the framework itself, variously described as the Planner, Owner, Designer, Builder, Programmer, and User viewpoints. All of these viewpoints express the enterprise in terms of how these different roles understand it… but not in the way in which an enterprise is actually relevant.
A business that does not provide value to a customer is doomed. Therefore, it is critical to develop models of the enterprise that reflect the viewpoint and perspective that is of critical importance. Unfortunately, while the Zachman Framework is large, it has a fatal gap: it demands many things but fails to demand the creation or classification of business elements from the perspective of the end customer.
One could say that the customer viewpoint is represented not by a row, but rather by a column: the “why” or motivation column. That is nonsense. We need to answer each of the interrogatives of Enterprise Architecture (What, How, Where, Who, When, and Why) from the perspective of the customer. The customer must be a row. It is not.
Now, time to retrain all those folks who are bringing Zachman “thinking” with them…
Fair points… agree with them all. However, I believe the conclusion is a bit dramatic. As you know no framework is ever always and totally perfect. They require thinking trained capabale human actors. With this element included the Zachman framework is functional and not as you say fatally flawed.
Fair points… agree with them all. However, I believe the conclusion is a bit dramatic. As you know no framework is ever always and totally perfect. They require thinking trained capabale human actors. With this element included the Zachman framework is functional and not as you say fatally flawed.
Hi Tim,
The followers of the Zachman framework will not allow any change to the list of rows or columns. That is a founding principle and one in which the professionals who use the ZF have been remarkably consistent with. Even derivative frameworks fail in the same spectacular way!
You can say that "adding the customer row would make the ZF functional," and perhaps you'd be right, but what is the goal here? Is it sufficient to be "functional?" I'd rather focus first on being effective. Could you be effective with a version of the ZF where the ONLY row is customer? Interesting thought. Maybe, maybe not.
But to simply state that we will add the row, when the followers of ZF would never allow it, and where 50% or more of the value of the framework is represented by that single missing row, is difficult for me to accept as a valid answer.
Analogy: we send a soldier to battle. On his back, we have included a weapon that weighs 50 pounds. It takes fifteen minutes (in the heat of battle) to set up. It is missing a firing mechanism and we have not sent along any ammunition. Do we fix the situation by adding the missing parts? Or perhaps we give him an altogether different weapon, one that weighs 10 pounds, works well with less than 2 minutes of set-up time, and helps him to complete his mission safely.
Which will it be?
Nick, good post and it got me thinking that perhaps the real issue is that we have matured past what Zachman was originally thinking of. I wrote a blog post in response … leodesousa.ca/…/is-it-really-zachmans-fatal-flaw
Hope you are doing well and having a great summer, Leo
Nick, there may be a 'fatal flaw' but I don't think it is an attribute of the framework itself. More likely there is a gap between how the Zachman framework is used and the purpose for which it was designed.
Clive Finklestien's "Enterprise Architecture for Integration" shows how well the Zachman framework works well to organise the abstractions involved in progressing from business strategy to a functioning system.
The end product of all that activity is executable code.
The concerns of EA are now wider than systems architecture. But Zachamn and TOGAF in particular are conceptual tools designed by and for software engineers.
It is unremarkable that the perspective is from the inside looking out. (I would say TOGAF is very much an inside to out perspective as well)
The question is whether these frameworks accrue unnecessary complexity through a process of accretion – of additional concepts, additional methods, additional uses – with each addition being a compensation that bridges the gap between the original focus of the framework and what the next enthusiastic adopter would like to do with it.
To my mind EA frameworks are starting to resemble the overly complicated and bloated systems we use them to analyse and remedy. They becomes maps whose complexity starts to match that of the terrain.
I think the Zachman framework is well designed and effective within a specific scope. It defines a 'translation matrix' providing solution architects a means of formally reducing abstract and strategic objectives to the functions of the physical systems they are responsible for.
Zachman can be used effectively as it is. Just not for everything. The 'fatal flaw' may be the impulse to overload. Just another variant on the "man with a hammer" truism.
Hi Ric,
I'm going to disagree. The fact that an abstraction CAN be used to travel a constructed path from strategy to system code, that does not mean that the road so traveled is an effective road. In fact, when you view things in the crystal light of hindsight, there are a wild array of abstractions that appear sensible. However, most are useless in actual practice because they only make sense in hindsight… that the moment you want to use them as a mechanism for foresight, the abstractions fail to be effective. In some cases, they are downright misleading.
This is the case with ZF. It is good for documenting "what is" but useless for documenting "what should be," primarily because of the missing focus on customer as well as any other external influences. None of Porter's five forces can be modeled in ZF. None of the influencers (internal or external) evident in the OMG Business Motivation Model can be modeled in Zachman. That is because these forces, and influencers, are not tangible in the current state model of an enterprise. They are useful if you want to understand the future… where an enterprise SHOULD go, but not necessary when understanding the present… where an enterprise IS.
Your case that ZF is appropriate in some cases is fascinating.
Zachman, himself, is adamant that his framework is not just for IT, but rather is a mechanism to capture the complete blueprint of a business. End to end… total scope. He maintains that is what it is designed for.
The fact that you feel that using ZF beyond a systems focus is inappropriate tells me that you disagree with John Zachman about the value and applicability of his framework. I'm having a hard time reconciling your statement (ZF is useful for IT only) with the clear intent of the progenitor of that framework, his philosophy, and his teaching (ZF is useful well beyond IT). It sounds like you are saying "it is only good for what it was designed for," when in fact, you mean "it is good for LESS than it was designed for."
In that way, I believe we fundamentally agree.
Unfortunately, EA needs a framework good for understanding the future. ZF cannot get us there.
I am amazed that such absolute garbage is presented in such a confident fashion. The customer while being the reason why an enterprise exists does not provide a view. The customer does not know what the enterprise should look like. The customer only knows and cares about the product being delivered. Hence the enterprise is engineered by various key stakeholders to provide what the customer wants at different levels.
In addtion – Zachman and TOGAF do not compete. They compliment one another.Zachman says what Enterprise Archtiecture IS and TOGAF shows you how to implement it…..
Hi Nick,
thank you, yes, that's a good point. I guess I do believe that the Zachman framework is good for "less than it was designed for" But more importantly I think the Zachman framework is good for even less that it is used for. And I would double down on that with TOGAF.
Of course, (and I am confident you will agree), the ZF is a tool not holy writ. Our task is application, not exegesis.
I suspect we agree on the weakness, but where you argue to extend (strengthen) the framework to support a greater scope of application, I would reduce the scope itself and look to use the framework only for the activities it can support well.
A framework for understanding the future? That question is really very interesting…..
Hi Ric,
You and I are on the same page about the limitations of both Zachman and TOGAF. The reason I have some hope for TOGAF is that the most recent version is starting, just barely, to approach the real concerns of EA, while at the same time, bringing along a focus on methods and practices. In that way, it is more promising than ZF which staked out an incomplete and inaccurate future, and then failed to provide the methods and practices needed to bring it about.
I am hopeful for TOGAF, because of the adoption curve and the growth curve, not because I believe it is there yet.
— Nick
Hi Dean,
I'm sorry that you dislike my statements, although I'm glad you feel that I'm expressing my opinion with confidence. 🙂
I found your words telling… "the customer … does not provide a view." Love the word "provide". That tells me that you are viewing the ZF as a model where the rows are "provided" by key stakeholders. E.g. The builder view is "provided" by builders. Interesting, because that is precisely what I am talking about in my prior comments… that ZF is good for documenting the existing structure (by asking the stakeholders to provide, and document, their viewpoint).
However, it is not a framework useful for predicting the future, or to guide the Enterprise Architect to find the optimum next steps for business to take, because it is useless for describing what the stakeholders cannot "provide:" the future.
It is true that the stakeholders are accountable for engineering the enterprise to provide for the needs of the customer. Have you noticed how important it is that all of those stakeholders have a shared understanding of what those needs are? Have you noticed how powerful that shared vision is? If you want to know the value of a shared vision, look at the re-emergence of Apple.
So where are all of the components of that shared vision in ZF? They are there, but only from an "inside out" view… only a document describing what the enterprise thinks it should be, but not a document describing what the customer needs the enterprise to be… and therefore there is no conflict. Without being able to illustrate the conflict between what is, and what should be, the ZF is incapable of providing insight into what must change.
And hence, it's fatal flaw for EA. EA must provide insight into the future, not just document the past.
Sure, TOGAF and ZF are complimentary, because ZF is complimentary with ANY description of the current state. However, ZF does not describe the "what" that you need to reach. It describes what you think you need to reach. It has no row to place evidence to the contrary.
No conflict. No enlightenment.
I do not believe TOGAF is done. The most recent release has begun the road to developing the future state. ZF never began that road. TOGAF is being widely adopted. ZF is dying.
Quod Erat Demonstrandum
— Nick
I always thought of the Planner row as being the Planning in terms of the view of the Customer. And it can provide insight into the future, but the future is almost a whole set of rows and such as by adjusting a future state, all rows of Zachman should be considered. Zachman is not confined to being just a 'current' state framework.
I take your points, Nick, though I have to say that I think you're perhaps missing the point.
Zachman was never designed as a 'proper' enterprise-architecture framework: it was initially about information-systems only, and later expanded to support a notion of 'engineering the enterprise'. To my mind, both of those are useful ways of assessing a _subset_ of the enterprise, but nothing more than that: I would never attempt to use Zachman to describe the _whole_ of the enterprise, and anyone who does so is frankly asking for trouble.
(The same applies to TOGAF, by the way: it's somewhat improved from where it was, but it will never be usable for enterprise-architecture – as opposed to detail-level IT-architecture – until they drop the fixed 'Business/Data/Applications/Technology' scope and rewrite to support a generic context-selectable scope.)
In your terms, I'm probably even worse than Zachman: in my usage of a Zachman-like frame I _explicitly_ and _deliberately_ remove all reference to 'Who' – for the simple reason that _people are not assets_. (The organisations relationships with people _are_ assets, though – and that point _is_ explicitly included in the framework that I sue.)
Overall, the 'fatal flaw' isn't in Zachman itself, but in the way that people (mis)use it. I would suggest that that latter misuse would be a more useful theme to tackle here, rather than worrying too much about Zachman itself.
Hi Tom,
Fair statements all. I cannot disagree with anything you said.
I see limitations in the combination of the ZF and the people who use it. The combination is toxic. We appear to agree on that point.
Three options:
a) Change the framework to address the gaps
b) Change the language that people use when using ZF
c) Change the methods and practices that people use when using ZF
You appear to be leaning toward option (b). I chose option (a). Both of us are calling for change… we are now simply discussing WHICH change is more appropriate. Hence I have nothing to argue with you about. Each change is better than remaining the same.
The reality is that ZF is flawed.
I have no problem with your decision to remove "who" from the methods that you use. I do not believe that the customer is a reflection of "who". It is much closer to "why" (as other respondants have pointed out. The problem is that the interrogatives apply very general slices through very specific structures, creating collections of elements that do not reflect the actual conceptual relationships needed to model an enterprise.
EA needed the ZF approach in the beginning, because practitioners were failing to include all these considerations (columns) in their models. But in the modern era of complete metamodels, that reminder should recede to "advice" on the practice of EA, and should no longer be considered a useful "framework" for anything at all.
In the effort to guide people away from the structures of the past, I have no problem with "shaking people up" a little, going after option (a). In the future state, ZF fades to "interesting advice" and real metamodeling becomes the norm. In the mean time, addressing the gaps is a start.
Remaining still is not an option.
With respect,
— Nick
Agreed. My complaint with the Zachman Framework is that it is designed for static systems and not dynamic systems that have feedback loops. Its roots come from a manufacturing mindset where you design/implement/deploy the "system" (enterprise, organiztion, solution, service, etc.) and it says relatively the same. In this new era, the customer is changing the "system" while it is running in some cases against the "rules" or "governance." Your point about the customer is spot on, can you imagine a passenger on an airplane changing the plan while it is flying? That is now the world of EA, whether we like it or not. The customer can now fundementally change the system by trying new things that the "system" designer (enterprise architect) was never able to envision. Holistic thinking in this new era forces us to examine how the system is consumed (used) by customers over time and how it will evolve based on observing outcomes. Our new frameworks must be adaptable and must have all consituencies of the "system" represented: business, designer, acquirer, planner, operator, and customer!
Nick
I'm afraid I have to disagree with you and this isn't a flaw.
The Zachman framework doesn't need a customer view for the same reason as a business doesn't need a customer on its board. We assume that the collective board members (in the roles of strategists and executive leaders) are capable of developing goals, objectives and strategy for their business by taking into account the concerns of all stakeholders, particularly that of the customer (otherwise they don't stand a chance!). Through the top two levels levels they are concerned with the context of the business in relation to the outside world and can't possibly do that without engaging with customers. It doesn't require a separate row for customers however, their concerns are captured there and can then trickle down through every row.
Much of this mis-interpretation comes from (I believe) a techie* view of Zachman's framework and EA as a whole rather than realising that the Business Architecture Domain (top two rows) is not just the context of the Solutions/Data/Infrastructure architecture domains but are the drivers of them. Experience suggests to me that often the top two rows have lip service paid to them and the context is lost so those architects feel an absence of that 'customer view'.
* no offence intended, not accusing you of being a techie… unless you're happy with that – I am at heart.
Hi Julian,
>>We assume that the … board members … are capable of developing goals, objectives and strategy for their business by taking into account the concerns of all stakeholders, particularly that of the customer <<
While I believe that EA is cool, I don't think that EA replaces the role that senior leadership plays in creating strategy. We agree on the above assumption.
>>their concerns are captured there and can then trickle down through every row<<
Don't you find it interesting that John Zachman chose the rows and has remained inflexible by announcing that those choices are "complete?" Don't you find it interesting that the needs of each of those perspectives are Explicit, but as you point out the needs of the Customer are implicit? This is a very inside-out viewpoint.
One way in which EA is effective is to help business leaders make good choices about their investments. We can help do so by building consensus towards a single vision of the future, and that single vision may already have some executives lined up, but others are not. Building consensus is tough, and you frequently have to express the desired outcome from the viewpoint of the person you are trying to convince, referring to the things that he or she values.
In business, these points of shared value are priceless. For EA, they are essential for fulfilling the role of helping to build a shared vision of the future.
Where do they sit? Where do the models live that indicate how a customer will use the products and services of the business, or where the competition will be defeated, or where the external stakeholder's needs will be met? All of those elements refer to the External stakeholder. Yet, as critically important as these models are for bringing about the FUTURE, there is no place in ZF to place them.
I would insist that the problem of techies not seeing ZF for what it is, is somewhat reversed. You see, ZF was designed to allow techies to operate within the machinery of an enterprise… to understand it… and to do a better job of "taking orders" from the business. The customers viewpoint exists for IT, because IT's customers are business leaders. Therefore, if you live within IT, ZF is fine, because it DOES include the customers of IT. However, if you live within the business, ZF is not useful because it does not include customers of the business.
The fact that this is not obvious to you may mean that your use of ZF is focused on helping IT navigate the business. As an EA, I need more. I need the customer. Since ZF is incapable of meeting my needs as-is, I feel the need to extend it. However, if the people who are critical to making that extension work do not believe that it can or should be extended, then perhaps my choice is not correct. Perhaps we should not extend ZF. Perhaps we should abandon it.
— Nick