What makes models interesting

Since 2009, when I first published my open source metamodel of enterprise architecture (the Enterprise Business Motivation Model), I’ve had numerous conversations with architects, business analysts, consultants, technologists, and the occasional student about models.  I frequently hear things like “I have an update to your model that makes it better,” to which I reply “cool, let’s see it.”

After seeing about a dozen now, I’ve begun to realize that I need to ask better questions.

Some models are simply more interesting than others.  Some have relationships that are more appropriate for specific situations.  (for example, one friend sent me his version of my model with specific elements related to government organizational structures and interrelationships).  That is very interesting, because I can see a value in capturing distinctions related to different types of organizations.  Another friend sent me an update to my model with greater focus on customer relationships, which is great if the goal is to highlight the importance of customer-first modeling.  Another person sent me an extension he did to Osterwalder’s model to include additional aspects needed to develop a business that is sustainable in the world environment.

Those are the good examples.  They add unique value.  They consider new things.

Some not-so-interesting examples often come from students or usually young architects (less then three years in field), who simply feel that one set of relationships is “better” than another, without any particular rationale other than “it looks better to me.”  Note: that’s fine.  It means the model represents their way of thinking, and their use of terminology.

But what do I say when they expect me to rewrite the EBMM to match their thinking processes?

I say “yes” in very narrow circumstances.

So for those folks who want to propose an alternative model or an update to the EBMM, let me lay out some basic concepts and guidelines.

Prove that the model extension answers questions that need to be answered

The first and foremost problem is a simple one: adding stuff just because we can.

The EBMM can certainly be “bigger” if that were my goal.  But it isn’t my goal.  My goal is to ask specific questions and produce a model that answers them.  The list of questions is far more interesting than the model itself. 

So before you send me a model, send me the list of questions you need to answer with that model.  THINK ABOUT IT.  Don’t create the model and then go hunting for questions that justify it.  These need to be legitimate questions that are of demonstrable concern or value to an enterprise-level stakeholder. 

The EBMM was designed to answer a specific set of questions.  Those questions are included in the model itself.  If you want to extend the EBMM, ask different questions.  Then, we can extend the model to answer them if necessary. 

“All models are wrong.  Some models are useful.” 

Many of us are already familiar with this quote, from George Box, noted British statistician and author.  While he was referring to statistical models, his advice is worth considering on a deeper level.  In his 1976 article, Science and Statistics, he provided a very useful bit of advice to the would-be creator of models. 

