Phil Wainewright did a good job in his blog making the case that many IT shops are afraid of SaaS.

"Two thirds of companies are missing out on the potential advantages of a SaaS solution simply because the IT department(s) are scared of trying SaaS,"

Phil confirmed what I've been blogging about for over a year now...the key challenge with the adoption of new and systemic technology is to get beyond the fear and control issues, of the existing IT staff. What's more, this is a SOA as well as a SaaS issue.

"deals are still lost because IT organizations start coming up with objections on the grounds of security, platform, control or some other alleged shortcoming. 'Whatever these objections are, they're really mythical objections. But the fears are real,'"

The problem with both SaaS and SOA (which I think are intermixed at a few levels), is that both technologies are so different from the current IT practices, and will change the fundamental way that IT works. Many in IT found those changes threatening to the way they operate today. The new approaches are scary for some reasons that are typically not real, but seem very real to them. Moreover, they have to give up some control to make the new approach valuable. That’s not something people like to do, generally.

I view the control issue as the underlying problem, and the largest barrier to implementing a SOA. You just can't get "traditional IT" guys to buy into the fact that their systems are going to both expose services, which is tough enough to deal with, but consume them as well? You then hear words of objection (or FUD) such as "security," "control," and "performance," just to name a few.

So, how do you get around these objections? There are a few simple steps:

Make sure that you define the value correctly. Many of those selling SOA, and I'm talking vendors and advocates within the company, make their pitches just assuming that they know "SOA is hip." However, you should assume that they don’t understand the value, and work the business case angle first, than their requirements, and only then the technology approach. They are correct in being weary of "magic bullets."

Anticipate the objections, and understand their validity. While you may see the objections as silly, they are indeed good points to bring up, and you must have good answers for each issue. How are you going to secure this new architecture? How well with it perform? How will they control it?

Not sure we'll ever be able to take the fear out of SOA in the short term. Only execution and success stories will raise the cloud of suspicion. Those are beginning to trickle in, fortunately.

Posted by Dave Linthicum on August 11, 2006 07:10 AM