Something strange in your SOA... who you gonna call?

In the US presidential campaign, Hillary Clinton's ads have been asking who is the most qualified to be picking up that 3am emergency call.

Why is a service malfunctioning? Who knows?

When it comes to SOA, who should be picking up those 3am SOA problem calls?

Forrester's Randy Heffner says many organizations are uncertain who should best be handling these calls. Often, one team or another may be charged with handling any malfunctioning services, but end up dragging in everyone else in for perplexing problems. I recently had the opportunity to host an ebizQ online session on this challenge, with Randy and AmberPoint's Ed Horst.

SOA has a lot of moving parts, and digging down to spot the root cause of a service problem is not always easy. SOAs are multilayered creatures. Is it the service itself that's creating an issue? Is it the database? Is it one of the servers? Who knows?

In his talk, Randy advised that unless teams want a lot of late-night calls, SOA management tools need to address what he calls "deep service" management.

Randy pointed out that SOA management tools all do a fairly good job of alerting administrators to problems with a service. Even in a complex service implementation -- it could be Java, .NET, messaging middleware, or legacy connectors -- when trouble is afoot, a good management tool will do a good job of sending an alert out.

Now, Heffner says, "great, we’ve identified there’s a problem with a service, who we going to call?"

With complex SOA implementation, and multiple teams, the only answer that will be coming from everyone within their respective teams saying, "it's not me -- my stuff is working fine." That's because everyone has a view limited to their piece of the infrastructure, Randy says.

Randy urges configuring SOA management strategies and solutions to conduct "deep service management." Typically, SOA management solutions employ solutions that don't look beyond the SOAP interface. A new generation of tools that are emerging, however, that can look beyond the service interface to the databases, services, and messaging layers beneath.

"Your SOA management solution, however you construct it and buy it, must handle SOA-based service requests that have complex service implementations," Randy said. This could involve services that invoke Java Message Service, MSMQ, Java RMKI, or CORBA, he elaborated. Or, there may be an ESB or app server behind the service.

Many deep service SOA management approaches can start with agents that many SOA management solutions provides, Heffner said. Then, there are also an increasing number of management solutions that run natively on various platforms.

They key is to employ these solutions -- with or without agents -- to gain better visibility into the systems behind the services, he said. "SOA management solutions may have various ways to construct or correlate a picture, such as dropping tags into a message... or, you might have to do a little work in the configuration..."

The benefit is that as problems with services arise, problems will be better isolated, and administrators will know which team to call for assistance, such as the database team. The alternative is all-night sessions rooting out problems with all the various teams behind the service. And, ultimately, such deep service management delivers benefits beyond root cause analysis, such as capacity management -- another issue that arises as SOAs gain steam.