“Since all models are wrong the scientist cannot obtain a "correct" one by excessive elaboration. On the contrary following William of Occam he should seek an economical description of natural phenomena. Just as the ability to devise simple but evocative models is the signature of the great scientist so overelaboration and overparameterization is often the mark of mediocrity.” (Journal of the American Statistical Association, 1976, https://www.jstor.org/stable/2286841,   retrieved 26 Sept 2013)

George Box said that so much better than I would have.  While he was referring to science and statistics, his advice applies to Enterprise Architecture rather well. 

What it means is this: if you have two models, both that capture the USEFUL elements needed to describe something, and one is simpler than the other, go simple.  In other words, I don’t care what is “correct.”  I care what is useful. 

Be forewarned: you send me a model that is a more detailed elaboration of my own model, with more elements and more relationships but which does not capture USEFUL knowledge more clearly, or convey information in a more accurate manner, I will reject it.  Additional detail is not useful unless you can demonstrate value. 

In order to demonstrate value, you need to show me two sets of information: one captured in the existing model and one captured in your more elaborate model.  You then need to describe to me how that information, in context, is less useful the way I captured it, and more useful the way you captured it.   Then, I will add complexity to the EBMM.  Yes, it’s a high bar.  The EBMM is complex enough as it is.

On the other hand, if you send me a model and you can demonstrate that you can use fewer elements to capture knowledge or describe intent than I did, I will not only listen, I’ll probably take a swing at removing stuff from the EBMM.  That’s a much lower bar for you, and a high bar for me.  I need to prove to myself (and you, if you are willing to put up with me) that the complexity in the EBMM is justified.  I will make things as simple as possible, but no simpler.

Simplicity in practice

Many folks have asked me why the EBMM doesn’t have entities for “database” or “network node” (or name your IT entity-of-the-day).  “It’s not a complete Enterprise Architecture model”, is the usual cry.  I usually point out that they are not looking at the right viewpoint.  The primary viewpoint, which most people are aware of, doesn’t show every element.  On the other hand, the IT Traceability viewpoint (below) has all the technical elements that an enterprise architect needs to model the technology landscape at an architectural level. (click the image to enlarge).

Simplification one: the model is for Enterprise Architects, not IT management

But wait, they cry, where’s the entity for a database!  Where’s the SharePoint Server (or the active directory server or the service bus, yada yada yada). 

Challenge accepted.  In the metamodel view above, information is managed within the context of an application.  Prove to me that you need to illustrate the element that gives you heartburn in a different way than I have captured.  Consider two questions: (a) Can an existing element be used? or (b) Is that element relevant in an enterprise architecture setting?

I can consider SQL Server, BizTalk, SharePoint, SAP, Dynamics, and many other systems to be “platforms” to be used by applications.   I can consider a server to be a “host” but I can also consider entire environments (like a DMZ or even the Azure cloud) as a host.  

So, no, I don’t have elaborate details that go further “down the stack” to the point of illustrating network nodes, because I don’t need them.  IT management does need those details.  That’s what a Configuration Management Database (CMDB) is for.  The EA repository may overlap with the CMDB but these two critters are quite distinct.  (topic for another post).

Simplification two: the model minimizes transitive relationships

A transitive relationship is of the form

A relates to B, B relates to C, therefore A relates to C.

I want to see the relationships between A and B, and between B and C. 

However, if you send me a model, please be aware of your transitive relations.  Don’t ILLUSTRATE the relationship between A and C unless it is NOT easily derived.  For example, look at the diagram above.  We could say that a Business process demands a system interaction point.  A system interaction point is described in a use case or user story.  Therefore, the relation between a business process and a use case can be easily derived.  Note, however, there is no “relationship arrow” on the model.  It is transitive, so there is no need to add the relation.

Minimizing transitive relationships reduces the complexity of the model substantially.  Realize that this is a conceptual model.  Nearly all concepts can be described using transitive relations (and many are). Rather than have a model where “everything relates to everything,” this simple practice makes the model readable and usable. 

On the other hand, some transitive relationships should be captured.  These would be the relationships that are NOT easily derived because of their complexity or underlying meanings.  For example, in the diagram above, an application uses a platform, and a platform is deployed on a host. I also illustrate the transitive relation (application is deployed on host).  Why?  Because platforms are optional.  It is possible to create an application that is NOT on a platform.  However, the relationship to a host is not optional.  Since this detail is not easily derived from observing the model, I illustrated both relations. 

Important note: when I discuss business capabilities, I say things like “you should map people, process, tools and information” yet in the model, I only illustrate the connections between the capability and process, and capability and tools.  That’s because the relation between capability and people is transitive (through process).  The relation between capability and information is similarly transitive (also through process).  I follow my own rules.  

Conclusion

For those folks kind enough to offer feedback on the Enterprise Business Motivation Model, I want to say, first and foremost, thank you.  I listen to every opinion and I care about every detail.  It is a labor of love.  Each new insight offers me an opportunity to refine the model, and I may make changes simply because you taught me something.

That said, if you are focused on seeing a change to the model as a result of your research, I will expect you to be cognizant of the context and concepts expressed in this blog post.  I certainly will be.

Comments

• Anonymous
  October 01, 2013
  The one and only benefit of going completely to the bottom of "the stack" would be to provide a standard methodology for infrastructure folk to create an enduring body of knowledge (which is not the Visio network template). The real challenge however that an "Enterprise" model should address is to ensure that there is no schisms or jarring gaps between the different methodologies and frameworks in the ICT space.  It's not useful Architects presenting models to business leaders and CIOs that do not align with ITIL style Service Catalogues.  There's very little value that can be achieved when project managers ask for deliverables that don't map to standard artefacts decided on by Architecture groups.   Moreover it just makes us look foolish. The Open Group is starting the journey with adding the Motivation and Implementation to Archimate, but my gut feel is that the EBMM is actually closer to the goal as there is less to get in the way with the ITIL service design process. And that I think is the real test; can an EA use the EBMM to describe their enterprise in a way that does that does not interfere with, or require translation by service delivery staff.

• Anonymous
  October 01, 2013
  regarding transitive relationships, that's one of the many issues with modelling languages that don't have built-in mechanisms to maintain their semantics consistent. If you assert that A relates to B and B relates to C, and these relations are transitive, then the language have to infer that A relates to B. Similarly, if A is an instance of B and of C while B and C and disjoint, that that should simply be not possible. However, as linking boxes with arrows has little constraints and models are rarely tested rigorously, especially in EA. I can't give you an advice how to improve the content of your model because so far I had no opportunity to test it and although I'm tempted to enter into conceptual discussions - they often give pleasure - I respect your work enough to risk wasting your time. However, I'll repeat another advice I allowed myself to give you some years ago: try to describe the model using OWL-DL instead of UML and I'm sure you'll be surprised about the things you'll discover.

• Anonymous
  October 14, 2013
  Can Social Media create new ideas?  Here’s an example where the answer is “yes.”  I recently

• Anonymous
  October 14, 2013
  "Many folks have asked me why the EBMM doesn’t have entities for “database” or “network node” (or name your IT entity-of-the-day)." Huh? Don't they even bother to read the name of the model? Enterprise Business Motivation Model? If it's explicitly a business-layer model, and a business-motivation model at that, why on earth would anyone expect it to include entities for database or 'network node'? Yes, there is a need for models that cover the technology-landscape, and that - if possible - can also provide traceability back to the original business-drivers for that technology-landscape. But as you say - and I strongly agree in this - that's not the purpose of EBMM. And it shouldn't be, either: there's enough work to do just mapping abstract-;evel business-motivation, without throwing in the random monkey-wrench of detail-layer technology. I do share your frustration here: I really do despair sometimes at people's apparent inability to think - or even, it seems, to read... Sigh indeed...