In-Depth

SOA: A Reality Check from IT Pros

Up to now, service enablement has largely been the baby of C-level executives and line-of-business managers. Many IT professionals see the promise of the technology, but warn that the reality is several years away.

• By Stephen Swoyer
• 06/21/2005

After more than a year of (mostly) unchecked momentum, the service-oriented architecture (SOA) technology bandwagon is rollicking along at full speed—propelled, as is so often the case, by the occasional amazing success story.

“SOA is in a lull, but it’s coming. Because we live in a day-by-day world, we don’t understand how fast it’s coming,” said R. Todd Stephens, director of metadata for BellSouth, at this spring’s TDWI conference in Baltimore.

BellSouth, Stephens says, is a case in point. The company has already service-enabled substantial chunks of its BI infrastructure—with startling results. “Some organizations have taken BI to the service layer. Which means what? I can’t find a data modeler inside BellSouth anymore—maybe one,” he indicates. “But I can find some UML class-diagram component programmers; and we’re exposing those Operational Data Stores through the service layer; and we run about 10 billion transactions through the service layer.”

SOA's triumph is the order of the day, but if history is any indication, the technology's inevitability could soon give way to another perspective—if-we-had-to-do-it-all-over-again hindsight. As students of the technology-hype cycle know, for every peak there’s an inevitable trough—a touching-terra moment in which the very real difficulty of translating a technological vision into practice can no longer be ignored.

By all accounts, SOA hasn’t yet reached this point. But—as some industry watchers concede—service-enablement has (up to this point) largely been the baby of C-level executives, line-of-business managers, and—of course—starry-eyed technology visionaries.

“We did a survey where we looked at the pervasiveness of the idea of the service-oriented architecture, and it turns out by a substantial margin that C-level and line-of-business executives get SOA and are more comfortable with the idea of SOA than developers are,” says Bill Roth, vice-president of marketing with BEA. BEA, for its part, is the latest player to clamber aboard the SOA Express: the AquaLogic vision the company outlined last week—which amounts to nothing less than a fundamental rebranding of its bread-and-butter WebLogic platform—is heavily predicated on the inevitability of SOA.

With AquaLogic, BEA is touting its own idiosyncratic wrinkle, too: the idea of liberating—or of liquefying (at the risk of endorsing a metaphor)—frozen or siloed IT assets. On top of this, BEA plans to add another differentiator: the notion that non-programmers—perhaps not business analysts, but technical or domain specialists—can tap the AquaLogic data-services platform to cobble together virtual (or “composite”) applications composed of nothing but services. “If you’ve service-enabled things the right way, it should be merely a matter of configuration and not coding [to build composite applications], and one look at our AquaLogic service bus product will tell you how that’s possible,” says Roth.

Among rank and file developers and other IT pros, SOA skepticism—cautious and otherwise—is the rule, not the exception. To some extent, it’s because of sunny technology optimism like that espoused by BEA’s Roth.

Still on the Horizon

IT pros, after all, tend to know a bit more about the nuts and bolts of the technology infrastructure that’s supposed to enable complete service-enablement than do their C-level counterparts. Some technologists who’ve looked at SOA say that while the technology has promise, it’s still largely only on the horizon.

For starters, says Jeff Grigg, an independent programming consultant and J2EE specialist, SOA is heavily tied to other emerging technologies, too—such as the business process execution language (BPEL).

“[Service-enablement] seems like a good idea, but people will have to make their services available as WSDL-described SOAP services first. Until businesses make a big investment in SOAP-enabling their business applications, there won't be much to drive with BPEL,” he comments.

This isn’t to put Grigg in the anti-service-enablement camp, either. In fact, he says there’s a way developers can reap the advantages of service-enablement in the here-and-now and (in many cases) liquefy “frozen” IT assets, as in BEA’s AquaLogic and other SOA visions. “Today, write SOAP Web services. It's an interprocess communication standard that's attractive because it's more widely accepted than CORBA or DCOM. So it's a winner."

This gives IT organizations a good foundation on which to build their service-enabled infrastructure of the future—when all of the technology pieces are in place. As far as programmers such as Grigg are concerned, that isn’t today.

“WSDL descriptions make development easier, but I don't think today's developers—or tools—are smart enough to really leverage it at run time,” he argues. “BPEL is a nice idea. Maybe someday we'll have the infrastructure necessary to leverage it. But it's several years away, except for a few specialized applications in leading-edge institutions.”

This is something even SOA evangelists concede. In fact, says Roth, BEA’s AquaLogic vision will actually unfold over several years. “Right now, we’re seeing enormous demand on our AquaLogic Service Bus, and AquaLogic Enterprise Security is available today, but will we see a [sharp uptick] in revenue because of this? I don’t think that’s credible,” he explains. “AquaLogic and SOA are part of a three-to-five year journey [in which] we’ll address things like how to build a metadata-driven, configuration-based process orchestration engine, how to build a user infrastructure or user interface in a metadata-driven way—issues like that.”

Along the way, BEA and other SOA proponents will surely face resistance from cynical IT pros who view AquaLogic and other similar visions as the latest spin on just-another-old-idea. Such IT workers are often highly skeptical of SOA and other “pie-in-the-sky” trends—even if (as is often the case) they admit to having an imperfect understanding of them.

Take Kevin Kinney, a mainframe operator with a leading provider of information management solutions for the financial services industry. “Personally, SOA seems to be just a shiny new name for reusing code. The concept hasn't really caught on even under the old name regardless of whether the code is Assembler or XML,” says Kinney, who concedes that his employer probably isn’t “in the mainstream” on the subject of SOA.

Even though companies like BEA have articulated SOA visions that embrace (so-called) “legacy” systems and siloed data sources, Kinney sees SOA as growing out of the “shrink-wrapped” PC and Unix system software space, which he says isn’t necessarily comparable to the way things have traditionally been done in the mainframe space.

“Our mainframe-based business model [is] different. PC software is based on the number of shrink-wrapped boxes moved out the door. In our particular case—on the mainframe—our revenue is based on licensing as well as consulting with clients who desire personalized solutions. Yes, that can be a pain at times, but simply switching from a customized solution to a cookie-cutter approach is something that needs to be carefully considered.”