Analyst: four SOA consulting red flags that spell trouble

ZapThink's David Linthicum, who nailed the SOA-business alignment problem so well at last week's Open Group's Enterprise Architecture forum, points to another matter creating headaches for organizations: consultants offering expensive "SOA" solutions that end up being far less than promised.

Consultants have a long proud history of overpromising and underdelivering -- why should things be different with SOA?

Of course, the past four decades of IT history (and management in general) are littered with horror stories of overpriced consultants overpromising and underdelivering. Expensive consultants are brought in to try to unravel the screw-ups left by previous teams of expensive consultants, and the beat goes on. Why should things be any different for SOA? Or, perhaps, is SOA adding a new dimension to consulting engagements that consultants can't quite get their arms around?

As SOA has gained steam over the past few years, I've often wondered how systems integrators would be addressing this change in their billable-hour business model. The million-dollar integration projects that took months or years to complete could, in many cases, be reduced to days and weeks with standardized Web services interfaces.

Dave says not to get too worried about consultants' revenue streams, as there are plenty that are now profitably riding the SOA bandwagon. However, organizations risk spending a lot of money and getting little or no SOA in return.

There are four issues Dave is seeing with typical SOA consulting engagements:

1) Consultants -- and the people who hire them -- can't or won't distinguish between SOA and JBOWS (Just a Bunch of Web Services) architectures. (I couldn't agree more, by the way.) "Be wary if consulting organizations point out their experience in the world of SOA by putting up past projects as proof of their experience," Dave writes. "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 a core benefit of SOA. ...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 architecture, agility, and changeability, and not just about service enablement."

2) Many consultants are a bit too chummy with vendors. SOA is about achieving the flexibility of being able to remove or plug in solutions from any vendor or source. However, some consultants may take enterprises down the lock-in path. Be wary of consultants that "implement the same vendors and technology each and every time," Dave says. "...it's still a de facto practice to take an 'ESB-oriented' approach to SOA, no matter what the issues are at hand, or, perhaps an 'app server-oriented' approach, or a 'governance-oriented' approach."

3) Many consultants attempt shortcuts around what should be a predefined SOA process. "SOA implementations are complex distributed systems, and thus complex to plan, design, build, and test. The time spent in planning will later pay huge dividends." However, Dave warns, "many SOA consultants try to use older software development lifecycle (SDLC) and enterprise architecture processes," instead of a true SOA approach "that requires a specific approach that addresses the unique nature of its architectural patterns... 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 approach never has a positive outcome."

4) Many consultants don't thoroughly bake SOA into their clients' business. As Dave puts it, many SOA consultants don't deliver because "there is the lack of understanding about ongoing SOA operations, and links with traditional enterprise architecture." SOA is an ongoing transformational process, not a one-time project. "If your consultant has done his or her job, you should have an architecture where the volatility has been abstracted into a configurable domain. As a result, it's a matter of changing things at the configuration layer to adjust to the changing nature of the business. Therein lies the value of SOA."

In previous posts, I have speculated as to whether the cross-enterprise transformation required to really make SOA work is too far beyond the scope of the IT departments that maintain the relationships with vendors promoting SOA.

Vendors, IT consultants and systems integrators often have working relationships with CIOs and managers on down the IT silo, but not necessarily with other parts of the business. Yet, SOA calls for the deep participation of other business units. Could many of the failings Dave describes with consulting engagements result from engagements that are too IT-centric? Should these consultants be reaching out more to marketing, finance, and operations decision makers?