In concluding my previous post, Modeling with Stickmen, I declared that if UML is neither intended for nor effective in communicating a high-level understanding of a system then something else will be needed. Achieving this high-level understanding and its being shared across a broad range of stakeholders is absolutely essential to success in any endeavour of a meaningful size. The question becomes whether there is a strategy that can be deployed and what, in terms of notation and methodology, does this look like.

Over the years, and amid too many projects to be recalled without shuddering, I had never encountered something that looked like it could fill this gap - at least to my satisfaction. That was until a couple of years ago when I came upon the Object Process Methodology (OPM). The key reference resources are:

• Object Process Methodology. The reference book by Prof. Dov Dori.
• ISO Standard OPM ISO 19450:2015.
• The Wikipedia entry on the Object Process Methodology offers a good overview.

My encounter with OPM was facilitated by attending systems engineering course at MIT. This course was delivered by Professor Dov Dori, the driving force behind OPM, and by Professor Edward Crawley, Head of the Cambridge MIT Institute and advocate for how OPM can be leveraged to model business as well as system considerations. The course, I should note, represents the best value I have ever encountered in a single professional education program. I would highly recommend it to anyone who is interested in the general question of modeling complex systems in a way that all stakeholders can intuitively understand.

I will attempt an unforgivably brief description of OPM here. The Object Process Methodology offers an astoundingly simple framework for modeling systems and scenarios of unlimited complexity. The root of its ability to do so lies in the fact that it departs from the prevailing fixation with Object Orientation (OO) which, in ultimately trying to represent the world using constructs relevant to software, inevitably spawns bewildering models as soon as it moves beyond anything more "real" than a software component. The main departure that OPM makes, as its name suggests, is the elevation of "processes" to being peers to "objects". In the real world, there are things and there are things that happen to things and this basic decomposition of conceptual units fits reality to a tee. So it is that whereas the full envelope of UML diagrams provides over 150 individual symbols, OPM manages to get by with literally a handful. This simplicity then makes a second major departure possible - the elimination of the litany of diagram types. In OPM, there is only one diagram type and only one integrated view. This is one major reason why business people can immediately grasp the contents of an OPM model.

Equally interesting is the fact that associated with any visual representation that can be constructed using the OPM notation will be a supporting "natural language" expression. The above image illustrates a very simple OPM model. The image is taken from the OPCAT modeling tool and along the bottom of the screen shot can be seen both the limited set of symbols used and a segment of the natural language expression associated with the model.

Among the activities routinely undertaken by Professor Dori and his team is the demonstration, usually through real-world projects, that the OPM can be used to model things with equal precision as might be achieved using UML and SysML and that the resulting OPM models stand as almost comically simple and understandable by comparison. Some of these efforts consciously endeavour to address challenges of increasingly minute sophistication. Continuing down this route leads inevitably to the question of whether OPM is, or should be, a competitor to UML.

The simple answer to this question is "No". And this stands regardless whether or not this proposition has any merit. That is beside the point. UML is an industry and, even if the issues evident with UML are serious, it is not going anywhere. Those inclined to cynicism might be quick to suggest that elegance and efficiency (that OPM so explicitly pursues) may not be things the UML community is interested in.

But the Object Process Methodology (OPM) has a great deal to offer as a modeling notation and methodology for business systems and in this area it can provide the perfect adjunct to UML. The OPCAT tool even makes it effortless to export models using the XMI specification so that the results of the early system analysis effort can be imported into UML-based design and development environments. In playing this role, the symbology of OPM could, ironically, be simplified further and I would be inclined to use a subset that retained the core set of conceptual building blocks and left the tweaking to a later, and probably UML-equipped, phase.

The short summary of this argument is that anyone interested in the general problem of understanding complex systems, and representing and communicating that understanding to a broad community of stakeholders, absolutely must take a closer look at the Object Process Methodology.