Jeffrey A. Solochek
 http://www.nosugarcoating.info

On the other hand BPEL, is a complex language which tries to replace the common use of scripting languages like perl or python for quickly weaving together an application out of independent web services.

The comparison between UML and BPMN is more interesting, UML is really an extensible modeling language, in theory, BPMN can be modeled as a UML extension. BPMN on the otherhand is a solution for the very specific problem of visually modeling complex processes using a surprisingly simple notation. In some sense, BPMN can be to UML what HTML is to SGML.

Thanks for the article.

These types of discussions are useful. I have a couple of comments.

BPMN was not strictly a front-end for BPML/BPEL. We specifically decided not to create an execution language notation. BPMN was intended to be a generic way to define and communicate process models. At the same time, enough detail was included (but not required) so that it could be mapped to BPEL. Thus, we did not have a pure IT approach. The approach was two-pronged to bridge the traceability gap between process modeling and process execution. But business POV was considered key to the success of BPMN. Just reading the spec, however, might lead one to see the IT side of it as being dominant.

This leads to why we did not just use (and perhaps extend) UML Activity diagrams. UML, whether deserved or not, was not acceptable in business process modeling communities. It didn’t matter what the capabilities or underlying constructs of UML were — whether it was UML 1.4 or 2.0. BPMN based on UML would not have been accepted and would have failed.

I do agree that BPMN and UML should be harmonized, especially now that BPMN is in the OMG. But this harmonization should be done carefully. It should be done to enhance the capabilities of UML, thereby reducing the business/IT gap. But it should not damage the reputation or acceptability of BPMN in the business community. Thus, it is hard to say when or how a harmonization of BPMN and UML will occur.

On a more picayune note, the term activity is used generically in BPMN. Both processes and tasks are activities. Thus, in your model, a BPMN process maps to an activity. Beyond that, I’ll note that no matter what terms we could have chosen for any element of BPMN, we would have confused or offended one or more community of users.

I think modelling may not be that good a practice for software. I guess we need to develop software that is more self-adjusting as the needs of the customer evolve. For example a customer may track only the phone number for a client today, but tomorrow the customer needs to track the mobile number as well. Such changes should be trivial to implement.

Another reason for the failure of modelling is the time it takes to convert from models to code is too long, and it is not a one to one conversion. Until that comes, I guess modelling will be more academic than practical. That is why even UML is given at the end of the project as an artifact of the project.

Thank you for your response.

I have used System Architect and agree with your comment about CASE tools. IEF and ADW were superb, and I can only blame CA for burying them. My background is Industrial Engineering & Operational Research, as well as Systems/Management Consulting. I find that many CASE tools have been perfectly adequate for business and systems analysis.

I don’t believe that IE’s shortcomings with respect to Object Modelling are in any way serious. IE can cope with any complexity of inheritance. That is all that is needed at the business modelling level. I’d be interested to know what specific shortcomings people believe that IE has at the level of business modellling! I am not religiously tied to any methodology either — but I do find it tiresome when supposedly new methodologies merely rebrand or make claims that are rather trivial/unnecessary (e.g. Use Cases and the like). Maintaining continuity is much more valuable than shamming revolution.

This does not detract from my wholehearted appreciation of BPM.

Regards

-Wilf

To a certain extent, I agree with you. I am very familiar with all the CASE tools and Methodology (Navigator) that you mentioned. In addition, I’ve also used Excelerator (the first DOS based CASE tool that supports Structured Analysis and Structured Design) and System Architect for Enterprise Architecture Engineering. Unfortunately, most of these CASE tools are no longer in existence, with the exception of System Architect, now part of Telelogic’s product offerings. System Architect is the standard CASE tool for DoD’s (Department of Defense) DoDAF.

