I’m always a little leery of a stack diagram that shows ‘systems’ living at some level of the stack.  For example, a diagram that shows a series of different application user interfaces at the U/I layer, and then workflow services somewhere further down the stack. 

What makes me leery is the fiction of the diagram.  Yes, workflow services are called by the business layer of an application, and we want to make it clear where that integration lies.  But a workflow system has a user interface, middleware, and database.  It is an application in its own right, and if we were looking at a diagram of the workflow system, we’d see components living at every level of the stack.

Therefore, while the Integration to a workflow system may live at a particular level of the stack, the workflow system  itself is not at that level of the diagram.   

I guess I’m just a little cautious of these diagrams.  I’m supposed to be communicating to developers and other folks.  How well am I communicating if it isn’t clear that the service interface is simply an integration end point?

SQL Server has the same issues yet I don’t mind that one.  Not sure why.  Perhaps I’m just not used to seeing systems that don’t provide an entire layer. 

Your opinion?

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

2 thoughts on “Be careful of the 'stack' diagram”
  1. I think stack diagrams can be useful for VERY high level communication where you are just getting a ROUGH idea for the LARGE components/systems/boundaries of a system.  

    You certainly would architecture/design/code a system just based off of stack diagrams, in fact, I am not even sure if the audience is purely on the technical side, but more in selling the idea to stakeholders.

  2. I see your point, Patrick.  I guess the problem I have is one of consistency.  What do I succeed in communicating if I create a diagram that is not valid from a technical viewpoint?  Even if I am just sharing with the business (especially).  

    Just because other architects have used stack diagrams, if they have no technical validity, why use them?  

Leave a Reply

Your email address will not be published. Required fields are marked *

11 − 10 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.