More on SOA Organizational Challenges

I just listened to Anne Thomas Manes’ podcast, “What Does it Take to Succeed With SOA?” that was released on Burton Group’s Inflection Point channel. One of the things that Anne pointed out is that many organizations do not have the right culture, especially on the business side, that promotes the sharing of services. A culture of sharing, collaboration, and trust is required to be successful. She also pointed out that the IT organization frequently mirrors the organization of the business, and if those business organizations don’t share, it makes it very difficult.

I started thinking about the organizational aspects of this. Many people in IT only have awareness of the highest levels of the business organization, and it may not be apparent that there’s a problem. But here are two common patterns that clearly point out the potential problems. First, there’s what I’ll call regionalization. Whether we’re dealing with global entities, or national companies with regional presence, it’s very likely that they have business units aligned along regions rather than along business capabilities. There may be very valid reasons for doing this, but it must also be recognized that they may all be performing the same business functions, only with the expected regional nuances. While it’s oversimplifying the problem, if a company sells widgets in 52 countries, there should be enough commonality to warrant some common services that all of them can leverage. Second, there’s product specialization. I have first-hand experience with an organization that had separate business units (and associated IT staff) for different products that the company offered. There were opportunities for shared services that were recognized within IT, but never made it to reality because of the cultural challenges within the organization. In this case, the cultural challenges were within IT, but it’s just as likely that the same challenges existed on the business side as well.

As Anne rightly points out in the podcast, somehow, we need to present the business value associated with the sharing. In some ways, this shouldn’t be any different than the value that makes companies choose to centralize sales and marketing. One of the big challenges faced within IT, however, it that the associated costs of redundant technology can be a bit harder to quantify. Yes, there are software licensing fees and maintenance agreements, but some of these one time costs are glossed over in deference to the project schedule. While I’ve never personally been involved with a centralization of sales and marketing, I’m guessing that a big part of the equation was an associated reduction in cost attributable to staff reduction, or in a more positive light, getting the cost to revenue ratio looking better by resource re-allocation. If we’re talking information technology, while it’s certainly a possibility, staff reduction doesn’t necessarily come into play, so that associated cost reduction must come from somewhere else, and at least in my experience, IT isn’t very good at quantifying it. So, across the board, our work is cut out for us, but that’s not to say it can’t be done. The one takeaway is to invest heavily in making your pitch. If you don’t have baseline metrics to be able to show the value improvement, whether in increased revenue or decreased cost, take the time to get them together before trying to make your pitch. It needs to be in terms the business can understand and is used to dealing with.

6 Responses to “More on SOA Organizational Challenges”

  • The problem is that IT continues to look at SOA from a technology viewpoint instead of a business viewpoint. If we can sell SOA to the business as the enabler of BPMS tools, then the business can see the value in terms of increased revenue, reduced costs, agility, visibility, and KPIs instead of trying to put a value to reuse of web services. That means nothing to the business. I have been harping about this for a while now and have been presenting my own personal case study where we have pulled this off at my company. The culture problem is secondary to the selling of the technology. Sell first, then deal with the change management.

  • Rob Eamon:

    Mike I tried to comment on your blog but it required me to be a member of ITtoolbox–and I boycotted them long ago.

    So I hope Todd doesn’t mind if I comment here:

    Decent article (Mike’s), except that SOA is not a technology. It’s a way to approach architecture.

    The steps listed are good–but are not unique to SOA. They apply to any enterprise level effort. You described the life of an enterprise architect. Which is good! Because SOA isn’t a distinct level of architecture. It is a modification of architecture levels we already practiced–we just now apply SO principles to them.

    Can you elaborate on how the company was “transformed?” What is the company now doing that is different from before? How does the business look different from before?

  • @Rob
    Todd sorry for using your blog for this but Rob doesn’t do the ITToolbox.

    Rob, you are correct that SOA is an architectural approach, not something you buy. It is something you do. My company is transformed by focusing a new department on Business Process Management. We now evaluate our processes and put more effort into justifying user requirements then we have in the past. The CEO has made business process management one of our 5 core initiatives in our 3 year plan. We see BPM as a huge benefit in the areas of cost savings, improved customer satisfaction, proactive business performance analysis, and many others.

    You are also correct that the steps are not unique to SOA. Actually, they can be used for any large initiative that brings change.

  • Rob Eamon:

    Mike, we agree then on the scope of your ‘recipe for succes’. Cool!

    I’m skeptical about the transformative nature of BPM as a core initiative, particularly since the benefits cited are in the future (benefits that are years off are a red flag for me–I assume those areas that will improve are being measured now?). But since I don’t have detail and these forums aren’t really appropriate for that level of sharing, I’ll leave it at that.

    You might be interested in a Y!discussion in the service-orientated architecture group regarding whether or not processes should be the top level concern vs. services. I think the bulk of the discussion is in the “Re: McKendrick on SOA, EA and BPM” subject. Good food for thought.

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.