Modeling as communication

Another meeting going adrift. You’re checking your watch and counting the participants. What a waste of good company time. The organizer started with a well-structured agenda, but the team is getting nowhere. Basic terms are unclear. Misunderstandings abound. People seem to agree but disagree at the same time. They’re talking and talking, but getting nothing accomplished. So, how can we make the meeting productive? Here’s a nearly surefire method: create a visual model of the subject at hand.

In my couple of years as an enterprise architect, I learned one skill that has changed the way I work and think: modeling. Enterprise, business and solution architects structure the relationships between an enterprise’s capabilities, processes, systems, data, infrastructure etc. in visual models using boxes, lines and arrows. The models serve to bring all key architectural elements together, ensuring the inclusion of all necessary elements and an understanding of their interactions. They help us think rigorously about structuring the enterprise. So, how might that help the meeting lost at sea? I’ll get to that shortly.

What is a model?

A model is a representation of some real (or future) thing or phenomenon etc. It captures those elements and relationships of the thing that are important to the modelers. The modelers use the model to design, explore and examine their subject, to test hypotheses, to understand causal and logical interactions or to plan. The model is necessarily a reduction. Hence George Box’s oft-cited dictum “all models are wrong, but some are useful”. Models are by definition incomplete, because completeness would make them identical to reality. The reduction has a key virtue: it allows the modeler to focus.

There are many ways to model. Architects, children and middle-aged (usually) men build physical models of buildings, houses, cars, train landscapes etc. Mathematicians and scientists use equations and diagrams. Designers and engineers plot and calculate in CAD systems. Enterprise architects and process analysts draw boxes, lines and arrows. And, there are surely more model types and uses. All types of models can be used in an organizational context, but I focus here on visual models with boxes, lines and arrows, as they are most broadly relevant for enterprises.

Thus, a model functions to structure important elements and their relationships. In particular the boxes, lines and arrows represent the phenomenon visually. The resulting image has the crucial feature of showing everything at once. By contrast, language flows linearly, and thus a description of some phenomenon can only be absorbed over time. With a visual representation, the eye and brain wander over the subject matter. Furthermore, it reduces the connections between the elements to the essential aspect of interest. For example, we may show that Team A performs a Process 1 using Data hosted in System D to support Service Y.  

Simple model of a team using a process to fulfill a service (EDGY)/1/

Even without the relationship labels, the arrows and the line convey the meaning sufficiently. The model contains only what is of direct interest. Team A may have other relationships to the process, such as “earns part of bonus by doing”, but since that is not our main focus, we don’t model it. (We could, of course, draw a second relationship to show it if we wanted to).

Modeling is communication

Returning to the meeting that has gone adrift. Now that I have become addicted to the modeling habit, whenever I find myself in such a meeting, I will often go to a whiteboard or start sharing my screen and start sketching a model of what we are discussing. A fascinating thing happens. No one objects, even if my interjection breaks the flow a bit. Everyone starts to contribute. It’s a bit like when the “dog whisperer” Cesar Millan walks into a pack of misbehaved dogs./2/ Chaos melts into serenity. Even for controversial subjects, the tone is constructive, as people engage in getting the model right.

I believe two things are happening here. Communication becomes structured, and it becomes co-creation.

Structuring communications

The model serves to structure the communication. It is helpful (but not required) if someone in the room knows a modeling language such as EDGY, Archimate, UML, BPMN etc. That way, we start with an established metamodel created by people who have already thought long and hard about how enterprises work. Virtually all enterprises need the same core set of elements. Furthermore, these elements have a limited set of (useful) relationships. In the end, these languages are just applied common sense, but it saves us the trouble of having to reinvent the wheel.

But, even without an known metamodel, the visualization of the elements in boxes connected by lines and arrows fixes them in a spacial structure. It focuses the group’s attention on the essential relationships. As something gets mentioned, we map it into the model. Superfluous parts of the discussion are silently omitted. As the model grows, everyone can see, propose and deliberate about the items’ links to each other.

Thus, we don’t just talk about and perhaps list Team A’s responsibilities, but we link them, for example, to the processes that they serve. The processes are in turn linked to capabilities that the company must be able to perform and to the products or services that we create. Graphic. Done properly, we differentiate the objects, thus melting the misunderstandings. Maybe Team A is in reality two sub-teams, who work quite autonomously and should represented separately. Maybe we discover that key assets are lacking.

Co-creation

