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?
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.
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?