SOA and Process Modelling

Being an ardent advocate of most things BPM and SOA, I am constantly disappointed, but not surprised, to find IT departments investing in development and integration tooling to support SOA that stop short of anything that contains the word ‘process’ in it. E.g. Process Modeller, Business Process Management, Process Engine, etc.

When I first came across this state of affairs a few years ago, I would have to admit that some of the process software and its integration with application development environments were fairly rudimentary. However, for at least the last three years, the tooling and interface standards have improved to the extent that the process tools can share registries and repositories with development and production libraries allowing objects and data to be freely exchanged and standardised.

So how is it that even today, most architectural and procurement decision around SOA tooling ignores or vetoes the process products? I have talked to a number of business managers who were told that their request for a process modelling tool was turned down by IT. I try to rationalise this in a number of ways. Perhaps the recommenders are unaware of the tools? Unlikely, as all SOA tool vendors have process offerings. Maybe, there is no budget? So why have they spent their money on a global ESB licence that they won’t get around to using in anger for at least three years?

Finally, it dawned on me that there were four main reasons why IT doesn’t get process. The first is to with how many IT folk think and act. With the current popularity of agile development, many projects start with a brief user workshop then a succession of scrums and prototypes iterating towards what the users and/or developers think they want. With much of this being delivered in the form of web services, the process and procedural aspect of the business service being developed is tends to be built into the services or developed as part of the portal implementation.

The second reason is that very few IT people would use (or know what to do with) the process modelling tooling, so these process products are removed from any shopping list or architecture diagram they have. I have uncovered several examples of the process tooling being dropped at either the architecture or procurement stage, as the recommender can’t see a need for it. This has left business sponsors, business analysts, change managers, and other assorted business related people bemused and unhappy. As most software purchases have to be approved by IT, this effectively prevents them from purchasing the modelling tools. Where business analysts have got some budget, they will run the risk of being cold-shouldered by IT when it comes to installing and supporting the process software.

The third reason is that process modelling tools are traditionally bought directly by business analysts or business change teams to help them understand business processes and workflows. These tools were mainly stand-alone graphical workbenches, one step up from Visio, which allowed the analysts to help the users visualise their ways of working. Their output tended to be just diagrams of process steps and was used for documentation only. Although these diagrams could be used as part of the requirements definition, they were just there to support the inch thick detailed requirements document.

Finally, many development teams see UML as the modelling language as choice, but this does not capture all the manual people and process steps that a full business process model requires. A fully functional business modelling tool can provide the high level business process diagrams for the users, logical diagrams for the analysts and lower level IT process steps for development all from the same model using different views.

However, most current process mapping and modelling tools provide much richer capture capability for the more detailed information development require to understand and design the required IT solution. Export of integration of information flows from the modelling tools to the development environments allow the objects defined in the models to be made available directly. There are a number of standard intermediary standard formats available to take the BPMN (Business Process Modelling Notation) input and provide Business Process Execution Language (BPEL) or Unified Modelling Language (UML) to the developer environments. In addition, many vendors provide repository sharing or integration of the process models with the development repositories or libraries, with version and library management support.

The solution to meeting everyone’s needs here is, as ever, education. The analyst community need to be smarter in explaining the benefits of process modelling and execution to the development teams, and start providing the requirements as proper service descriptions and data objects. Development teams in turn can provide their preferred templates for their own tools and repositories so that the process requirements can be delivered in the most usable format. In addition, we need build better end to end business cases for the process components of the SOA toolset.