First of all, full disclosure. I am a SOA consultant, thus I'm always a bit careful when I talk about other consultants in the business. However, I'm also an industry pundit, and, as such, I think it's time for me to point out a rather disturbing pattern. As larger organizations begin to embark on their SOA projects, there is some misdirecting going on that you should be aware of, which will allow you to make an educated decision as to, not only what you're going to do, but who's going to help you.

At issue is the fact that many people in the planning stages for SOA do not get the proper advice and guidance as to how to proceed, or even what a SOA actually is. Thus, the larger tragedy is that many of these projects will hit the wall, and do so with an impact that will reflect poorly on the notion of SOA, when it's not really a SOA issue at all.

First, be wary if consulting organizations point out their experience in the world of SOA by putting up past projects as proof of their experience. Most, if not all, of these past projects are really JBOWS (just a bunch of Web services) and have no underlying mechanisms to provide agility, which is the core benefit of SOA.

The problem is that many of people looking to hire SOA consultants don't understand the difference between JBOWS and a true SOA, and accept JBOWS as "experience." In reality, it's an indication that the consultants don't understand the core value of SOA, and thus could send you off in all sorts of dangerous and costly directions. So, make sure to hire consultants who understand that SOA is really about configuration, agility, and changeability, and not just about service enablement. It's very easy to expose services; turning those services into solutions is another level of sophistication.

Second, many consultants are a bit too chummy with vendors. Thus, you'll find that they implement the same vendors and technology each and every time. This should be a huge red flag since SOA problem domains are all very different, and technology solutions that work best for the solution are never, ever, from the same vendor, over and over again. However, when you sell hammers, everything looks like a nail. The path of least resistance is what you know, not what you should do.

Those tasked with managing SOA consultants need to state clearly that you are looking for the right solution, not the one they know, or what may be part of an existing partnership. Indeed, consulting organizations with many preexisting vendor partnerships should be quickly overlooked. You need guys and gals in there who are agnostic when it comes to technology, and are willing to leverage the best-of-breed to address your issues.

Third, there needs to be a predefined process. While many SOA consultants try to use older SDLC and enterprise architecture processes, SOAs need a specific approach that addresses the unique nature of these architectural patterns. For instance, there is a traditional focus on data, but the data needs to be properly bound to services. Moreover, those services must be properly bound to processes. Plus you need to keep track of all the interdependencies, and how all of this stuff links to SOA governance, SOA security, and event management and monitoring.

Many consultants attempt to oversimplify the process, rapidly moving through or even foregoing the planning steps. Their main focus is the selection of the technology, or, in some cases, they attempt to force fit a problem with a predetermined technology solution. This can never be good.

Posted by Dave Linthicum on January 2, 2008 04:27 AM