It's easy to understand why, too. AWS represents a disruptive innovation within IT, and it's important to understand the basis of that disruption to understand what it means for IT going forward.
Clayton Christensen coined the term disruptive innovation in The Innovator's Dilemma . It occurs when a new entrant into an established market significantly changes customer expectations by providing a new alternative to established solutions.
Commentary: Cloud Computing: A Sustaining or Disruptive Innovation?
The most common type of disruptive innovation occurs when a new market entrant figures out how to offer a cheaper, easier-to-use solution-one that is sufficient for many customers in the existing market who are dissatisfied with the current solution's complexity and cost. Christensen characterizes these dissatisfied customers as "overserved" by current solutions. In other words, these customers have simpler needs but can't get them addressed by current vendors, as they deliver highly capable, highly complex, expensive solutions and have no interest in offering (what they view as) cheap, stripped-down products.
Speed, Flexibility of Cloud Gives Developers Edge
Seen in this light, the appeal of AWS for developers is obvious. The traditional method of obtaining infrastructure resources is to request them from an operations group whose primary focus is directed toward production systems. The goal of an operations group regarding its main focus is methodical process control; this ensures that nothing destabilizes the all-important production applications. This process control approach commonly means that changes in infrastructure can take weeks to implement-but in the past that was just fine due to the importance of infrastructure stability.
This focus is well-suited for production applications, but it's highly unsatisfactory for developers who want quick access to resources and the ability to self-manage the process. Clearly, developers have been overserved by the established approaches. The widespread adoption of AWS due to its low-friction, low-cost offering was thus quite predictable.
AWS has brought excitement into the market because it has unleashed an enormous amount of creativity by enabling developer agility. With easy, inexpensive resources available within minutes, developers are free to experiment, help their companies respond to market opportunities and accelerate application delivery. It's no exaggeration to say that AWS has helped make developers much more important within IT, as its low-friction offering has enabled IT to become much more responsive to business needs.
In fact, there's a school of thought, put forward by the small but influential analyst firm RedMonk, that developers now occupy the role of IT kingmakers. This theory holds that the traditional model of IT adoption, which assumes that major decisions emanate from the top, is wrong. Instead, the decisions that appear to come from a CIO are, in fact, dictated by the choices made by people way down in the IT organization-the traditionally denigrated developers. CIOs merely ratify the decisions made by "lowly" developers.
Developers May Be Kings, But They Aren't Ready to Rule
From my experience, there's a lot of validity to this perspective. All the creativity in IT organizations resides in the lower rungs. When those creative developers start putting applications together using a new generation of tools, sooner or later those tools start being officially ratified by the powers-that-be. The role of AWS in this creativity can't be overlooked. Certainly, I'm seeing many IT organizations modify their previous private cloud-only strategies to incorporate AWS into them. This broadening is something I referred to in a previous post as an "and" strategy, in the sense that cloud strategy increasingly involves an internal private cloud and leverage AWS at the same time.
However, if IT organizations apply this developer-centric approach blindly, they're doing themselves a disservice. Let me explain why.
It's irresistible to poke fun at some of the most egregious aspects of today's IT practices-change control committees that only meet once every two weeks; ITIL implementations that place more emphasis on paper trails than actually, you know, getting things done; operations groups that resist application updates in the name of stability, and so on and so forth.
However, the fact is that these functions, if not their manifestation, exist for important reasons. Overlooking them-or outright ignoring them-is not the right solution. Ensuring that updates to production systems are made, and being able to track who makes changes to infrastructure, are enterprise functions are that won't go away just because cloud computing is in the picture.
So why do these areas not receive the proper emphasis in too many of today's developer-forward environments?
One reason is that developers are typically solving an individual problem, usually a single application, and don't focus on the fact that most IT shops support many applications. Therefore, developers use a "simple" solution that works for the application under consideration but is not scalable or applicable across different technology stacks. Identity management is an obvious example of this: using a single-application ID management solution is quicker for getting a single application up and running, but it's disastrous when considered in the context of an enterprise-wide need for user management. Consequently, any application solution that is selected should be useful across a broad spectrum of applications, or it should be so useful that it makes sense to carry a single-application implementation forward.
How-To: Address Cloud Application Lifecycle Challenges
Another reason is that developers are typically focused on developing applications. They're not charged with, nor are they specialists in, operational processes, application and infrastructure security and skill coverage in the organization. Frankly, they shouldn't be. But that doesn't mean those requirements should be ignored, either.
A final-and important-reason is that developers aren't motivated to address those concerns. This doesn't mean personal motivation, though that, too, might be missing. It means that management typically puts measures in place to promote certain behavior, typically speedy application development, quick iteration on features and bugs and business unit satisfaction. The old cliche is "You get what you measure," and measuring developers along these lines guarantees that they'll de-emphasize other, equally important IT elements.
Don't Make Developers Fill Out TPS Reports
Therefore, the rush to venerate developers needs to be balanced by ensuring that other critical functions have a place in these new, low-friction, highly agile applications. But how?
One thing it doesn't mean is insisting that these newly empowered developers come to their senses and start observing the established processes. That ship has sailed-and it sunk. The reason developers have such clout is that they are critical to what the business wants from IT-applications that help the business operate more efficiently, more profitably and with more innovation. Trying to rope developers back into an inefficient process is like the classic TPS report scene from Office Space:
On the other hand, it does mean evaluating the function and contribution of existing processes to determine what their real outcome is (or should be) and ensuring that this is addressed in new cloud-based applications. I've seen some horrendously slipshod security practices in AWS-based applications; the solution to this is to evaluate what functionality an organization's existing security tools and processes implements, and mapping that to AWS to ensure the same functionality is implemented there. Of course, if the organization's current security practices are slipshod-and I've seen plenty of that as well-perhaps a total rethink is required.
Analysis: How the Cloud Changes the CIO-CFO Conversation
It also will inevitably mean reengineering IT processes. Reengineering, quite rightly, has a tarnished reputation, given its misapplication for purposes of cutting costs, building fiefdoms and the like. However, since one aspect of cloud computing is the expectation that automation will replace manual processes, rethinking processes is critical. Otherwise, IT organizations are going to find themselves in a hurry-up-and-wait environment, with widespread customer dissatisfaction.
Within the industry, we've hardly touched on this inescapable implication of cloud computing, but we can expect that IT, driven by the agility available to developers, will be forced to rethink its operational processes end-to-end.
I stand firm on my belief that cloud computing will impose more change on IT than any previous platform shift. We've only just begun to comprehend these changes, but if you think through the implications of the new developer paradigm, you can clearly understand that the industry has only just started to confront its disruptive innovation.
Bernard Golden is the vice president of Enterprise Solutions for enStratus Networks, a cloud management software company. He is the author of three books on virtualization and cloud computing, including "Virtualization for Dummies." Follow Bernard Golden on Twitter @bernardgolden.
Follow everything from CIO.com on Twitter @CIOonline, on Facebook, and on Google +.
Read more about cloud computing in CIO's Cloud Computing Drilldown.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.