It is interesting to know that someone still practices Information Engineering for almost 20 years. Throughout my 25 years in Management Consulting, I have mentored Application Architects, Data Architects, and Technical Architects in many of my consulting assignments using various methodologies and CASE tools. Personally, I have no preference for any particular methodology or CASE tool. Each one always misses something! In architecting complex systems, process and system simulation becomes an essential tool, which System Architect also supports, but not as sophisticated as the tools used in OR (Operations Research). By the way, IE doesn’t support Object Modelling, which is the de facto paradigm for current Software Engineering practices.

-Francis

I object to you branding IE as being data oriented. It was, and is a complete powerful methodology, incorporating the following techniques:

- Entity Relationship Modelling
- Function/Process Decomposition
- Business Event Modelling
- Entity Life History Modeling
- Process Dependency Modelling
- Process Views
- Process Logic
- and more…

It is impossible to be just data or process oriented and do a sensible, thorough job of business analysis. You may be familiar with IEF (CASE tool), IEM, and with ADW (CASE tool) and Navigator (from Ernst & Young), which covered all these techniques in an integrated way.

I am enthusiastic about BPMN, but once again, it is nothing new. It is identical to Process Dependency Modelling, but with the capability to formally depict all those things (conditionality, multiplicity, exclusivity, multifarious event types, etc.) that we could do only through manual representations previously. Also, BPMN has relevance for design and development capability — but as a Business Analyst I have no specific interest in this.

Regards

-Wilf

Thanks for the compliment. Both of you and your thesis supervisor are correct given the current states of UML and BPMN. Let me explain. At the time when BPMN was conceived, UML modeling elements were primarily for showing ’static’ associations or relationships between components and classes. Only ’sequence’ and ‘activity’ diagrams support temporal and dynamic aspects of components and classes at a rudimentary level. It is virtually impossible to map two incompatible model (i.e. sequence and activity) elements to BPEL. Thus BPMN was born.

Currently, there is a disconnect between UML and BPMN as they belong to two different Domain Task Forces within OMG. Personally, I prefer to roll BPMN into UML under one Domain Task Force. The benefit of doing so is that UML will be the only modeling language that supports Requirements Engineering, Systems Engineering, Knowledge Engineering, Software Engineering, Hardware Engineering and other Engineering disciplines for better enterprise management in terms of agility and innovation of processes, products, and services.

I hope that the above answers your question fully. If you have further questions, please feel free to let me know.

During one meeting with my supervisors for my master’s thesis, we discussed the real added value of BPMN over UML. I argued that it is obviously useful to use BPMN over UML because we can generate BPEL code from it, and perhaps do some round-trip engineering. The point of view of one of my supervisors was that we can do most of that stuff with UML as well. I’m not an expert in the field of BPMN (still learning), but I think he has a point. Why didn’t we extend the current UML language to fit in the SOA story for instance? Most of the people in the software industry are already familiar iwth UML, so… ? What is your point of view on this matter? What are the strong arguments why a new language was invented instead of extending UML?

Thanks for the correction.

It looks like business users will have to deal with a plethora of incompatible models. This also means that the Activity diagram in UML will compete with BPMN. The question is why does the IT industry create so many incompatible gadgets in independent silos? I would suggest that the architectural board of OMG launch a program to consolidate all similar activities and a chief architect be appointed to oversee all architectural efforts in all Domain Task Groups. This is to ensure and enforce that all DTG activities will be in harmony with one another, without contradictions and duplications.

It won’t be long before business users get frustrated, revolt, and find the simplest and cheapest solutions. That is, outsource all back-end computing and data processing activities, like in the 50’s and 60’s, to time-sharing bureaus! With virtualization and grid computing, IBM and EDS will be glad to comply!

You wrote: “Now that the work on BPMN has been folded into the UML working group at the OMG, it is hoped that UML will evolve into a more robust and simplified modeling language.”

The premise is incorrect. BPMN has not been folded into the UML working group at OMG. Both tasks forces operate independently. Neither graphical language is designed to replace the other.

Your assumption is correct, BPMN was originally developed for BPML.