Today I was able to complete a thorough power-read of the book Real Life BPMN by Jakob Freund and Bernd Rücker.
I’ve performed discovery on, analyzed, characterized, automated, modeled, simulated, documented, controlled, and improved various kinds of customer processes more or less for my entire career. I’ve specified, designed, written, implemented, installed, tested, documented, tested, verified, validated, and commissioned software for a wide variety of languages, tools, environments, operating systems, and applications during that time as well. I’ve thought about how it all works from a very low to a very high level and how it has evolved over time from its earliest origins to current developments. With that background in mind, particularly after having devoted some thought to the details of discreet-event simulations last week, I found the book to be both fascinating and well-structured.
It is easy to think that if you can analyze one type of flow or network or logic problem you can analyze a wide variety of them. Not so. I’ve learned over time that it’s generally a good idea to begin at the beginning when looking at something different that you’ve done before. Other kinds of experience make excellent analogues but without proper grounding they can lead you into serious misunderstandings. I had the background to understand the implications of what is described in the book as I read it but I leaned that I did not actually know what it was about going in.
The authors, who apparently also developed the BPMN standard up through version 2.0, build an explanation of what it does from its simplest elements to the most complex, and then describe the implications of each feature and what it represents to the business analyst/process modeler, the process managers, participants, and engineers, and the process improvements and automations that are supposedly to follow. They do this in a very clear and understandable order and any questions that occurred to me as I read were answered at some point in the text.
The main difference between the types of business systems the BPMN is meant to describe and the analysis, modeling, and even business process reengineering I had done previously is that business processes often have multiple logical parts that have to be tracked, split, and rejoined over time in combinations of entirely rational but potentially dizzying complexity. I’ve worked with some complicated software, systems, and processes, and they’ve sometimes involved checking against multiple conditions with varying delays and methods of synchronization but the picture they built up gave me a clear understanding of the challenges specific to this discipline.
The big issue is that the analysis of the business process itself, as described by the notation, is intended to live at a particular level of abstraction that doesn’t directly related to the software in which the described system is meant to be implemented. It is meant, instead, to logically represent a (wait for it…) business process in terms of business operations. There is a particular reason for that, I think, as demonstrated by the creation of the standard after other modeling languages, techniques, and implementation systems had been in use for some time and found wanting, and the standard’s subsequent evolutions through several iterations, each one incorporating improvements identified through application in the field.
The book is organized into seven chapters as follows:
- Introduction: Brief context in terms of vendor, application, audience, and relationships.
- The notation in detail: How to use the actual symbols.
- Strategic process models: How to use a very streamlined subset of the standard to diagram the top-level framework. It shortcuts the formal syntax in favor of clarity for a broad audience including participants and senior managers.
- Operational process models: How to use the notation to describe business processes in detail.
- Technical process flows and process automation: How and why the various software systems don’t match the models described by the notation and how to deal with that.
- Introducing BPMN on a broad base: Adopting BPM processes as an organization.
- Tips to get started: Getting up to speed as a practitioner. Very short.