Part 3: The four hallmarks of an effective CIO: Agility

Two weeks ago here on Planet Mainframe I introduced the idea that a CIO must excel in 4 areas: Alignment, Architecture, Agility and Ability, and we looked closely at Alignment. Last week we had a close look at what Architecture in IT is all about. This week we have a closer look at the counterbalancing force to Architecture: Agility.

3. Agility

Agility is the set of processes and tools employed by IT to reduce unnecessary complexity and time to market. It’s a relatively new guiding principle for IT, and it’s a necessary counterbalance to all the forces that make traditional IT slow and cumbersome. Be aware that Agility without Architecture is Chaos (but Architecture without Agility is Bureaucracy).

Traditional IT processes evolved from engineering project management disciplines. Engineers had developed sound principles over hundreds—if not thousands—of years, and it was a good place to start when IT was young and the pace of change was slow. Building an oil refinery or a bridge takes time, involves many physical processes, and has an “all-or-nothing” focus (half a bridge is of little use). When you’re building a giant ERP system that controls inventory, orders and manufacturing, it’s a lot like building that oil refinery (and half a system is of little value).

Today, IT is less about building huge monolithic systems (sometimes called ‘Systems of Record”) and more about building systems that reach out and touch employees, customers, partners (“Systems of Engagement”). Unlike, say, an order-entry system, these systems often have value even if they’re not 100% complete and 100% perfect. This evolution has come as a big shock to many long-time IT technicians. They have been used to delivering feature-complete, fully debugged systems for so long that their engineering minds might have trouble adjusting to this changed world. Even more importantly, the processes and tools used to deliver those systems were designed and tuned over the years to work a certain way: slowly and carefully.

An effective CIO understands that different applications have different cost/time/feature/quality trade-offs and creates processes and standards that allow these trade-offs to be exploited. This will seem like heresy to IT traditionalists: we have to follow the architecture, fill out the forms, gather all the signatures, perform exhaustive design studies, get the next round of approvals, and only then start coding. This “Waterfall” methodology produces high quality outcomes, but it takes a long time and locks the project into requirements that are—deliberately—hard to modify as the world outside the project changes.

Whereas traditional Waterfall methods assume delivery will take months or years, Agile methods allow large projects to be broken down into small deliverables, each of which can be designed/coded/approved in days or (at most) weeks. This allows mid-course corrections to be made and for the final product to change quite a bit from inception to completion. (In fact, Agile projects don’t necessarily have a “completion.” Some never end, as delivery and maintenance blend together. And others just sort of taper off, as some initially required features are deemed unnecessary.)

The IT community has been working with Agile methodologies for the last 15 years or so, and there are many specific Agile techniques that have worked successfully for many classes of projects. This is not the time to discuss specific techniques. What’s important is that an effective CIO has Agile tools in the toolbox and an appreciation for when and how to use them.

We made a big deal about Architecture just a moment ago, so let’s discuss the seeming contradiction between Architecture (do it according to the rules) and Agility (do it now, somehow). Effective IT needs a measure of both. Architecture without Agility is stagnation; Agility without Architecture is Chaos.

One more thing: there’s a lot of talk in consulting circles lately about “Bimodal IT.” This is the notion that IT needs one “speed” (slow) to maintain the Systems of Record and another speed (fast) to maintain Systems of Engagement. They got the idea correct, but not its execution. Just like a simultaneously two-speed bicycle would be hard to ride, limiting IT to fast and slow speeds fails to exploit the trade-offs among cost, time, features and quality.

Getting it right takes a certain amount of IT Ability, which we’ll examine next week on Planet Mainframe.

Part I: The four hallmarks of an effective CIO

Part 2: The four hallmarks of an effective CIO: Architecture