Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

How do I pair BPM modeling tools with an SOA?

When pairing BPM and SOA, a BPM modeling tool should take advantage of a service registry/repository. Expert Todd Biske explains why.

What is one key characteristic that I should look for in BPM modeling tools, especially when looking to pair them with a service-oriented architecture?

When trying to make sure your BPM tools takes full advantage of your SOA efforts, one of the most important things to consider is the ability of the BPM tools to take advantage of service metadata that exists in a registry/repository. Whether modeling within the tool is being done by process analysts or by developers, the ties back to your service repository are important.

First, consider the process analyst. Typically, this person will be working solely within the confines of a BPMN model. A BPMN model is going to consist of flow objects, connecting objects, swimlanes, and artifacts. The two items that have relevance within SOA are the activities (part of the flow objects), and the swimlanes. Swimlanes frequently represent ownership boundaries of functional domains, and these may be the same boundaries used to define your service taxonomy. If you have this taxonomy in your service registry/repository, it would be great to have it accessible to you during your modeling efforts. Secondly, when adding activities to your processes, many of these activities will represent services invocations. As these activities are defined, they should be shared across processes where appropriate. Unless these activities are saved in a repository that is viewable across all processes, you are at risk of having them be defined multiple times, potentially in different ways. If the tool is not integrated with your service registry/repository, then you may have BPMN activities shared across processes, but when that process is handed off to a developer for implementation, the activities associated with mapping that activity to the right service will need to be repeated every time, with risk of it being done inconsistently.

This brings us to the developer side of the process implementation. It is the developer's role to take that model and turn it into something that can be managed by the runtime BPM engine. To do this, there typically is a message flow associated with the process, with steps along the way contributing or manipulating information within the message flow. To do this properly, every automated activity must take some information in and provide some information out. This information is mapped to the information that flows through the entire process. If there is no connection between the service registry/repository and the BPM tool, the service definitions must be manually imported, which can again lead to incorrect mappings in the worst case, or in the best case, a less efficient development effort.

Analysis by groups like the Burton Group have shown that there is a strong correlation between effective BPM efforts and successful SOA efforts. If portfolio management is a success factor, then it is important that the tooling we use take full advantage of that portfolio information wherever possible. The service registry/repository hold the service portfolio, and as a potential orchestrator of services, the BPM engine should be portfolio-aware to fully leverage the efforts from SOA.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.