SOA cannot be bought as a boxed solution. I mean, that's just common knowledge. Ask anyone and they'll tell you: SOA doesn't come in a box.
Well ... anyone except this guy - Enterprise Integration Architect Jack van Hoof, who, frankly, is giving a lot of people pause with his recent blog post pointing out that, in fact, you can buy much of your SOA as a boxed solution and, what's more, it might be a darn good idea to do so.
van Hoof argues that infrastructure vendors want you to think you can't buy SOA as a boxed solution because they want to sell you - duh - infrastructure. Meanwhile, he notes, ERP vendors are selling, essentially, a bunch of SOA-enabling technologies which, put together - out of the box - give you a major jump start on building a service-oriented architecture.
Quoth van Hoof:
The difference between infrastructure-vendors and ERP-vendors like SAP is that the infrastructure-vendors are trying to sell infrastructure to the business and ERP-vendors are selling business solutions to the business. Who do you think will win?
Well, when you put it that way, it does seem like the smart money will be on boxed solutions.
This posting led to an interesting blog exchange between van Hoof and Joe McKendrick, who blogs on SOA at ZDNet.
McKendrick concedes that van Hoof makes some darn good points. He even goes so far as to add to van Hoof's case, noting that many companies are much more comfortable dealing with one huge vendor, rather than cherry-picking SOA-enabling technology from a variety of vendors and building on their own.
But, mainly, McKendrick disagrees with the idea of SOA in a box, contending that buying a bunch of tools and templates doesn't add up to a service-oriented architecture:
Good SOA is ultimately the product of enlightened and savvy management, smart and well-trained people, and competitive drive. And that part will never come in a box.
Point taken. I would argue that you can pretty much say that about any technology that involves more than a CD to install. But, point taken.
But it wasn't enough to change van Hoof's mind, as he explained in a response to McKendrick's response:
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!
Part of the discussion boils down to how you define SOA in a box. I mean, sure, we're never going to get SOA in a box in the same way, say, we get Microsoft Office in a box.
Perhaps it would be helpful to distinguish between a boxed solution - which brings to mind the idea of a plug-and-play solution that really only applies to things like appliances or simple software - and a bundled solution, which is what I think is really meant in this discussion.
Either way, van Hoof's right to take the SOA community to task for dismissing the concept outright. Clearly, you can buy bundled SOA-enabling technology from big-name vendors and buy yourself a few steps up the SOA implementation ladder.
Whether or not you should do so - well, at this point, that's a bit of a philosophical discussion for IT. Should you risk vendor lock-in on something that's supposed to help you avoid vendor lock-in? (Though, as van Hoof points out, most vendors are using open standards, which somewhat negates that concern.)
It's an interesting discussion. But unless you're just interested in SOA as a philosophical treatise, I suggest you follow it up by listening to Dave Linthicum's recent podcast, "When SOAs Fails." It doesn't have a direct connection to the exchange between McKendrick and van Hoof, but I think it will illuminate it for you.
Linthicum specializes in SOA and integration, frequently writing and speaking on SOA. Until very recently, he ran his own SOA consultancy. In this InfoWorld podcast, he shares how he's seeing a number of large enterprises "failing" at SOA and why he thinks this happens.
In all cases, it's not the SOA technology that failed - it's the people, notes Linthicum.
He discusses three general causes of SOA failure, but for our purposes, what's most pertinent is Linthicum's second reason for SOA failure: Lack of Planning, by which he means IT fails to understand the needs of the business.
He's not even talking about some high-level, strategic alignment problem, although that's certainly an issue. He means people buy an SOA-enabling technology - such as an ESB - and it doesn't do what the business needs it to. So, they have to buy another.
If they'd simply defined a business plan and outlined how SOA could impact the business plan long term, they could've avoided the problem in the first place, Linthicum says.
And this may be the best argument against a "boxed" or bundled solution. While a boxed solution may work very well for your company, you won't know until you've done the necessary due diligence.