In an eBizQ column this week, David Linthicum says that there's a lot of bad consulting on SOA right now, and his fear is the bad advice will result in a bad rap for SOA.
That's always a problem with large projects that require major IT changes, particularly when the concepts are new and there aren't many consultants who have proven, real-world experience. As Linthicum points out, it's not that consultants are deliberately misleading you. It's just that their experience often is limited either to one vendor's solution or to what Linthicum calls JBOWS -- Just a Bunch of Web Services, which they mistakenly believe constitutes SOA.
Linthicum, who is himself an SOA consultant, outlines the warning signs of a misguided consultant in his column. His advice is sound, though I wonder how many companies will even be able to find -- or afford -- the kind of expertise he recommends.
And let's face it: There isn't a lot of consensus about the path to SOA.
As proof, I offer you this week's controversy over whether or not Microsoft "gets" SOA.
In that post, I referenced an Aberdeen whitepaper, and soon received an e-mail from the author of that whitepaper, Perry Donham, the director of Enterprise Applications Research. He wrote that his research revealed confusion over what SOA means and what Microsoft's role in SOA will be:
In my research on SOA over the past year, it's been really interesting to see Microsoft consistently show up as #1 when I ask, "What vendors are you using for SOA and Web services infrastructure?" and, in THE SAME SURVEYS, the #1 response to "Why have you chosen not to build out a SOA infrastructure?" is, "We are a Microsoft shop." Clearly there are some mixed messages and perceptions in the market!
Not long ago, Microsoft published an e-book, "SOA in the Real World," which indicated its developers understand the point of SOA. Here's its working definition from the book: "A loosely-coupled architecture designed to meet the business needs of the organization."
I'm still working through the 196-page document -- what can I say? I had to read the last Harry Potter first. However, I can tell you it's one of the most thorough pieces on SOA I've read to date and it does a great job of explaining SOA's history, services and capabilities. At the same time, I do see hints that the writers may be conscious of Microsoft's plan for its own version of SOA. For instance, the first chapter includes this comment about SOA and open standards:
...the key promise of SOA is to enable agile business processes via open, standards-based interoperability. While these standards are important, we must remember that standards are not architecture and architectures are not implementations. At the end of the day, it is the implementation of a well-designed architecture that will generate business benefits, not the architecture itself.
The argument ignores the fact that, long term, open standards and the architecture can in and of themselves help you generate business benefits, such as reducing costs because you're not locked in with one vendor solution.
Microsoft isn't the only company accused of trying to lock down SOA into just another vendor offering. BMC Software Chief Technology Officer Tom Bishops cautioned IT leaders about this very issue in a recent article published on Australian IT. Bishops is quoted as saying "absolutely there's a risk" of vendor-lock in derailing SOA.
How will they do this? One way would be to lock you into a enterprise service bus that integrates best with the vendor's offering, according to Bishop.
That's a bit frightening, especially considering this news item about SAP's latest version of the SAP NetWeaver Process Integration platform, set to be available next month. With this platform, SAP joins IBM and Oracle in architecting a business process platfrom on top of an ESB -- or, in SAP's case, on ESB capabilities integrated with the platfrom.
I'm not saying that this means these vendors are trying to lock you in because, frankly, I don't know.
I'm just saying, "Buyer Beware."
You're the only one who can make sure your organization's SOA is built on open standards and avoids vendor-- or consultant -- lock in.