RSSDoes SOA mean "you’re fired" for CIOs?
Of course, no one is really suggesting that, except in that sly way that we bloggers often do to be provocative by saying "Now, I'm not really suggesting…" and then going on to suggest that very thing. It's a good way to put a new angle on old problems, sometimes, and certainly serves to get your attention. It got mine, at any rate, when several other bloggers seized on a poin in this recent Burton Group study examining SOA implementation success rates.
Loraine Lawson wonders if the real key to SOA success is in acquiring a new CIO,
citing several key points in the Burton presentation which noted that often success in SOA projects was only attained with the replacement of the current CIO, and that strong degrees of trust were necessary between IT and the business, as well as business alignment and C-level sponsorship. As she notes, though, most of the other factors also require a strong, business-oriented CIO at the helm; so then, isn't it reasonable to associate SOA success with the CIO overall? Dave Linthicum agrees, but has more nuanced questions as to whether it's the CIO or the organization as a whole at fault.
The factors Burton mention, however, don't really have anything to do with SOA in particular; they are true of any major, paradigm-shifting project. And the reasons that CIOs are perceived as being weak in these areas are not entirely of the CIO's making.
As I have discussed before, the CIO is often in a rather delicate position when it comes to the adoption of new information processing technologies or paradigms. While finding and recommending these technologies is often part of the CIO's purview, and is what often receives the most attention in the press and in the board room, the part of the job most CIO's know really matters is maintaining the security and stability of infrastructure and operations. That's what gets you called on the carpet; that's the underlying motivation behind what you do to keep your job from day to day. Bringing in the new implies risk to that stability.
So there is inherent tension in the role, and it's hard to blame the CIO for putting it there. And it's equally hard to fault them for being conservative in adopting anything new or different. If what is in place is working, the CIO can only lose by changing it. Every CIO knows that credit for successful projects is hard to come by, while blame for failed projects is sure to land on their shoulders. The incentives designed into the system don't encourage the bold undertaking of vast initiatives such as converting an enterprise to a Service Oriented Architecture. Firing the CIO doesn't change that; it simply short-circuits the cycle by allowing the new CIO some freedom to act aggressively while blaming many of the necessarily associated failures on the previous occupant of his office. Firing your CIO every time you want to implement a major new IT paradigm may work in the short-term, but over time it will only be disruptive and inefficient (that is, presuming that you buy my theory that a CIO should be selected not for the technologies that he knows but instead for his adaptability to new technology, rather than Paul Murphy's idea that the CIO should be selected for the technology he is expected to manage).
I don't want to pretend that I think the CIO should be allowed to hide in his office and simply shepherd the organization along without taking risks or evaluating and aggressively pursuing the benefits of new paradigms and technologies; as I've said before, stop talking about it and go do it. But I feel at least that I have some sense of the reasons that less bold CIOs venture into these waters, and I feel as though someone needs to stand up and point out those underlying factors in these situations rather than simply faulting CIOs for doing exactly what they have been conditioned to do. Churn at the executive level is a bad thing. If you can find ways to achieve the same results without all the ancillary disruption that a change of department leadership will also entail, shouldn't you look into that first?
Although there is certainly some correlation in the logic between the Burton findings and the idea that you should fire your CIO to get your SOA project (or any other project) on track, doing so is going about seven steps too far… throwing the baby out with the bathwater, as it were. There is much that can be done to address the factors which commonly retard these large projects without it; indeed, the organization as a whole is likely to benefit more over time by digging into the root causes than simply finding a scapegoat and firing him. There are times when a department-wide shake-up is what is needed to achieve results in these areas, but that's rarely the place to start. And I have never seen an organization with trust problems between IT and other departments, or with alignment problems, or executive-level sponsorship issues, where the entire fault lay with the CIO.
The original article on the Burton presentation, incidentally, is a good read if you are planning or thinking about planning an SOA project in the near future, with much practical and political advice to serve you in good stead through the venture.
