Requires Free Membership to View
When you register, you'll begin receiving targeted emails from my team of award-winning writers. Our goal is to keep you informed on recent service-oriented architecture (SOA) and SOA-related topics such as integration, governance, Web services, Cloud and more.
Hannah Smalltree, Editorial Director
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.
This was first published in November 2009
