There’s no denying that consumer technology is evolving quickly and continuously, and that the pace of innovation is accelerating. There’s also no denying that consumers are rushing to embrace the latest and greatest tools as fast as they are introduced. If consumerization is about anything, it’s about change. Rapid change. But this continuous roll-out of new technology has serious implications for the enterprise, which is accustomed to lengthy life-cycles of design, development, deployment, and maintenance.

1. Unisys: IT Leadership in the Age of the Continuous Roll-Out<br />There’s no denying that consumer technology is evolving quickly and continuously, and that the pace of innovation is accelerating. There’s also no denying that consumers are rushing to embrace the latest and greatest tools as fast as they are introduced.<br />If consumerization is about anything, it’s about change. Rapid change. But this continuous roll-out of new technology has serious implications for the enterprise, which is accustomed to lengthy life-cycles of design, development, deployment, and maintenance.<br />Look no further than the speedy adoption of the iPad for the latest evidence of our new world order. The iPad is expected to be in 28 million hands by the end of next year, according to a recent Wall Street analyst report. Market researcher iSuppli now projects 100 million iPads will be in the field by 2012.<br />And Computerworld reports consumers aren’t waiting for IT leaders to decide what, if any, role the iPad will play in their organizations. They’re putting the iPad to work in droves, policy be damned. Let’s not forget that there were no iPads in the field just six months ago.<br />How can IT organizations cope with such real-time (or near real-time) changes in consumer technology, behavior, and requirements? In a word: agility. Take the core concept of agility, born among application developers, and spread it throughout the IT organization.<br />It starts with establishing horizons for changes in the IT environment that are measured in weeks, not years. This realigns IT processes to the notion of continuous improvement. And because continuous roll-out requires continuous investment, ownership of IT agility goes beyond the technical decision makers. The CFO has to be a partner in this change.<br />The traditional corporate process for building new applications requires systems be specified, built, tested, and deployed over several years. Version 2 of an application might arrive a year or more later. The longer an application can remain in use, and the less updating it requires, the better the ROI.<br />But that’s not how pace-setting consumer services like Google, Facebook, Twitter, Amazon, or Orbitz work—or how they measure ROI on IT. In fact, they couldn’t survive if they did. Their applications are constantly improving and constantly being redeployed, often on a two-week cycle. As part of that, their IT infrastructure is often being redesigned and redeployed on the same short cycle. Ditto end-user support.<br />Such IT agility focuses on the notion of perpetual small-scale steps, all of which contribute value as they are taken. Instead of having a massive release with 500 new features that take years to build and test, the team works in two- to three-week sprints, delivering something in that period that improves the application.<br />Unfortunately, agile methodologies are largely the domain of software developers. Can agile make the leap from appdev to infrastructure? What would that look like? Think of enterprise IT as having two different components: the piece that writes applications, and the piece that deploys infrastructure.<br />On the applications side, the key to understanding the agile development strategies used by Google, Facebook, and other Web 2.0 players is that they are not creating licensed software or viewing it, in fact, as software at all. They say they are creating services—services accessed through a single uniform method into an environment they control. This allows them an approach to design, evolution, and testing that’s more effective and efficient than traditional development.<br />Compare this to the typical enterprise application, written as though it is going to be sold to everybody on the planet. It has to be qualified against every conceivable environment. In actuality, though, enterprise applications usually run in one place: the data center. Step one is to stop viewing enterprise applications as software, and starting viewing them as services delivered from an enterprise environment that is uniform and controlled.<br />With this approach in place, you start to go about things in a different way. You start to think about breaking applications down into decoupled components that are, in essence, reusable services. These would be independently evolved, and perhaps even independently deployed. That would allow you to make small, fast, incremental improvements as needed, one after another, over a period of days or weeks. You would be willing to recognize that some of your changes won’t work as conceived, and will need to be replaced, repaired, or abandoned.<br />Google, Facebook, Twitter, and the like aren’t afraid to pull something back and fix it immediately after they deploy it. Look at how quickly Google was able to respond to problems with its Buzz application. Your organization can be this courageous, too. Indeed, agile IT requires a comfort level with disposable components, making mistakes, and fixing problems quickly. Users will be comfortable if you set low expectations for initial builds of a service, and get buy-in by listening to user feedback and evolving the service based on their guidance.<br />For the CIO, the notion of disposability represents a huge shift in strategy that needs to be coordinated across the entire organization. The CFO needs to be involved, because disposability changes the way we financially model our ROI. The old model is to build an application and use it until the wheels fall off. If you’re talking about continuous roll-out, however, then you’re also talking about continuous investment and continuous measurement of ROI against that investment.<br />The agile method has several important financial differences from the traditional development model, which can be understood and applied to IT overall. In the traditional model, the organization has to spend a great deal of money up-front, far in advance of any revenue.<br />In the agile model, revenue can start almost as soon a development begins. Even if the project is intended to reduce costs rather than increase revenue, with agile development, the benefits to the organization start almost immediately after the development effort begins.<br />This shift in how we measure return can (and, I would argue, must) apply as well to the infrastructure side of IT that runs wires and provisions servers and so on. All of the classical decisions on how to run a data center, which were already crumbling under the impact of virtualization, go out the window entirely with consumerization.<br />You can’t have a rigid infrastructure if you need to react in real-time to challenges stemming from consumer technology, or to keep parity with consumer technology, or to service consumers who are self-deploying myriad devices that are intelligent and complex. Further, you can’t have a rigid infrastructure if your development team is agile.<br />The infrastructure has to be as flexible as the applications. It has to be generic. It has to be capable of being reshaped and repurposed instantly. It must be agile. It’s no coincidence that these are the attributes of cloud computing. Our data centers and enterprise IT resources will increasingly need to move to a mix of public and private clouds in order to gain the agility they need.<br />Agility shouldn’t remain the exclusive domain of software developers. Agile can help the IT organization adapt and align continuously to swiftly evolving business needs—of which, it could be argued, the consumerization of IT is a driving force.<br />Imagine if, instead of a terminally long evaluation period for a hot new device such as the iPad, within days the device is brought in, evaluated, characterized, understood, and the first baby steps taken towards integrating, securing, and supporting it. Imagine, as part of this, end-users are given more opportunities to give feedback and help shape how applications, resources, and other IT service or support relate to the device.<br />The truth is, enterprise IT isn’t really rigid and resistant to change. It just seems that way, because our existing processes aren’t agile. They’re old and becoming dated. For existing systems, the old model holds that, if it ain’t broke, don’t fix it, because fixing it might break it. As a result, it takes many an IT organization too long to identify and respond to new requirements.<br />This mentality isn’t compatible with the direction of technology innovation, much of which is being driven by the dynamism of consumer technology. Ultimately, the lesson of consumerization is not about deciding whether to support a given device, service, or app, and when. It’s about making the entire IT organization agile enough to be able to make and execute these decisions with confidence, in real-time.<br />