Gregor-grams and Chappell-grams

I've been doing a lot of work with an Enterprise Services Bus (ESB), and found Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions a very useful book - especially the diagram techniques "Gregor-grams".

These are useful for diagramming any message based system - I'm very keen on UML but it does not really address MOM systems in the large. Below is a Gregor-gram showing how a Sales Order Process might integrate SFdC, Zuora (Z-Billing) and Oracle Financials (a pattern that most businesses will need):

This diagram allows us to show how message move through the system and are transformed. There's also another good book is Chappell's Enterprise Service Bus which is focused on the ESB implementation of MOM (no surprise given the name!).

It has another diagramming techique, which at the moment I'm using for creating a static view of the ESB:

This is closer to a static UML view (deployment maybe), but it also allows you to express how the components connecting to an ESB exchange messages (HTTP/WCF etc). I feel that Gregor-grams are better for the dynamic view. The book never names these diagrams, so 've taken to calling them "Chappell-grams" given that they are meant to be an evolution of Gregor-grams.

Using Gregor-grams and Chappell-grams together allows us to document how a system works from both a dynamic and static view.

7 ± 2 rule of diagrams

Reading "The Elements of UML(TM) 2.0 Style" by Scott W. Ambler I came across the 7 ± 2 rule of diagrams:

"16. Reorganize Large Diagrams into Several Smaller Ones

It is often better to have several diagrams showing various degrees of detail than one complex diagram that shows everything. A good rule of thumb is that a diagram shouldn’t have more than nine symbols on it, based on the 7 ± 2 rule (Miller 1957), because there is a limit on the amount of information that someone can deal with at once. “Wallpaper” diagrams, particularly enterprise data models or enterprise object models, may look interesting but they’re too information-dense to be effective. When you are reorganizing a large diagram into several smaller ones, you may choose to introduce a high-level UML package diagram (Chapter 6)."

which is based on The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information by George A. Miller in 1956

Scott's book is full of useful tips, and some nice links like this one!