Barriers to SOA Adoption

The latest ZapFlash from ZapThink discussed what the real barrier to SOA Adoption is, and Ron points directly at IT as the source. He states:

What ZapThink is finding is that the primary barriers to SOA adoption do not come from business management … but rather from within the IT organization … too many people in the IT organization conceive SOA as a technology concept only, and as such think of SOA as just a set of technologies and infrastructure for exposing, securing, running, and managing Services.

As always, Ron walks the line of controversy with this entry. In reading the article, there’s certainly not much you can argue about as far as some generalizations of IT go. I have seen organizations that are clearly burying SOA within IT, thinking of it as just another application development technology, just as Ron describes it. On some recent work, I recently had created a slide that showed a picture of a bunch of monolithic applications and then breaking apart those monolithic into groups of services. Some may think that this is doing SOA. I’d argue that if that’s the only thing that changes, you’re probably not. In most organizations, there does need to be some fundamental changes in the way IT operates. That being said, what causes that behavior in the first place? Ron made one statement in the above quote, which I intentionally left out at first. Here’s the full text:

What ZapThink is finding is that the primary barriers to SOA adoption do not come from business management, which by and large realize the benefits of an agile, reusable, and loosely coupled architecture (even if they don’t call it that), but rather from within the IT organization …

The italicized text is what really surprised me. Previously, I had a post that said that the organizations that are claiming success with SOA probably had a culture that already had IT and business working together at a higher level. Therefore, I would expect that a business that realizes “the benefits of an agile, reusable, and loosely coupled architecture (even if they don’t call it that)” has a mature Enterprise Architecture practice, with IT having a seat at the strategic planning table. If that’s the case, it would be even more surprising to find a huge gap between IT management and architecture and the actual IT execution. That tells me that some CIO, CTO, or Chief Architect is not doing their job very well.

In organizations where SOA is buried within IT, I would have expected that IT is buried within the organization. So, while all the problems that Ron describes would be accurate, the cultural issues actually ripple beyond IT. Those cultural barriers are a huge barrier, and it’s not just an IT problem, it’s a problem for IT and the business. If the business doesn’t think strategically, which you’d think would be required in order to understand the benefits of an agile, reusable, and loosely coupled architecture, how can can IT be expected to think strategically?

My pragmatic nature tells me that there are surely cases where IT is the problem. There are also cases where the business is the problem. There are cases where both groups are the problem, and there are cases where everything is well. The only real problem is when no one recognizes the problems that exist. It’s always better to deal with your own problems before you begin finger pointing at another organization. IT can be a barrier, and Ron’s article does call out some common problems so it’s definitely worth the read. Truth be told, however, if you’re struggling with your SOA efforts, odds are that there are things that need to be fixed both within the business and IT. Don’t try to boil the ocean, but rather, understand where you’re at, the things you need to work on, and set a realistic approach in motion for doing so.

3 Responses to “Barriers to SOA Adoption”

  • Excellent observations, Todd. Let me take it a step further by observing that it is easier for the business to look enthusiastic about SOA that it is for IT.

    Most business units dependent on IT have heard the following about SOA: a) it’s cheaper; and b) it delivers faster time-to-market. What business wouldn’t love that?!? Since almost every business unit wants both those things, they begin to urge IT to give it a try (or at least check it out).

    For IT, on the other hand, SOA represents first and foremost change. New skills to be learned, new processes to put into place, and reworking a variety of systems already in place. Sure, there *may* be a long term payoff (as they see it), but does the risk outway the reward?

    Add to this that many business units probably don’t understand how much their own IT aquisition processes must change as a result of SOA (and Agile) practices.

    In my opinion, this is why so often business looks like they “get it” well before IT does. This is true for SOA, its true for data center automation technologies (such as Service Level Automation), its true for BPA, etc. If there is a faster/cheaper element to an IT technology, business will tend to want it and IT will tend to scrutinize it before accepting it.

    By the way, I blogged about how the SLA cultural issues parallel the agile computing cultural issues recently. I would say the same goes for SLA and SOA…

  • I agree with both Todd Biske and James Urquhart and would like to add that it is still a easier sell if business buys in than if they don’t. Combined budgets of several BUs can add up to enable the funding of such an undertaking while it is a hard sell for IT if they go it alone.
    A clear methodology, with a transformation roadmap, a time line and a budget with change management as an integral part of the project can make not only the sale but also the project a great success.

  • […] Barriers to SOA Adoption: This was originally posted on May 4, 2007, and was in response to a ZapThink ZapFlash on the subject. […]

Leave a Reply


This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.