In-Depth

SOA: The Services Are Out There

Successful service-enablement requires a high degree of visibility into an organization’s IT inner workings.

• By Stephen Swoyer
• May 9, 2006

According to industry watcher Forrester Research, large organizations spend nearly three-quarters of their IT budgets on application maintenance, the bulk of which takes the form of routine activities such as bug fixes, modifications, improvements, and new-feature requests. If there’s one thing service-enablement can help cut down on, proponents claim, it’s spending of this kind.

There’s probably some truth to that. It’s probably just as true, however, that the transition to a service-oriented architecture (SOA)—that sine qua non of pervasive service-enablement—entails costs of its own. For many organizations, the road to SOA-dom, once embarked, isn’t without a pothole or two. Because SOA assumes an unprecedented degree of cooperation among services, applications, data sources, and other resources, a change in one location can impact a seemingly unrelated service at another point. For this reason, some SOA proponents argue, successful service-enablement requires a preternatural degree of visibility into an organization’s IT inner workings.

“The problem [for most SOA adopters] is that they [have to] clearly identity the business services they want to execute as Web services—[services such as] calculate tax, authenticate user, generate invoice, and so on,” says Guy Hoffman, president and CEO of SOA lifecycle management specialist Metallect Corp. “The first thing you have to be able to do is map those business services to all of the instances of the logic that you already use to execute those services.”

This includes COBOL, RPG, C++, C#, Perl, and other logic, Hoffman says—as well as RPC calls, SQL stored procedures, and so on. More importantly, he claims, SOA adopters must identify and reconcile all instances of redundant or reduplicated services—regardless of the platforms, languages, scripting engines, or data sources for which they’re written. What good, after all, is a service-enabled infrastructure with several instances of the same service? “It’s important that you locate all of these instances for several reasons. If you have 32 instances of ‘calculate tax’ already, creating [a calculate tax] Web service is only going to give you a 33rd, unless you can deprecate the other 32,” Hoffman notes.

Hoffman isn’t exactly a disinterested observer, of course. His company markets IQ Server, an application maintenance and modernization solution that it also pushes as a solution for many of the discovery and identification issues which bedevil frustrated SOA adopters. In other words, it’s in Hoffman’s interest to highlight—if not amplify—some of the infrastructure challenges associated with service-enablement.

He parries this charge by stressing that many customers, knee-deep in the muck of SOA transitions gone awry, come to Metallect looking for help. “A lot of time, [the impetus for the customer is] the whole Pandora’s box of, ‘We started down this path, and it looked good to begin with, but at some point, it spawned a whole bunch of problems,’” Hoffman explains.

For example, he says, once you’ve consolidated and subtended your existing services, you must anticipate the emergence of unsanctioned or rogue services. They’re a bigger problem than a lot of organizations might think. Mostly it’s a question of governance: just because you’ve identified and eliminated (or deprecated) all of your redundant services (as a subset of a master service) doesn’t mean a frustrated or entrepreneurial programmer can’t (or won’t) take things into her own hands.

“[Some of these] problems are related to SOA governance—we’ve created this new service and that’s great, but we still have every developer with the ability to create new services. Say [a developer] doesn’t like the service, or doesn’t want to use it—maybe because it uses [or exposes] an interface he doesn’t like. So he creates a new service, just for his own use,” Hoffman says.

From a governance perspective, this is unacceptable. In an aggressively service-enabled infrastructure—where dozens or even hundreds of services might eventually be in play—it’s not hard to imagine a scenario in which more than a few might be rogue or renegade entities, and that’s also not counting the possibility of malicious services.

How can organizations know what’s out there? Enter Metallect and IQ Server. “What we do is help enterprises minimize risk and accelerate cycle times by minimizing costs related to application lifecycle management,” Hoffman says. “Basically the problems of cycle time and risk mitigation are key, and reducing costs is a byproduct of that. What we’ve done is built a software platform that goes out and scans all of your application logic, source code repositories, database schemas, and associated middleware.”

IQ Server scans source code repositories, exposed APIs and databases to generate a metamodel—a canonical catalog—of an organization’s existing application infrastructure. “This is really important when we talk more specifically about how a Web service or Java method that you’re looking to wrap as a service may down the line message a DB2 table through a mainframe or through a message bus like MQ,” Hoffman comments.

“We have metadata generators for specific technologies—they’re a lot like source code—and they generate the metamodel. We use RDF [resource description framework], and we’re building a graph, we’re making each of the grammatical constructs of each individual language a node on the graph, and what RDF allows us to do is annotate that graph.” At that point, Metallect uses custom inferencing algorithms to determine which services are redundant or superfluous: “[This inferencing engine] extracts the meaning of [the programming] logic and the context in which it’s used.”

Hoffman thinks SOAs have staying power, but he takes issue with the idea that the SOA is an imposition from without. Specifically, says Hoffman, the push for SOAs is coming almost entirely from IT executives—not necessarily from business executives, in spite of the attractiveness of an application paradigm in which IT resources are understood and described as business services, and not abstracted as multiple, interoperable systems.

“The value proposition of an SOA really resonates with the business people—it’s better, faster, cheaper. That’s always going to resonate with the business person. [But] when push comes to shove, I don’t think the business people give a damn about SOA,” he concludes. “Where I think it is coming from is the IT executives who are looking at this and saying, ‘My inputs are coming from the business people and they’re going up; my ability to fulfill this is coming from [programmers in the] trenches, and my [IT] budget is going down. How do I address this?’”

The attractiveness of SOA is that—on paper, at least—it promises to help IT executives stretch their IT budgets further. “I could make an argument that [a substantial percentage] of the logic they need to run their business already exists [internally], and once we get it service-oriented, you probably don’t need as much [of your IT budget] to run this,” he concludes.