Getting inside a CIO's head

I was disappointed to see that our nation's first chief information officer, Vivek Kundra, is having some major distractions, with the FBI raiding the District of Columbia CIO's office he was overseeing. According to this report from ZDNet's Sam Diaz, Kundra has not been linked to the raid, which stemmed from a bribery investigation involving employees and technology vendors. (Sounds like there could be some troubles for some vendors too.)

Kundra has some great ideas, and hopefully, he'll be able to get back to work on them -- he said in a recent interview that he wants to move the government to adopt more consumer technology, as well as cloud computing, which he sees as an alternative to the “big IT” culture of federal agencies. Kundra also wants to support government operations with social networking approaches, modeled along the lines of wikis and Facebook.

Of course, managing the ethics and money being moved around between projects and vendors is only one of the headaches of the job of CIO. The job also calls for a high level of delicate political skills, since the business needs to be on board with major technology initiatives, and there are often major fiefdoms to overcome.

The CIO is busy and consumed then, and doesn't have a lot of time to fuss with uncertainties. They need solutions carefully considered and laid out for their consideration.

ZDNet colleague Michael Krigsman points to some guidelines on approaching CIOs to get ideas and solutions sold. Mike's post is directed at vendors seeking to pitch CIOs, but there are valuable lessons for managers within organizations who seek support for projects. The best way to pitch a new project or solution to a CIO is to present case studies that include the business goal, stakeholders involved, overview of client process and/or timeline, technology architectural approach, options that were evaluated, technology deployed, and business outcomes. Also, add a "lessons learned" aspect to any proposal, that answers questions such as: "If you re-did the project, what would you do differently?"

One of the things we often pitch at this blogsite is the involvement of the CIO and business in service oriented architecture. However, not everyone thinks the CIO should be involved in the intricacies of SOA. Ted Neward, for one, wonders if C-level types should be spending a lot of their time worrying about SOA at all. "It’s gotten to the point where CTOs and CEOs are talking about SOA as a general strategy for running their entire IT department," he says.

"I always thought CTOs and CEOs had something… I don’t know… *better* to do. For some reason, I always thought it was the job of the architect to think about these things, rather than let the CTO or CEO sit around and think about how their various software systems should be designed...  When a CTO starts thinking about objects, or services, or other low-level activities, she may as well be conducting code reviews, too."

Hmm.. I can understand why CEOs should avoid getting wrapped up in SOA efforts -- it's their job to delegate those kinds or roles, and worry more about interfacing with customers and markets and CNBC. But for the CTO (we'll presume Ned means CIOs as well), service orienting the business ultimately evoles into a major transformative process as it picks up steam and critical mass. CTOs and CIOs shouldn't be worrying about Java versus .NET, or REST versus SOAP. But the ability of the business to service orient its technology and architecture may be the most important part of their jobs.