The human side of SOA/BPM

Two recent posts that were completely unrelated have prompted me to write a little bit about the human interaction side of SOA and BPM. First, in response to the debate on maturity levels between myself and David Linthicum, Lori MacVittie posted this entry on the F5 DevCentral blogs. She didn’t get into the debate on maturity levels, but rather brought up a point about the use of the term orchestration. She states:

Orchestration of applications is a high level automation mechanism that can’t really be completed until there is a solid underlying SOA infrastructure and set of common services in place. It’s the pinnacle of SOA achievement, the ultimate proof that an organization SOA can indeed provide the benefits touted by pundits. But orchestration of services should also be the mechanism by which applications are constructed.

The second post that caught my eye was Ismael Ghalimi’s post, “What is Wrong with BPM.” In this post, he talks about the problems customers face in selecting a BPM product and some of the things that customers run into after the purchase has been made and they try leveraging the solution on one of their real business problems. He states:

Then comes the really fun part: the business folks want a different user interface for their workflow. The one you got out of the box seems to be working pretty well, and you could display your company logo at the top left, but somehow the suits have something different in mind, and they want it now. They paid $300,000 for some magic pixie dust that gives them business agility, and they expect it to make you a contortionist worthy of a full-time job with Cirque du Soleil. So you end up spending the next six months writing massive amounts of JavaScript code that will hardcode the customer’s process deep into the user interface. You will be late, over budget, and won’t benefit from future software upgrades, for what you have now is built upon a completely different codebase. Great…

The two things I want to call out are Lori’s phrase “orchestration of applications” and Ismael’s laments about the quality of the user interface. I believe both of these posts are hitting on an element that is frequently forgotten around SOA, which is the human interaction. Regardless of how many services you build, some user is still going to need a front end, and there are inherently different concerns involved. Ismael’s absolutely right that some bare bones web form creation tool slapped onto the ugly schemas that represent the process context just don’t cut it. While 5-10 years ago, you may have been able to limp by with basic HTML forms, today’s web UIs involve AJAX, CSS, JavaScript, Flash, and much more. The tools that are calling themselves orchestration engines excel at what Lori calls orchestration of services (the BPEL space), but I don’t know that there are many that are really excelling at business process orchestration. I’m using my definition of business process orchestration here, which is both the human activities and the automated activities. I’m guessing that this is what Lori meant by orchestration of applications, however, I try not to use the term application anymore. It implies a monolithic approach where everything is owned end-to-end, and that simply won’t be the case in the future. If I do use the term, it’s reserved for the human facing component of the technology solution.

True business process orchestration that includes the human element, is not one that we’re seeing a lot of case studies on, but it’s where we need to set our sights. The problem is quite difficult, as the key factor is context. When I was working with a team on a reference solution architecture for BPM technology, one of the challenges was how and when to bring in context. If you rely on events to trigger state transitions, should those events carry references to information, or the contextual information itself? If it contains references, then you need access to all of the associated information stores, and you need to figure out what information is relevant for the problem at hand. It’s hard enough to get this right for an automated system where the information required is probably well defined. Now try getting it right when the events are tied back to a user interface. The problem is that every scenario may require a different set of information. As humans, we’re good at determining correlations and understanding where to go. Systems are not. Our goal should be to creating solutions that support the flexible context required for true business process orchestration. I think this will keep many of us gainfully employed for years to come.

One Response to “The human side of SOA/BPM”

  • Good points on the “human integration” factor in the BPM space.

    I think the problem with integrating human interaction into BPM is primarily due to several factors. First is that most of the prominent vendors in the BPM space – PegaSystems, Savvion, Lombardi – grew out of the workflow market, so they’re far too focused on queues and workload distribution and hard-coded business rules (that’s another argument for another day, as these are really embedded application logic and not business rules in the same sense as orchestration). Second is that most of these vendors rapidly adopted BPEL and BPMN, both of which have been long criticized as failing to properly address the need to integrate manual processes into automation. Manual processing will likely always be required because as you point out, systems are not good at correlating certain types of information. Lastly, the latest wave of entrants into the BPM space came out of the EAI space, which again is focused on system-to-system integration, and not human beings.

    This all leaves the human factor out of the equation, and though BPEL4PEOPLE (BPEL 2.0) is a valiant attempt by the industry to address the lack of human integration in business process management, it doesn’t appear to go far enough from what I’ve read thus far.

    SOA is certainly the enabler for BPM, but it appears to remain constrained to “server” side interactions. Perhaps what is necessary to begin to really address human integration into the process is the notion of human services as well as business services. Services that are specifically designed knowing that they will be manually processed by human beings, and reside on the client rather than servers or in queues on buses inside the data center.

    We give a lot of lip service to asynchronous services, but in reality most processes aren’t built with this kind of asynchroncity in mind and when humans are involved, this is a requirement if the people factor is going to be properly addressed.


Leave a Reply


This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.