2 days ago 19 624
Dr Alexander Samarin wrote: The lack of the “bigger” architecture, which should enable together the following features: • BPMN should use a standard execution semantic which can be validated and which guarantees the adequate interpretation of models by different software for different uses, e.g. for functional testing, performance simulation and execution. • It should be possible to represent the same business process model with different levels of detail, e.g. a high-level view for a normal user, and a more detailed view for a business analyst. • There should be a modelling procedure which guides different stakeholders how to use these different levels of detail. • Details of the execution of business processes should come from a coherent set of standards, similar to that provided by the W3C for HTML: a) xHTML for structure and content, b) CSS for presentation, c) DOM-based API for dynamic modifications, and d) some other specialized standards. Thanks, ASSome quick comments here, since I think these points are pretty typical of what is thought. BPMN is a process modeling language, so criticizing it for not being an architectural modeling language is both unfair and inaccurate. BPMN modeling can be done within an architectural modeling context, but it requires methodology and convention to be done (or at least done well). Thus, this "challenge for BPMN" is just as much a "challenge for architecture" as anything else. BPMN does have a standard execution semantic. It just happens to be complex, and the spec itself contains areas of ambiguities and inconsistencies that do beg for clarification in an updated version. The idea of a reference model to validate interpretations would be great, but politically it is infeasible. The closest thing to that is what we at the OMG Model Interchange Working Group (MIWG) use to test interchange between tools whose vendors are willing to submit for testing. Multiple modeling levels/views are already possible with BPMN. The two conformance classes (Descriptive and Analytic) can be used to support such different views. And methodologies and conventions exist for creating those different views, but they are add-ons to BPMN. What is admittedly missing is a means by which different levels can be tied to the same business process in some formal way. I'm working on something like that now, but it is ultimately (IMO) going to be a mix of methodology and convention with some meta-model constraints tossed in. But this was not a BPMN problem, but a model management problem, so it was not in the standard. BPMN must prevail in the marketplace, just as the standards cited above had to do. It is the dominant process modeling language, but adoption is probably not yet at the stage cited above. So the challenge is in making adoption easier, I think, and not so much in the standards setting.
Stuart Chandler wrote: First, there is still a fundamental challenge of organizations adopting the notation and building it into their vernacular...Business Architect and Business Analysts are still integral to the adoption so the real success is when the business is able to either adopt the nomenclature and 'speak' or BPMN evolves. This somewhat leads me to challenge two, that notion that technology needs to evolve for more business hands on. We see numerous tools that are attempting to capture and articulate the business easier via BPMN ...are trying to eliminate the need for BPMN by enabling organizations to build right into the tool using drag/drop, screen flows to capture business process (putting aside under the cover rule activity)....Adoption is the problem. Flexibility and complexity are the reasons, IMO. The spec was a consensus, and the collective desire was to support different modeling styles with a formalized language for them all. And the spec is complex as a result of this flexibility. These have, unfortunately, given rise to bad modeling practices and bad models out there that outnumber the good ones by a factor of at lease 100-to-1. I do agree that once we can easily show how this relates to the Business Architecture, we should be able to get better traction with it. Some of the pure modeling tools (as opposed to process design-based IDEs for BPMSs) that I track are actively working on making the tooling interface more intuitive, reducing the need to know BPMN semantics, and on relating the models to a broader architecture. The EA modeling tools out there approach BPMN as just another construct, and (IMO) rarely get the BPMN treatment right. With the process modeling vendors now engaged, we may see more movement to a integrative and coherent use of BPMN in creating models. Hope springs eternal!