How do I pair BPM modeling tools with an SOA?

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT BPM Modeling BPMN 2.0 adds notation to handle BPM choreography KANA releases a new business oriented SOA platform Software AG mounts tender offer for IDS Scheer Appian-SharePoint link upgrade Parasoft releases SOA Quality Solutions Say 'hello' to business process lifecycle management Enterprise mashups poised to power app dev for masses? Co-evolution of BPMN and BPEL drives BPM in SOA settings Business Process Modeling Notation Mini-Learning Guide

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

When trying to make sure your BPM tooling takes full advantage of your SOA efforts, one of the most important things to consider is the ability of the BPM tooling 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 application portfolio management (APM) 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.