SOA Demands New Way of Thinking

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.

Next Page: Web services pave the way to SOA success?