A CIO Needs to Know How to Find SOA or Find the Door

We interrupt this podcast series for a special announcement. This week I planned to feature a podcast interview with Eugene Ciurana, director of Systems Infrastructure at Leapfrog Enterprises in Emeryville, Calif. I wanted to cover his unique approach to an open-source SOA.

Problem: The audio quality is lacking. My fault. I left a switch on the Zoom H2 in the wrong position, and the audio is over-modulated (read: clipped and muffled). It’s going to take me a little time to fix it, and get it to a state where it’s not unpleasant to listen to. I’m hoping Audacity or Audition have a filter that can do this for me automagically. But if I can’t repair it, I’ll have it transcribed and will present it here as a text-based Q&A.

Meanwhile, all is not lost. I have several other interesting people and SOA projects in the podcast pipeline. But rather than jump right to the next personality in the queue, I wanted to take a moment to address something that popped up in the SOAsphere over the past few weeks.

Back in July, Software AG released the results of a study on the state of SOA governance. Dubbed “Best Practices for SOA Governance,” the report calls out three principal take-aways from the survey (Software AG’s wording, below):

• SOA has “crossed the chasm.”

• Governance plays a key role in creating sustainable, enterprise-wide implementations.

• Users recognize that better governance is needed to institutionalize and automate needed SOA processes and best practices.

Good stuff. But buried in the study, on page 15 of 20, is a remarkable observation; one which I would suggest should be a top-line take-away. From the report:

Another striking fact was the lack of direct CIO involvement within these SOA steering committees.

This is noteworthy on several accounts. First, it may suggest that SOA isn’t viewed as strategically within IT as many have been led to believe. Secondly, it suggests that achieving SOA’s goal of improving IT’s alignment with the business may be difficult as the individual most responsible for this activity, the CIO, is not actively involved with their enterprise’s SOA initiative(s). Finally, this lack of engagement by IT’s “chief salesperson” to the business may explain the challenges that some users experience in making the business case for SOA.

So respondents claim SOA is strategically important to IT, and yet, we see no direct involvement—indeed, no direct leadership—from the CIO. Wouldn’t having the CIO directly involved in a strategically important architecture seem to be a best practice?

Bloggers have also picked up on this conundrum. Joe McKendrick asked who should lead SOA initiatives: architects or analysts? David Linthicum asked if you should fire your CIO in order to get your SOA going (i.e., you need a CIO who gets it).

These blog posts and the Software AG study raise important questions about the role of the CIO in the success of the SOA project. Here are the issues as I see them, along with a forehead-slapping obvious answer.

1. Any major project requires executive management involvement. Any! The involvement must be at the initial startup of the project, as well as ongoing for the lifecycle of the effort. Anything less and the project will likely fail.
2. It’s not about the technology. It’s about the business. If the CIO doesn’t understand that, a superior and less costly alternative to summary justice would be some education that gets them up to speed.

There’s a story from IBM lore about chairman and CEO Thomas Watson Jr. dealing with a mid-level executive who just made a multi-million dollar mistake. The executive in question was told to report to the chairman’s office. Watson asked if the individual knew why he’d been summoned. The manager assumed he was there to be fired. Watson’s response: “Fire you? I just spent millions educating you.”

I don’t know if that story is true, but it certainly sums up the right attitude needed when considering the CIO’s role in relation to SOA. If the CIO is not 100 percent behind the effort, then education is required—because ultimately, SOA should be initiated by the business in concert with technical management.

When education is needed, where do you turn? You could Google “SOA education CIO,” but you’ll have to weed through tech product pitches engineered to work as courseware. A better approach: start with education on the ITIL framework, followed by additional education in Service Strategy. Google “ITIL education” for a kick start (or look at CIO.com’s own ITIL resources).

Service Strategy is at the core of ITIL v3. The Service Strategy book provides guidance on the design, development, and implementation of service management as an organizational capability and a strategic asset.

Part of the responsibility includes defining the market, chartering the service offerings, and understanding things like demand (a.k.a. capacity, availability, costs), financial (what does it cost to plan, develop and support each service versus the value proposition for the customer), and portfolio (the health of the organization is a combination of the services already offered combined with the service in the pipeline; I can usually tell a great deal about the health of the IT organization by looking at the pipeline).

ITIL can (and IMHO should) be the foundation for CIO success—and that includes SOA projects. If the CIO doesn’t see SOA’s value to the business, it’s possible he or she simply doesn’t understand the changing roles of IT and the business. Now, if they are unwilling or unable to grow, then, yes, show them the door. But short of that, show them the text books.