The tools available to developers for building and deploying Web services can easily lead to the wrong kind of success. Its easy for individual application developers or business units to use new tools and standards to define a function and expose it in the form of a service; its harder to make services talk to one another across unit boundaries, or among partner organizations, to achieve code reusability now and flexibility in the future.
Enterprisewide issues must be considered and addressed at the beginning of the process; infrastructure must be designed and implemented to accommodate heterogeneity and manage future change. Without these upfront actions, an early appearance of success in experimenting with an SOA (service-oriented architecture) can turn out to be a disappointing dead end. This was a key warning that emerged from a roundtable conversation convened last month by eWEEK Labs to assess the current status and direction of SOAs.
Several roundtable participants agreed that customer sophistication has greatly increased in terms of understanding that merely building application components with Web services technologies is not enough to bring about a service-oriented IT environment. “There is a better understanding that SOA is actually a broader concept—that its a more efficient way to build applications through reusing existing assets and reducing the level of redundancy,” said BEA Systems Inc.s Fabrice Lebegue.
An SOA is more than the endpoints of a network of IT resources, said Oracle Corp.s Ted Farrell. “In the past year, I would say the biggest influencer weve seen, hands down, is BPEL—Business Process Execution Language,” Farrell said. “Having a very simple language that lets you quickly and declaratively hook these things up and actually start wiring services together into applications has been enormous.”
A possibly related shift, as described by Microsoft Corp.s Ari Bixhorn, is a movement away “from using Web services as an internal-only technology to one that spans organizational and trust boundaries. I think thats where were now seeing Web services hitting a tipping point.”
Several participants said tools and trends such as those that Farrell and Bixhorn described have both enabled and required the emergence of people who live up to the label of “enterprise architect”—not merely devising architecture in the individual IT silos of an enterprise, but thinking in architectural terms about IT assets and capabilities across the enterprise.
Said Sonic Software Corp.s Gordon Van Huizen, “Weve seen some very strong individuals and groups with those capabilities emerging—dealing with broad-scale systems architecture issues, thinking about the implications of creating sets of collaborating services, thinking about governance issues across the organization and [being] responsible for mapping business requirements into technology.”
Van Huizens observation is as much a challenge as a declaration of victory: Would-be adopters of SOA, warns eWEEK Labs, should not underestimate their need for strong technical leaders who are able to achieve and communicate such a perspective.
That big-picture view of the business—and recognition of its inevitable change and continuing heterogeneity—is essential to avoid a false definition of SOA goals. Its not success, emphasized Blue Titan Software Inc.s Frank Martinez, to construct a system based on service definitions and interfaces if that system still has all the problems of previous approaches to application integration.
What makes Martinez optimistic is the shift he said he sees from customers thinking about services as an interoperability solution to thinking about service orientation in broader terms as an “evolvability” aid.
Alexander Krapf, from Codemesh Inc., didnt want to see the group dismiss too quickly the continued importance of Web services in paving the way to SOA success. The ideas behind SOA are not really new, Krapf said. “In CORBA, you could do many of the things that you can do with more modern SOA approaches, but [CORBA] never took off,” he said. “What were seeing now is much more widespread adoption, not just on the middleware vendors side but also on the application vendors side.”
Krapf credited Web services—which can be easily implemented and broadly supported by nonproprietary standards—with energizing the SOA process. “The continued adoption of Web services is probably the biggest thing to get the SOA idea out,” Krapf said. “More and more ISVs are publishing Web service-based interfaces.”
In fact, said IBMs Scott Cosby, the level of interest in using Web services to implement SOAs is at the point where any remaining weakness or volatility in standards is now overshadowed by the prospect of almost-immediate returns. “Theyre not waiting for the standards to solidify,” Cosby said of the IBM customers with whom he works. “Theyre going ahead and making progress.”
Microsofts Bixhorn agreed but joined Blue Titans Martinez in emphasizing the need to treat developer enablement as the beginning rather than the end of the journey to a services model. Bixhorn said its a matter of “making sure that I as a developer not only have the ability to build services but also that we have the mechanisms to securely expose them to our partners, to make them discoverable to our partners.”
The Hartford Financial Services Group Inc.s Ben Moreland, who represented SOA customer concerns during the roundtable, was glad to hear it. Moreland cautioned that an excess of interest in developer productivity was perversely “the one thing that scares me.”
The problem, he said, is that “the way that the tools have emerged is that they look to developers to create the WSDL [Web Services Description Language] that goes into the UDDI [Universal Description, Discovery and Integration] registry, and from my perspective, thats backward. We should have tools that enable the businesspeople to create the service interface, and the developers consume that.”
Its no longer news, in short, that developers can create services; whats now needed, said Moreland and several other participants, are governance models that result in services conforming to business unit needs and that are capable of addressing those needs across organizational boundaries and technological fault lines.
It might seem as if governance mandates and infrastructure hurdles would impede the grass-roots innovation that propels new approaches such as the SOA into an organization, but thats a false perception, said Reactivity Inc.s Andrew Nash.
“The essence here is that you need to be able to get traction, to prove ROI [return on investment] on small-scale projects,” Nash said. “If you dont have that infrastructure component that buffers you from changes in technology and differences in implementation, then you have to spend a lot more time upfront getting things right the first time.”
Thinking big, paradoxically, has to go hand in hand with starting small.
On the plus side, performance concerns about verbose XML-based Web services conversations are being addressed, according to Systinet Corp.s Roman Stanek. “Customers previously said they couldnt deploy SOA in a real-time environment—they werent ready—but, now, even large real-time installations are being made,” Stanek said.
Another crucial development is that enterprises no longer need to take it on faith that service technologies will someday pay their way.
“We think the biggest step forward in 2004 was customer realization of return on investment in their SOA projects,” said IBMs Cosby. “We work with hundreds of customers around the world, and pretty consistently we see a return on investment for the projects they undertake with this approach.”
The challenge for IBM and other SOA technology providers is to help their customers tame the tiger that theyve already started to ride.
Technology Editor Peter Coffee can be reached at email@example.com.
Ari Bixhorn Lead product manager, Web services, Platform Strategy organization Microsoft, Redmond, Wash.
Scott Cosby Director of WebSphere business integration IBM, Armonk, N.Y.
Ted Farrell Chief architect, application tools division Oracle, Redwood Shores, Calif.
Alexander Krapf President Codemesh, Carlisle, Mass.
Fabrice Lebegue Practice director, BEA Strategic Consulting Services BEA Systems, San Jose, Calif.
Frank Martinez Chairman and chief technology officer Blue Titan Software, San Francisco
Ben Moreland* Director of the application delivery group in the property and casualty division The Hartford Financial Services Group, Hartford, Conn.
Andrew Nash CTO Reactivity, Belmont, Calif.
Roman Stanek Founder and chief strategy officer Systinet, Burlington, Mass.
Gordon Van Huizen CTO Sonic Software, Bedford, Mass.
*Representing customer interests