SOA management software can put your business operations on cruise control, but don't fall asleep at the wheel.

	express delivery
	• print  • comment
	When process automation falters because of unnoticed errors, having preset policies in place can keep things running smoothly: SOA management software can be used to implement preset policies In theory, it should focus on how the infrastructure is operating But it can also be used to enforce business rules Specialist tools are needed to design new policies Automating policy enforcement removes integration bottlenecks
	Glossary terms: BAM, SOA, SLA, BPM, runtime, lookup tool Sponsored links: your text link here

In a services oriented architecture (SOA), business applications exchange information by sending messages. It's the job of SOA management software to monitor the message flow and make sure it complies with predetermined policies, such as security settings and performance criteria. In theory, it's also possible to monitor and manage business activity by analyzing the content of the messages. But many vendors steer clear of taking that extra step.

James Phillips, senior VP at SOA management specialist Actional, is one of those who disagrees with the notion of "snooping" on traffic to find out what's going on at a business process level: "What customers have told us and what BEA and Microsoft have told us is that it's silly," he says.

Instead, data about business activities and service levels should be fed into applications that are specially designed to handle such information. "The best way to empower customers with that knowledge is through dashboards that can be built into an application," he says. For example, the best place to monitor the business process of accepting and checking an order is from within the console of a business process management system.

But the division of responsibilities is fuzzier than this initial outline suggests. Although it doesn't participate in creating the policy, SOA management software plays a vital role in enforcing business policy within the infrastructure. Once process data has been marshaled and analyzed within a business application, any policy decisions that are taken will then be handed back to be implemented within the SOA infrastructure. For example Infravio makes great play of its focus on enforcing service level agreements (SLAs) that embody predefined policies for service interactions. "We've considered the kind of SLA items you'd need in a contract. We've called them terms. You specify SLA items as part of the contract between consumer and provider," says CEO Jeff Tonkel.

Infravio maintains the demarcation favored by Actional's Phillips, providing interfaces to external third-party applications that deal with business activity monitoring — and, indeed, systems activity monitoring. But it plays a full role in implementing any policy decided within those applications, providing a repository for setting up and storing service contracts that embody the policies to be enforced.

OSI layers

This divide between policy decision at one layer and operational execution at a layer below was originally established in the seven-layer OSI model for network applications, according to SOA management vendor Confluent. Acquired earlier this year by Oblix, Confluent staked its architecture on maintaining a clear demarcation between user decision-making at layer 7 of the OSI model and the operational deployment of those policies at layer 6.

"We are not about managing business processes at all. We are a layer down," explains VP marketing Paola Lubet. For example, verifying whether the person approving an order is authorized to do so is a matter of implementing existing policy as already defined in a service contract, whereas deciding to deliver the order from Oakland because of a snowstorm in Ohio is a matter of business process policy formulated in response to changing conditions.

"Sometimes our competitors get into the business activity monitoring space. Our focus is in enforcing operational policy. We look at the content of the messages just to see if that process needs to be handled in a certain way," she says.

But sometimes that dividing line can be tricky to discern. Dublin-based services management vendor WestGlobal found that infrastructure performance was inextricably linked to business process decision-making for its customer O2. "As they exposed their systems to interact with competitors for the first time, they wanted to ensure there was no negative impact on their own systems," says the vendor's CEO Paul Acton. "So for example were they still providing adequate levels of customer service? Was the self-help time to provision a new service still being maintained at a business level?"

In such circumstances, SOA management vendors can hardly be blamed for getting drawn into business process management issues. If important decisions can be taken quickly on the basis of information analyzed within the SOA management console, it's often a more pragmatic choice to take them there and then, rather than bringing a separate business process management application into the project.

After all, customers feel a business impact whether it's the process or the infrastructure that's at fault. Many will find it hard to understand a dogmatic insistence on keeping application-level decision-making separate from infrastructure-level implementation.

Unexpected errors

Recognizing this duality, SOA management vendor Amberpoint has designed its Exception Manager product to cope with problems arising from either layer. "Customers have two categories of conditions they have trouble with," says VP marketing Ed Horst. The first is technical, for example when a system fault means that orders have been closed and shipped but not invoiced. The other falls into the business process sphere, for example allocating phone numbers that have already been taken when provisioning a new line to a telco customer. It doesn't matter that this is a process design fault rather than a software glitch — either way, it needs to be identified and fixed.

Exception Manager still defers to human operators when it encounters an error that it doesn't have a policy for dealing with — irrespective whether the error has occurred in the technical or business sphere. The technology has no autonomous decision-making capability. Like cruise control on an automobile, it simply automates the execution of predefined policies.

It's handling those unexpected errors that makes some vendors wary of getting too deeply involved in business activity monitoring. Developing software to support policy decision-making requires very different skills than automating policy execution. This is the most significant divide between infrastructure and application software, and any vendor that aims to straddle both sides must make sure of having access to the right skills for each. Those who choose to hand off to separate specialists perhaps are simply avoiding over-extending themselves.

For the moment, though, the policy decisions customers are likely to be making are going to be fairly straightforward. Most enterprises are just at the beginning of automating policy enforcement, and have come to it as a matter of necessity — "Web services have exacerbated the need to have runtime enforcement of policies," says Lubet. The main problem they face is how to apply existing policy to new process automation, rather than creating new policies to handle unexpected conditions. When they automate process integration, it removes manual steps where people would previously have been on hand to spot policy breaches. So unless policy enforcement is automated at the same time as the process itself, much of the benefit of automating the integration is lost. Effective policy enforcement is essential to productive services integration, and customers are going to expect SOA management vendors to fulfil that need.

More on this topic