How to handle SOA vendor consolidation

The SOA concept -- developing a software architecture based on service components that can be mixed and matched as needed to reduce development time and increase application deployment flexibility -- is only a few years old, but the providers of SOA-supporting infrastructure are fast consolidating. Oracle captured the headlines with its acquisition of BEA Systems this spring, and Progress Software recently bought Iona Technologies.

That means the choices for infrastructure providers -- from enterprise service buses (ESBs) to shared code repositories -- is shrinking just as more companies are exploring SOA. A few vendors such as IBM and Oracle now offer the convenience of a soup-to-nuts SOA platform, but at the risk of locking in their customers to a proprietary stack or selling them more than they need as part of a suite or package.

For example, Delaware Electric had to fend off IBM's attempt to sell more than the utility needed, says CFO Garry Cripps. "IBM behaved like most vendors I deal with: They tried to up-sell me for the highest horsepower whether I needed it or not," he says. (Cripps is pleased with the IBM WebSphere Process Server he did buy to manage SOA services.)

Vendors such as Hewlett-Packard, Itko, Software AG, Tibco, and WSO2 that offer specific SOA platform components will continue to exist. But some of them fear that because their customers increasingly are using platform offerings from the large vendors, they could be displaced by the larger vendor, either because it offers a similar component or doesn't integrate well with the smaller vendor's tool.

For example, Software AG says that IBM's claim of integration with and accommodation of other vendors' products is misleading, putting it at a disadvantage.

Not as simple as "soup to nuts" versus "best of breed"

But the choices in the SOA market are not so clearly between proprietary but integrated stacks and "best of breed," but rather nonintegrated components, says Randy Heffner, a Forrester Research analyst. That's because by its nature, SOA uses standard interfaces such as SOAP, WSDL, BPEL, and XML to connect services to each other. Thus, even a large vendor like IBM is forced to compete with a startup like WSO2.

In a true SOA approach, individual services can run over proprietary infrastructure, but the interfaces among them typically adhere to the established standards. That reduces lock-in risk to the infrastructure, not the applications running over them, Heffner says -- but only if IT avoids vendors' proprietary extensions to those standards. "There are a lot of extensions beyond the specifications," he notes.

Also, because most SOA efforts seek to reuse existing applications wherever possible, IT will have to do custom coordination no matter how integrated the SOA platform. That helps blunt the "one provider" argument.

"With SOA, there's a lot of legacy products, so you have to write your own pieces," said Brad Svee, manager of IT development at Concur Technologies, a provider of expense reporting and travel management services.

Enterprise architects assembling an SOA have three strategies, according to a recent Forrester study by Heffner. These include a single-vendor, "best of breed," or specialized approach (using a proprietary framework developed for or by the company).

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email Computerworld
• Follow Computerworld on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark