More 'out-of-the-box' SOA thinking

My recent post on SOA-in-a-box, inspired by the ruminations of Jack van Hoof, stirred up some interesting discussion across the blogosphere. Jack posits that vendors offer many of the components needed for SOA, and those companies that buy and install SOA packages will have a jump on those building their own.

Will enlightened and savvy management result in SOA? 'That would be too easy.'

Jack van Hoof provided more details on his in-the-box post: "When I buy a modern ERP-solution I get a populated SOA infrastructure with it, based on open standards. This open standards based infrastructure can also be used for the governance of external services and processes. It is not unwise to use these integrated out-of-the-box SOA products as a starting point and as enforcers."

I opined that good SOA does not come in a box, since it is ultimately the product of enlightened and savvy management, smart and well-trained people, and competitive drive. Jack agreed, but questioned whether enlightened and savvy management, smart and well-trained people, and competitive drive alone will result in SOA. "That would be too easy. I think it is a prerequisite for SOA but we still must enforce SOA if we are believers... A business wise populated infrastructure with tools and templates, integrated out-of-the-box, and based on open standards will help. An unpopulated infrastructure will also help... but slower. Much, much slower!"

Todd "Out-of-the-Box" Biske, for one, thinks that it's more likely that SOA services will be offered in a box, versus the technology:

"We have no idea what the underlying architecture of SAP is. While it may be the case that SAP or any other large ERP system could constitute the bulk of your infrastructure, that doesn’t mean that you’re suddenly purchasing an SOA. If new business needs come along, it’s now up to your ERP system to provide those capabilities."

Todd disagreed with my view that a goal of SOA is independence from vendor lock-in. "While services can be used to create an abstraction layer from vendor products, I don’t think it needs to be a goal. The factors that influence whether an organization leverages one vendor, lots of vendors, or no vendors really doesn’t come into play at all. What SOA should do is assist you in making appropriate vendor decisions."

Scott Wilson agrees that the while the organizational aspects of SOA won't come in a box, it's entirely feasible that the technical aspects of SOA can come boxed, if you will. "I can't think of any theoretical reason, if you are already basically adapted to a single-vendor implementation, that you couldn't just take off-the-shelf SOA and make it work," he said:

"That's a tenet I often preach to clients in other matters, after all, you are a not a unique and special butterfly, your business processes probably aren't a competitive advantage that you have to mold your information systems around (note: some of them are-but you'd better know the difference before you go mucking around with any of them) and so you can probably go off-the-shelf and save yourself time and money in the process. Custom development is expensive and fraught with risk. And yet I-and others-have been suggesting that it's the only route to viable SOA. Perhaps not."

In a post that preceded this current discussion, Nick Malik warns companies, however, to "beware of SOA in a box." He says that "SOA is not a product. It is an architectural style.... When you buy a product from a vendor (including Microsoft), you are buying more than tools. You are also buying the constraints that drove the assumptions in the tools. Those constraints are important, and usually overlooked."