Modeling Wars: 5 Areas of Friction

While we might all agree there are great benefits to modeling processes, decisions, goals, or data, there are major disagreements on modeling methods, including method standards and which object is the most important to model. Let’s examine the areas of friction in and around modeling.

I’ve identified five areas of friction, but I imagine there are more issues that are lurking below the surface.

Model the Logical or Physical:

A common argument often revolves over modeling the target logical model instead of the physical implementation model, as it represents the pure need and would include things like operational manuals skipped by the implementer. The implementation folks usually argue that the logical model is eventually not reality and synchronizing both is an impossible task.

Some organizations use the logical model as a specification and throw the logical away as soon as the physical model emerges. Those who believe in rapid innovation say create the implementation quickly and fail fast. I prefer to do a rough logical model that includes operations manuals and iterate to completion.

Model to the Standards or Not:

Many folks believe in modeling standards and say that standard modeling makes training, communicating, and attracting instant contributors from outside the organization easier. There is also a benefit from moving models around from one vendor to another without nasty conversions when switching to another platform already inside the organization or even a new one.

There are those that say the standards are difficult to work with and miss key nuances that make a difference. Why use clunky standards when they just slow things down? I prefer ease of development over standards, but I get tempted to iterate rather than model to perfection.

Model Cases Over Processes:

There is a brewing argument that the Case Management Modeling Notation (CMMN) is very close to Business Process Management Notation (BPMN) and could be easily extended to support cases. If BPMN would include goal modeling, I would agree because cases work to milestone goals and flow can take a back seat.

Model Decisions Over Processes:

There is also a growing debate weather processes embed decisions or if decisions are on top as they determine the tasks to perform. I think you need both for very complex processes and decision. They should work together, but Decision Modeling Notation (DMN) is the new kid on the block and doesn’t get the respect it deserves.

Model Goals Over Processes:

The real odd man out is goal modeling, as processes and decisions used to be pretty rigid and unchanging. As both decisions and rules become more fluid, goal modeling makes more sense. The goals remain and the goal target could change, but the path of decisions and process tasks can vary greatly. Goal and constraint modeling should receive more attention than it does.

Net; Net:

Modeling is great, but it is full of religious wars. Whatever models you embrace, decide at the front of the project and stick to your selection unless it looks to need major adjustment. This is unlikely as fluid processes/cases are usually known up front and approaches can be selected to support them

This blog originally appeared on jimsinur.blogspot.com.