How, Specifically, BPM Can Help with SOA Problems

Loraine Lawson

This week, I've focused on the core problems with SOA -- governance, service level agreements and basic reuse challenges, such as what do you do when a small component of a service breaks and it brings the whole shop to a halt.


ITIL and IT service management is one way to address these problems. But the tool I see mentioned more frequently for managing SOA is business process management.


Recently, I interviewed Phil Larson, director of product management for Appian, which specializes in Business Process Management. Appian recently released its Enterprise 5.6, which includes nifty new features -- RSS feed integration, easier design and rules creation, to name a few -- all designed to involve more organizational users in the BPM process.


As it turns out, Appian is knee-deep in SOA and Larson had definite opinions about how BPM can address the major challenges of SOA. I asked him which comes first, SOA or BPM.


Larson wasn't taking the bait. His argument is that BPM and SOA are synergistic and can support each other. Specifically, he contends BPM can provide a governance methodology for SOA.


Larson identified four specific SOA challenges and explained how BPM can address them. Though he names four, he covers the same major challenges we've talked about this week.


1. Prioritization of services. Obviously, organizations are struggling with which services should come first. Larson argues that by focusing on business processes, companies can identify their core processes and what's going to impact their business. Then, IT can focus on building the services that will have the largest impact on those core processes. Larson points out this solves two problems: How to prioritize services and the scope of the services. I would add it also solves another underlying IT challenge: Aligning with the business.


2. Funding issues. Funding was easy when applications were built for specific departments. With SOA, you never know who may end up using your service -- and therefore, you don't know who should pay for it. Larson says:

"What will end up happening, I believe, is that organizations will want to structure the funding of their initiatives in ways that are based off use. So in the same way software as service has taken off as a market because it meters the usage of technology, organizations will want to fund their products this way and say you can use these services, but we're going to implement a charge-back service in which we monitor the use of the service and you'll help pay over time for this service."

A BPM suite can address this because it can monitor use of services and provide analysis on who's benefiting most in the organization from a service.


3. The question of ownership. In the old school funding model, it was clear who owned an application: The department. SOA confuses this issue, because the ownership can change over the lifespan of the service. BPM by design can manage roles, responsibilities and ownership of processes. This same functionality can be used to enforce ownership roles with services, according to Larson.


4. Service-level agreements. Again, with SOA, you're moving around code that was designed for specific uses, with specific promises about what it would do. When you change the context -- as SOA does -- the service level needed may change. And as Larson explained, the application or the value that's being created for the customer is created out of multiple services. How do you create a service level agreement for that?


He contends the person that's ultimately responsible for that value to that customer has to make sure they've got the right service level agreements in place. And the tool they can use to manage service level agreements is BPM.


Larson isn't saying SOA has to be managed with BPM. He's just saying if you start with BPM, it can help.


For more from Larson on Appian and how SOA is impacting Appian's BPM solution, you can read the interview here.

Add Comment      Leave a comment on this blog post
Jun 6, 2007 8:22 AM Dirk Deschoolmeester Dirk Deschoolmeester  says:
Hi,I would like to know what you mean by BPM.Even if acronym means "Business Process Management" , then I would be careful with use of this acronym without specifying at what level the BPM-acronym is used .I personally think that distinction should be made between a higher level organisational concept of managing the processes of a company or business unit on one side(ie higher level end2end processes crossing different departments in the organization) and the far down the organization , detailed level of( sub-)processes .These detailed ICT-supported (sub-)-processes are situated at level of"ICT-applications installed and used to support (usually smaller parts of ) such higher level end2end processes crossing different fragmented parts/departments of the organization .In other words lets recognize that BPM can be used to refer either to discuss with management about their ways of doing the work while ICT-views of BPM are very much at detailed level for supporting parts of such organizational processes.To consider this BPM-definition distinction is worth a long discussion.While management is still wondering in many organizations what meaning and value is of BPM-concept , ICT-specialized professionals have "captured" the BPM-acronym like it is only to be "owned and captivated" for talking about ICT-solutions meant to support only parts of problems situated in the higher level business processes of the organization ... ! Reply

Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.