Multi-faceted BPM: Turning a business process model into software automation

Turning a business process model into the specification, design and implementation of a software solution for process enactment is a non trivial task. It might be considered as not so relevant by business analysts (that typically focus more on BPR and BP optimization), but I think it’s a crucial issue anyway.
Indeed, the specified processes can be a mix of new functionality to be developed and interactions with pre-existing systems and the user’s activities must be supported through effective and usable interfaces, possibly compliant with the visual identity and interaction style of other corporate applications. 
Furthermore, the business requirements embodied in the process models, as well as the technical context in which the underlying applications are deployed, are subject to evolution. This may cause severe alignment problems when trying to keep the business process and the application in sync.
I think that business process models per se are not enough for representing the complexity of real world software applications that implement them; therefore other design dimensions must be taken into account in the analysis, design, and implementation of applications. 
The gap between process modeling and application development  (aka, the business-IT gap) can be alleviated by increasing the degree of automation in the design, implementation and maintenance of applications derived from process models. The automation framework should support the semi-automatic translation of the process model into running applications, be flexible enough to incorporate different architectural and interaction requirements, and apply not only to the initial deployment of the application but also to its evolution and maintenance.  An outstanding difficulty in providing such an automation framework is the semantic distance between the process model and the running application: the former dictates roles, activities and business constraints at a very abstract level, irrespective of how these are supported by computing tools; the latter embodies very low-level details, where business, architecture, and interaction aspects are blended together and hard to customize and evolve separately. As an example, the same user’s activity specified in the process model could be enacted in a variety of ways: by means of a wizard, by form editing, by using a legacy application interface, and so on. 
With WebML and WebRatio we propose an integrated design approach to BPM that comprises modeling of business processes, application structure, master data, and user interaction, together with automatic model transformations among them. In this way, it is possible to work at different levels of abstraction and get quick prototypes to be discussed with the customers, but also generate production applications to be delivered as finalized systems. Indeed, the models allow the designers and analysts to work on orthogonal aspects of the design, and to fine tune the final application in several ways, e.g., by integrating the visual identity of the organization, plugging in new components, or connecting the business process to legacy applications via Web Services. 
The basic design flow we propose is the following:
This is in line with and extends the vision of integrated BPM and MDM (Master data management) design proposed by Clay Richardson (Forrester) and studied by several research and industrial experts, including Rick Hull (IBM Research), ISIS Papyrus and Pallas Athena. 
You can try our solution by downloading the free WebRatio tool at .

Responses on BPM in the Forrester Blog

Software AG buys Data Foundations: Business Acumen Meets Data Competency (Fri, 10/22/2010, Clay Richardson Forrester Blog)

Dear Clay,
I think your predictions are crucial for both the data and process management fields. I would actually read them more as a recommendation to potential adopters than a mere prediction. I think that the evolutions you mention in the vendor market are only external signals of a deep need that has been latent for (too) long.
I strongly believe that business process models “per se” are not enough for representing the complexity of real world enterprises and therefore also of software applications devoted to implement the enterprise processes.
I think that other design dimensions should be taken into account in the analysis, design, and implementation of such applications.
Besides business processes, data is definitely one of these dimensions, and probably the most important one. In the approach we have been devising for some years, we studied some further aspects:
– application structure
– user navigation
– visual identity
As a research team, we have tried for a long time to find a way to combine all these aspects together in a sensible way. We ended up with Model Driven Development (MDD): different orthogonal models represent the various aspects of the applications and a set of mappings and transformation rules allow a seamless integration of all of them (plus a set of nice-to-have features, such as quick prototyping, integrated documentation, automatic alignment of models and implementation, and so on).
I would be glad to get feedback on this. Do you think it makes sense to consider further aspects wrt data and processes? Might MDD be an interesting option for integrating them?
Hi Marco,
Right now the real challenge is to these two worlds – MDM and BPM – together at the business-level, initiative-level. These are often two large-scale initiatives that live in silos and we know teams often try to address this at the application-level, but that’s too late in the process.
While I think MDD is a great approach at the design/architecture level, it really doesn’t address the real problem: How do you get the process professionals thinking about and taking ownership for maintaining data quality, and how do you get data professionals to take process into account for maintaining the quality of master data?
The MDM/BPM disconnect is less of a technical design/architecture issue and more of an alignment/synchronization issue. Most of the teams we’ve interviewed have tried to solve this problem at the technical level have had limited success – basically they’re using technical and development resources to triage data quality issues that creep up as a result of process improvement projects.
Alternatively, we’ve seen really good examples from successful teams. These teams have moved beyond trying to address MDM/BPM at a technical level and focus on governance to synchronize roles and activities across both initiatives.

My second comment:
Dear Clay,

thanks for your response. In my post I was mentioning MDD more as a methodology than a technical framework (although it it is more often intended in the latter sense). This means to think about reality purely in terms of models, and relations (or mappings, or transformations) among them.
In this sense, MDD could contribute in MDM and BPM alignment.
Indeed, I fully agree with you that the real challenge is on alignment and synchronization. I think that MDD can help also on this, to some extent, thanks to the its “models and relations” paradigm.
I bring this in as an integrated design alternative to the siloed worlds you mention. Obviously this is not always possible, but it’s definitely the one I would embrace when starting new projects (if instead you already have the siloes as a starting point, a longer discussion is needed on how and if MDD can be applied).
And then, I was trying to push the things a little bit further by saying that besides models for MDM and BPM, one could think to other aspects of the real world to address, and generalize the approach.
Maybe a grand vision, not for tomorrow, but something worth imagining.
We actually had some successful experiences on this, both at research and large-scale industrial level, by working on projects that integrated BP models, complex Data management models, user and role models, and user interaction models. Some slides about this are online on Slideshare ( and we are going to publish the experience in the upcoming book edited by Michael Rosemann and Michael zur Muehlen following up the industrial session of the BPM 2010 conference in Hoboken, NJ. I’ll keep you posted on this if you want.

BPM history in one picture

Starting from various sources and disciplines, I have built up a pictorial representation of BPM history in the last 30 years. I know, it’s shallow and incomplete, but I think it makes some good points.
Just one comment on the last step: model driven development seems to be recognized as a good practice in the BPM industry by now. Next waves? MDM (Master data management) integration maybe…

Obviously, comments are welcome!