A Manifesto for 21st-Century IT

Numerous blogs have described how Barack Obama’s IT team dramatically outperformed Romney’s team during the 2012 Presidential election. Obama’s team delivered greater quality, better functionality, and superior results for the campaign at significantly lower cost. They did it using cutting-edge tools and techniques such as public cloud computing, DevOps, gameday testing, and open source.

The Obama IT team’s methodology is reminiscent of those used by 21st-century digital properties like Netflix and Facebook. Detractors have dismissed success stories from these companies as only applying to “non-mission-critical entertainment” applications. It would be hard, though, to find a more mission-critical situation than a presidential election. This year’s campaign invested a billion dollars to decide which single person would have an unparalleled influence on the state of the U.S. and the world for the next four years. The election also provided a rare public opportunity to observe a bake-off between current-generation and next-generation approaches to similar IT problems. For these reasons, I think we may look back at the 2012 election as the seismic moment where next-generation IT moved out of its niche and proved itself in a major way.

So what are the essential characteristics of this new kind of IT? Whatever we call it, whether “21st-Century”, “Post-Industrial,” or “Adaptive,” what differentiates it from current IT practice as epitomized by the Romney campaign? I find myself answering this question in terms of not-entirely-binary value choices, along with the lines of the Agile Manifesto. I offer a strawman set of statements, and invite others to help refine it:

1. We value resiliency over stability: since both external environments and internal structures for accomplishing things are complex and ever-shifting, failure is “always around the corner.” It should be treated as just another expected event rather than as an exception

2. We value minimizing Mean Time To Repair (MTTR) over maximizing Mean Time Between Failures (MTBF): the inevitability of failure makes trying to maximize MTBF a futile exercise. Instead, the focus should be on maximizing one’s ability to repair failures. The dynamic nature of the market means that even working applications quickly fail to match shifting requirements. Not only operations but also development becomes an exercise in minimizing MTTR.

3. We value elasticity over planning: Static planning produces solutions that are brittle when forced to change. Elasticity treats unpredictability as the plan.

4. We value lightweight tools over comprehensive solutions: the more global, comprehensive, and tightly structured things are, the harder they are to adapt, change, or repair.

5. We value loose coupling over coordination: the more complicated a situation is, the more overhead is required to coordinate it, and the more fragile a coordination solution becomes. Adaptability favors figuring out how to enable solution components to move independently from each other while coordinating as needed.

6. We value continuous innovation over best practices: the traditional approach to defining, encoding, and propagating best practices can never keep up with constant change. Instead, innovation itself should be a continuous practice.

7. We value diversity over monoculture: forced adherence to single sets of tools and practices reduces opportunities for learning, change, and innovation, while simultaneously slowing selection, implementation, and propagation of those tools and practices.

8. We value open source communities over hierarchical organizations: the open source model offers a mechanism for reconciling apparently conflicting needs for coherency and flexibility.

9. We value unity of purpose over separation and specialization: providing service to customers is the overriding purpose for all employees, regardless of their role or location in an org chart. New functionality, the quality of that functionality, its operability, and its communication to customers are all intrinsically linked, and so should be the people, processes, and tools that deliver them.

Post Comment