Jaa

Zachman’s Fatal Flaw: No Row for the Customer

  • Artikkeli

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…

Comments

  • Anonymous
    July 09, 2010
    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.

  • Anonymous
    July 09, 2010
    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.

  • Anonymous
    July 09, 2010
    The comment has been removed

  • Anonymous
    July 12, 2010
    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

  • Anonymous
    July 12, 2010
    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.

  • Anonymous
    July 13, 2010
    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.

  • Anonymous
    July 14, 2010
    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.....

  • Anonymous
    July 14, 2010
    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.....

  • Anonymous
    July 14, 2010
    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  

  • Anonymous
    July 14, 2010
    The comment has been removed

  • Anonymous
    July 15, 2010
    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.

  • Anonymous
    July 17, 2010
    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.

  • Anonymous
    July 18, 2010
    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

  • Anonymous
    July 19, 2010
    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!

  • Anonymous
    August 16, 2010
    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.

  • Anonymous
    August 16, 2010
    The comment has been removed