The session becomes an act of co-creation. Since everyone sees the model as it develops, everyone is implicitly encouraged to contribute. If most in the room are silent, then the moderator should urge them to join in. All voices are heard, and they are channelled toward the production of the model. Participants can test and even challenge each other’s suggestions within a safe context. And, the moderator should ensure that the meeting remains a safe space.

A good model also has a level of causal and logical rigor (often provided by the modeling language). In my experience, many misunderstandings arise from mixing categories or object types. One person is talking about the service, the other about the process. Thus, the “billing” team who is responsible for the “billing” process may identify itself with the workflow, even if several other teams also contribute to the process. By ensuring that the process is represented separately from the teams involved and linked by a “performs” relationship, we can have a much clearer and fruitful discussion about how to optimize the process.

Co-creation creates collective ownership and responsibility for the model. Since we’re modeling for the purpose of building and changing the enterprise, the co-ownership vitally supports the real development of the company. If the billing team itself worked on optimizing the billing process (perhaps by giving up some tasks to other, better-suited teams), they will not only accept the change, but even lobby for it.

Where is modeling relevant?

Modeling is certainly relevant for any kind of design or development: products and services, enterprises, computer applications etc. Constructing experiments, improving processes, planning a project may all profit from a visual diagram of the subject. I can imagine it also as an effective sales tool, for helping the customer understand the product’s role in helping her get something done. 

A sales pitch showing how the product supports the tasks a customer needs to apply on her journey to improving her service effectiveness (EDGY)/3/

When police plot the suspects, witnesses, other evidence on a pinboard, they are visually modeling the relationships to better understand the crime. Mindmaps are models of texts./4/ I could even imagine lawyers modeling the arguments in a case. Modeling won’t help much in meetings centered on getting the daily work done, where the focus is on coordinating tasks, refining scheduling etc. Nevertheless, I believe that they can and are being widely applied.

How to model?

So, how do we model? It’s important above all that it’s about creating models, not pictures. It’s about structuring, not just documenting. And, finally, it’s about co-creating and communicating logical and workable structures. So, we need to take care that we’re thinking clearly, broadly and deeply about the subject. A few tips:

• Use clear, disjunct object types. For example, processes, assets, capabilities, services, etc. should each be represented differently in shape and/or color
• Arrows and lines show the relationships, which are the verbs that link the elements. It may be helpful to label the arrows, so that the verb is explicit. With other relationships it might be helpful to show the cardinalities.
• Keep the detail level consistent with the need. It may be necessary to create several views with different levels of detail. Nevertheless, avoid showing elements that are not directly relevant.
• Let the modeling language do the work. I recommend using an established language that has defined what the symbols mean and which relations are allowed. BPMN for processes. EDGY or Archimate (TOGAF) for enterprise design. Even simple flow charts follow well-known conventions.
• Keep the focus on the model and how it helps with your design or planning challenges. The method helps us think straight, but it’s not the end in itself.
• Use whiteboards or pinboards for the group session, but document the result with the help of a modeling tool. Visio, Draw.io or Powerpoint are sufficient for single visualizations. Archi (tool) is a great, open source tool for modeling with Archimate.

My experience with modeling in groups has been thoroughly positive. I would be keen to hear what kinds of situations where a visualization of the topic has helped the discussion.

Notes

/1/ This diagram uses the EDGY language from the Intersection Group, (see, https://www.enterprise.design). Another great resource for EDGY is Eero Hosiaisluoma’s website: https://hosiaisluoma.fi/design/. EDGY is my preferred modeling language, as it better fits my current role and covers all elements of enterprise design.

Archimate from TOGAF is highly useful for enterprise architecture. It is limited to what EDGY calls the architecture facet, but it has the virtue of being more specific, if more detailed, in its object types (see, https://www.opengroup.org/archimate-forum/archimate-overview). Archimate has also been nicely implemented in the Archi software application (see https://www.archimatetool.com)

EDGY and Archimate are also mutually compatible.

/2/ https://www.cesarmillan.com

/3/ The EDGY “experience” facet links customer tasks to experience and journey as well as the product and the brand. 

/4/ Mindmaps are great for modelings texts, but are otherwise quite limited as models. They usually arrange objects hierarchically in a circular form around the main subject. The hierarchy does model relationships, but usually restricted to the verb “belongs to” or “is part of”. Some readers might object that mindmaps can show connection between disparate elements. Agreed. I personally have rarely encountered a mindmap that has more than hierarchies. And, I have never seen one where other kinds of relationships are explicitly mentioned. Instead, a mindmap usually reduces to an outline of a text. Thus, it models the text that could be written from it.