Analyst: Resist the temptation of well-integrated SOA suites

Can a vendor's offering be too well integrated for its own good? Definitely, when it comes to SOA.

Packaged SOA defeats the very purpose of SOA

Service-oriented architecture is not meant to be "bought" the same way a packaged ERP or CRM system is bought. First, SOA is a philosophy (high level) and methodology (nuts-and-bolts level), and thus can't be captured in a single product. Second, the idea of buying a "packaged" SOA suite runs contrary to the whole notion of SOA, which is supposed to be about interchangeable solutions from any vendor or service creator. Third, buying expensive packaged apps isn't the way to "start small" with SOA, which is the best route for many companies.

Nonetheless, plenty of vendors are "service-enabling" their offerings, and thus offer compelling shortcuts to achieving at least some aspects of SOA.

These packages or suites must be tempting to enterprises, since they offer the chance to greatly accelerate SOA efforts in critical pieces of the infrastructure and application stack.

Judith Hurwitz raises some of the pros and cons of SOA buy versus build in a recent post, and talked about the understandable confusion a CIO was feeling toward moving to SOA via packaged application offerings. Among the questions that need to be considered are the following:

"What is the benefit and danger of implementing a package software offering that has all the industry best practices, business process, and middleware integrated together. What are the opportunities and risks of this approach? Likewise, what are the risks of buying piece parts and integrating them together?"

Judith acknowledges that it must be awfully tempting for CIOs to take "the path of least resistance" by buying into well-integrated software suites from the likes of Oracle, IBM, and SAP. However, this is a temptation that must be resisted, she urges. As also noted at the beginning of this post, Judith says SOA is all about creating flexible, modular environments "where it is easier to add or subtract components based on either a new business initiative or a new innovative technology."

Judith urges IT managers and CIOs to look at packaged software as components in an overall SOA strategy, "rather than the lynchpin of that strategy." Begin with the overall business strategy and an Enterprise Architecture and work from there, versus attempting to extend SOA out of a packaged application environment.

Judith adds that off-the-shelf SOA solutions would make life much easier, but "unless you are buying a commodity, I think the world is still too complicated for packaged SOA."

Indeed, a single-vendor SOA environment is an oxymoron, like jumbo shrimp or clicking "start" to shut down a computer. But many enterprises, if not most, have a comfort zone in dealing with a single master vendor, and many tend to stay the course with their vendors’ SOA roadmaps. Will they be willing to venture outside of these comfort zones? Ultimately, SOA is a transformative process reshaping the entire enterprise, and executives are not likely to want to go it alone without a vendor partner taking the lead. Nevertheless, SOA is an important step on the road to independence.