While we might all agree there are great benefits to modeling processes, decisions, goals, or data, there are major disagreements on modeling methods, standards, and the object that 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, like 'there is only data' or 'there are only rules'.

Model the Logical or Physical

A common argument often revolves over modeling the target logical model instead of the physical implementation model as the former 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 who 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 whether processes embed decisions or if decisions are on top since they determine the tasks to perform.  I think you need both for very complex processes and decisioning.  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 since 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 get more attention than it does.  Just sayin'.

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 like it needs major adjustment.  This is unlikely as fluid processes/cases are usually known up front and approaches can be selected to support them.

# # #