1. Diagram-driven code didn't pan out as well as advocates hoped (and to the extent it was useful, UML wasn’t a great language for it; BPMN was less bad at this.)
2. Modeling and analysis became devalued, adversely impacting modeling languages
3. OMG also ended up as the owner of BPMN (which was also affected by the first two factors) which has enormous overlap in function with UML. So, with a reduced role for visual modeling languages you've got two competing standards in the area from the same organization, neither one of which is really adapted to current usage patterns.
It's not been my observation that the overlap is that big, having done lots of BPM work using BPMN in a former life. BPMN is for describing much higher level processes than what UML is for.
> BPMN is for describing much higher level processes than what UML is for.
BPMNs process-oriented focus is often viewed as both more general (tech neutral) and more suitable for high-level use than UMLs OO focus, and there are more low-level implementation diagrams in UML (e.
g., Class diagrams) and more high-level context diagrams in BPMN (e.g., Conversation) but there is still significant overlap. BPMN Choreography diagrams serve exactly the role of UML sequence diagrams. UML Activity diagrams and BPMN Orchestration diagrams cover very similar space.
We're using it via an executable process engine at my current company on a project that's not yet in production, so I'm still on the fence. I have no idea if anyone from the "business" side will ever look at these diagrams, and if it's just the developers looking at them, then why not look directly at the code with the support of a modern IDE?
It works well for business processes, e.g. here's one I did: capture credit application; do auto check for credit worthiness; do rules check for amount requested vs credit worthiness to trigger auto approve, auto reject or manual approval gate; submit save approved loan details to mainframe for money issuance.
The tools I used generated a system using storage-backed messaging between every step for reliability, and then I could plug in a UI or an integration where needed, and generating monitoring screens to illustrate where in the process things are, cycle times, etc etc.
If you use it like that, as a config language you can use to drive creation of other things, it can work well, and it's a pretty mature standard, so it can describe lots of possibilities.
1. Diagram-driven code didn't pan out as well as advocates hoped (and to the extent it was useful, UML wasn’t a great language for it; BPMN was less bad at this.)
2. Modeling and analysis became devalued, adversely impacting modeling languages
3. OMG also ended up as the owner of BPMN (which was also affected by the first two factors) which has enormous overlap in function with UML. So, with a reduced role for visual modeling languages you've got two competing standards in the area from the same organization, neither one of which is really adapted to current usage patterns.