Recently I was asked by a large financial software vendor to present a talk about the relationship between SOA and BPM at in internal IT conference aimed at their top IT architects, managers and developers. I was not alone. A number of other presenters, many representing companies with SOA and BPM development products to sell, extolled the notion of tying together SOA and BPM.
In general, the vision presented was a brave new world where business analysts can simply compose the new or improved business processes they need from a set of reusable business components, after which some run-time execution BPM engine (nowadays usually based on BPEL) will end up invoking the appropriate reusable SOA-based services to execute those processes.
To this end, each of the various presenters happily showed off slideware of his own company's BPM/SOA 'marketecture'. This usually involves some kind of layered approach, with 'business components' in a BPM layer connecting via an enterprise services bus (ESB) down to one or more' service components' in a SOA layer. From the SOA layer, some of these service components call other service components, while the most granular call the necessary implementations, which are typically 'wrapped' legacy applications, either custom developed or COTS.
I suspect nearly everyone reading this blog has already seen some form of this kind of approach - you may even have presented your own version! It is certainly a very appealing idea and, as a vision, I completely support it. But there's just one problem - as usually presented today, it is mostly a sleight-of-hand magic trick, not reality.
As with most such magic tricks, the presenter must get the audience to believe they 'saw' something that didn't really happen. In this case, this involves getting the audience to believe that, just using BPM and SOA, they will automagically come up with an appropriate set of reusable, recomposable components at both the BPM and SOA layers, plus an efficient mapping between the two.
In fact, when pressed by this very savvy audience, none of the presenters could actually explain how a real company with real IT systems could actually get from where they are today to realizing such a set of reusable components, except perhaps in a very limited way. As long as this remains the case, I don't expect his BPM-to-SOA approach to get much beyond the hype stage. Unfortunately, if it gets too hyped in its current 'magic' stage, it may even ultimately discourage companies from even trying to reach its ultimate and, I believe, very achievable vision of using BPM and SOA synergistically.
So, what's the problem with the 'magic' BPM-to-SOA approach I just described, and how do we get beyond that magic to something real? The first step is to realize that unfortunately, neither BPM nor SOA can, together or singly, tell you how to define the correct components you'll need at either level, much less how to synch these up.
Yes, once you have a set of such components, BPM will allow you to recompose them at will into new processes, and SOA will allow you to deploy and execute them on an enterprise (or even inter-enterprise) service bus. This makes them potentially very powerful enablers, and that's why they sound so sexy together. But until you figure out what those reusable business components are, the whole BPM-to-SOA approach remains in the realm of legerdemain.
So, is there an approach that CAN help to identify a set of reusable, recomposable business and service components? Fortunately there is – MDA. By properly applying MDA to this kind of problem, you can develop multiple viewpoints of your enterprise architecture, while keeping those viewpoints in synch. And that's exactly what we need to link up BPM to SOA.
In MDA, a ‘viewpoint’ is just a set of models presented in a form suitable to a particular audience. So, in this case, we can develop a viewpoint for the business analysts to show the available enterprise functionality (IT or otherwise) as a set of reusable business components, which can be linked together using BPM. At the same time, we can also show the available IT functionality as a set of reusable service components, each with a mapping down to one or more implementations, which can be deployed in a SOA ESB.
But what about the mapping between the two viewpoints? In MDA all models are well formed and formalized. Therefore, it is possible to represent a mapping between viewpoints as a set of formal ‘transformations’, each of which just another form of model. In some cases, all or parts of a given transformation can be automated. In other cases, some kind of human intervention will be necessary to effectuate the transformation. But, in either case, MDA will help keep everything in synch.
Now, armed with MDA, we can paint a much clearer and more compelling picture of the BPM-to-SOA approach. We start by defining a formal BPM-based business viewpoint, a formal SOA-based services viewpoint, and a formal transformation between them. Until we can do all this, we really can’t guarantee that any particular set of business components – or any business process built from those components – can map down to SOA. But, once we define the viewpoints and transportations, we can now guarantee that every such business component or process defined at our BPM layer will map down clearly to service components at our SOA layer.
By the way, this also explains why it doesn’t make sense to just start doing BPM at one end, and SOA on the other, and hope that the two will somehow synch up. Without a common framework like MDA sitting in the middle to guide the mapping, it will never happen.
Interestingly, none of the other presenters at the conference even mentioned MDA in their talks. To be fair, the conference was on SOA and BPM, not MDA per se. However, when questioned, several of those who marketed BPM and SOA tools freely admitted that their own organization were using MDA extensively in order to move information around within their toolsets, and to keep that information in synch among different viewpoints. If these vendors depend on MDA to design, develop and integrate their own software, maybe they should also start telling their customers a bit more about how to take advantage of the same approach. Maybe that would take some of the mystery out of the BPM-to-SOA connection.
Have you had any experience trying to create a mapping between BPM and SOA? Did you use MDA for this purpose? Are you interested in learning more about this subject? Do you have an alternate point of view? If any of your answers were 'Yes', please post your comments to this blog - we look forward to hearing from you.