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.