State of Change, Chapter 4: 10 Reasons the Cloud Revolution Is Already Different
None of the principal documents that inspired the leaders of the management information systems revolution of the 1970s, or the strategic information systems revolutions of the ‘80s and ‘90s, led off with the word “imagine.” This was to their benefit. “Imagine” is like a hook, and all too often, juicy morsels attached to hooks end up being bait. With the right bait, people can often be led en masse in any direction. One can lead people to believe the ends exist despite the means.
“Imagine if a three-year business transformation plan forged through some bold collaboration between the CFO and the CIO,” writes Oracle SVP for Communications Bob Evans for Forbes last February, “used cloud computing to enable a big corporation to liberate $100 million in IT spending to fund growth-oriented and customer-facing innovation.” Instead of spending 78% of its IT budget on maintaining infrastructure, Evans goes on, the company could shift its cost structure so that, after three years’ time, it’s spending only 65% of the budget on upkeep. “That’s the real magic of the cloud,” he writes.
As history tells us quite plainly, alchemy and magic have never been successful strategic weapons in attaining competitive advantage. When the only way left to achieve that advantage has been magic, it has failed to manifest itself. Cloud dynamics does enable significant cost reduction plans, not by magic but through common sense. Nevertheless, if the main ingredient in a three-year strategic redeployment plan is “some bold collaboration” between IT and finance, or IT and operations, history reveals that significant efforts to achieve such collaboration fail much more often than they succeed, despite every conceivable incentive. Some folks just won’t take the bait.
The whole point of cloud technology, say many of its practitioners, is to enable outlays for IT initiatives to be shifted from capital expenditures to operating expenditures. As some of SISP’s original architects illustrated quite correctly early on, the flow of responsibility in an organization follows the flow of funds. Thus the person ultimately responsible for any initiative is the one in charge of its budget.
So when an organization makes a fundamental shift in the way it funds an initiative or a project or a department, it makes a corresponding shift in its leadership structure. When IT becomes an operational expense, it often becomes an operational department. It answers to the person in charge of OpEx rather than CapEx. Short-term operations and long-term strategies have historically been separately funded. Thus when you put the COO or the CFO in charge of IT... what happens to the CIO? Perhaps you make the CIO report to the CFO. Or, to put it another way, you want to go right back to 1978.
You want to see some magic? How about we press the magic reset button and wipe out 35 years of business evolution?
Why Revolutions Fail
The common reason for the failure of revolutions is that someone or something fails to show up for the party. For the many organizations where SISP failed, and for the countless more where EIP exploded and left careers ravaged, the missing element was consensus. There had been no clear agreement among departments on common goals and objectives. And when similarly sounding goals were cobbled together for different departments (e.g., “business process integration,” “strategic collaboration”), they were not enough to lead them in the same direction or toward the same end. Synergy is no substitute for consensus.
A post-mortem analysis of all of the pre-cloud, would-be revolutions reveals that, in those organizations where they failed to take root or yield positive results, certain common factors were at play:
The key business departments whose goals were expected to align with one another, never actually aligned or, in a few cases, never even made the effort. One reason is so fundamental that it goes beyond cultural differences: Historically, the value of IT to a company has always been perceived as a percentage of capital expenditures. By comparison, the value of business management is calculable using operational expenditures. In large organizations especially, the two may as well be separate currencies, for which a rate of exchange has never been fathomed. SISP had the inspiration that strategic value could be obtained through the systematic improvement of operations and business functions. The problem was, operations and strategy have typically always had separate funding sources. Changing this basic flow of funds is like channeling two arteries into one and expecting blood flow to improve.
Vendors have an interest in sustaining the brands in which their customers have already invested. They won’t sacrifice that interest in order to facilitate a revolution where those brands are the first casualties. Both SISP and EIP pointed the way to a level of integration in the data center which could have rewired existing data warehouses. That’s a huge industry which will not go away just because a new alternative happens to be technically superior. There must be substantial economic superiority as well, and businesses must be convinced and even guaranteed of that superiority before they’re willing to let go of the past.
Businesses looked too often to vendors to provide complete solutions, especially on the advice of experts and analysts who promised those solutions would inevitably arrive. In the case of EIP in particular, they never did, often because those vendors were acquired by the makers of existing platforms (see #2). As Susan Borden of CRM magazine correctly surmised in 1999, businesses will prefer to buy the solution to a business problem, in those situations when it can be purchased outright. A business cannot create competitive advantage value for itself by devoting resources to replicating a solution that already exists elsewhere. When businesses were promised the future in a bright, shiny package and it never arrived... nothing happened.
Platform migrations only happen when the destination platform exists, and its state of completion is way beyond the experimental stage. No one has ever built a platform during the course of actually migrating to that platform, and no one ever will. SISP 2.0 mandated that newly inspired, re-aligned business units should craft new business processes that met everyone’s goals, and would implement those processes in an iterative fashion — literally building the new platform on the fly. Agile makes that same mandate. Virtualization — a technology that enables businesses to build pilot platforms in safe environments during the experimental phase — arrived a few years too late for SISP and EIP.
Technology does not change business by itself. No, it doesn’t. Really. People change the nature of business to accommodate new technology. If technology always had the power to remake the way we work with each new invention that yielded improvements in efficiency and output, we would already have cured cancer, there would be no traffic jams, the petroleum era would have already passed, and the National Security Agency would be a more admired institution than Starfleet.
No single innovation in business networking in the last quarter-century — not a single one — has moved even in the general direction of its goals without sober and concerted consideration being paid to the topic of information security. No network architecture predicated on openness with security bolted on afterward, is applicable to the modern era. Information security is permanently and irrevocably a matter of identity, access control, privacy, compliance, and governance. These are the pillars upon which all modern network architecture rests. If you’re going to base your business architecture around your network architecture, you cannot allow open collaboration among your people to lead to open borders between your network resources. Portal architectures failed mainly because the tools that would make them secure detracted from the ease of use and simplicity of implementation that made them desirable in the first place.
No great business or technological strategy ever manifest itself through a process that could be described as “amalgamation.” Just ask anyone involved with “AOL Time Warner:” Massive organizational structures never coalesce organically. The information systems of the 1980s and ‘90s were designed for the departments they served. You can’t integrate multiple departments’ software into one organism any more than you can stitch together multiple departments’ leaders into one executive. Cohesive, all-encompassing software and processes must be designed that way from the beginning, as a platform that can contain the old data while encapsulating new ideas.
Competitive advantage is about generating unique business value — something a competitor does not have, and may even lose advantage by struggling to imitate. So it does not make sense that a single template for the generation of competitive advantage can work the same way for everybody. Business revolutions are mass-produced, packaged, and sold as magic elixirs, even though what makes any advantage competitive in the first place is the lack of competitors who have it. Viewed in that light, every business revolution that mandates its minions march in lockstep with one another toward the exact same objective, cannot succeed.
Revolution and benefit are orthogonal qualities. No amount of positive benefit will render an initiative suddenly revolutionary, as Michael S. Scott Morton’s “Five Levels” chart indicates, and which practice clearly validates. Revolutions are complex organisms. They achieve their results systematically, even when those results include radical simplification. Easier business processes can come about, and typically do, but their simplicity counteracts their own capacity to affect change. For simplicity to take root, there needs to be an effective conspiracy (there’s no better word for it) to upend the existing complexity and substitute the solution, and there are no simple conspiracies.
Commoditization is a stronger force than any one vendor can possibly control. In every market where commoditization determines the value of a product or service, and that value is not in the best interests of the vendors — even when one vendor enjoys a monopoly — the participants will find new and better ways to make money. Multiple vendors acting in concert can conceivably control the commoditization process to their advantage, but it is an extremely dangerous undertaking — one which, in the case of cloud, is already being challenged by antitrust courts and trade officials. If too many vendors share a market, and they are unwilling to make the effort to control the forces of commoditization so that their margins are sustainable, no matter how lucrative the business may be (case in point: video rental), they will either abandon it or be acquired by others who will abandon it. And there goes your revolution.
“The whole point of cloud technology, say many of its practitioners, is to enable outlays for IT initiatives to be shifted from capital expenditures to operating expenditures. As some of SISP’s original architects illustrated quite correctly early on, the flow of responsibility in an organization follows the flow of funds. Thus the person ultimately responsible for any initiative is the one in charge of its budget.”
The Cloud, Point-Blank
Having isolated and identified these lessons from history, you might think that cloud computing will share the same fate as every would-be revolution that preceded it. It would, if it failed to heed these lessons. As of now, it’s learning pretty quickly. In honor of N. Venkatraman, I’ve aligned the following list of 10 variables in the cloud dynamics revolution, with the 10 lessons learned from the previous IT revolutions:
The most successful cloud platform or service vendors thus far have made simultaneous value propositions to the executive board and to the IT department (and, where applicable, to development teams). They are often not the same appeals whatsoever, but they generate equivalent levels of interest enough to move disparate departments toward the same goal. Cloud dynamics makes strategic sense for individuals concerned with strategy, and practical sense for those concerned with operations. There’s enough strength in the concept that both departments do not have to align, for them to work toward the same objective.
Vendors making tentatively successful transitions to becoming cloud service providers (e.g., Microsoft) are acutely aware that they must carefully move their old platforms and their old brands into the new environment. Those manufacturers with an incentive to maintain their old brands are the ones finding the most success with devising platforms that could conceivably sustain new brands. Once businesses adopt these platforms, then they’re in a better position to begin transitioning their business processes to new ways of working. Unfortunately, the rapid acquisition of cloud services by conglomerates uninterested in perpetuating them, continues today. But this time, there are so many new entrants to cloud computing that it’s financially impossible for all of them to be acquired. So when a big software manufacturer effectively nullifies one upstart through acquisition, it gives incentive to its competition to fill the vacuum.
“The cloud” and cloud services are being presented to organizations as a solution they can purchase wholesale, as essentially plug-and-play. It’s complete, it exists, and the only question is, are you on board or aren’t you? The danger in this line of reasoning lies with ceding total control and responsibility for service integrity to a source outside the firewall. Certain organizations giving private institutions that they don’t own the control and authority to manage resources they do own, may not only be unwise but illegal. For these and other reasons, “the cloud” should never be perceived as a complete, out-of-the-box solution, but rather as a new platform with new rules.
“Beta” does not work well in the cloud. You don’t expect to owe a taxi driver if he crashes on the way to your destination. Cloud services are similarly metered, but customers expect that meter to stop when the service is incomplete or malfunctional. Professional cloud services are predicated on service-level agreements (SLAs) which exactly spell out the customers’ expectations, even when customers fail to read them before signing.
The most innovative cloud service providers recognize that business processes are changed by people. Thus to help distinguish their services and gain competitive advantage, they offer people to help customers understand and implement changes in ways that uniquely benefit them, often as consultants, sometimes (ironically) on-premise.
Information security remains an enormous issue with respect to cloud services. At the root of consumers’ distrust of the whole cloud idea is the notion that it places their privacy and security in someone else’s hands. (Never mind that security wasn’t exactly pristine when it was in their own hands.) The final solutions to the problems of cloud network security may theoretically exist today, though their implementation in the real world remains years away. Nevertheless, in a sharp split with the past, cloud architecture is being driven by engineers who accept the responsibility for security, rather than by managers who assume some bolt-on gadget made by someone else will provide it later.
The most successful cloud technologies devised thus far were created from the ground up, as novel and untried solutions for extremely serious problems with existing network architecture — solutions that are downwardly compatible with absolutely nothing. “Big data” systems such as Hadoop, which incorporate on- and off-premise storage devices regardless of their configuration or location, were literally designed in a state of panic. That they work as spectacularly well as they do is testament to the fact that truly transitional technologies are never mash-ups.
The single biggest complaint that organizations have about the whole subject of cloud dynamics is that there is no single, all-encompassing definition for the thing. The fact that I’m actually trying on my own to coin a phrase here — “cloud dynamics” — that may apply to all the loosely attributed definitions there are today, reveals that there is no single “cloud” that applies to everyone. To be honest, there is no single “cloud,” period. Certainly there are numerous attempts to mass-produce a business concept of cloud, but the inordinate number of those attempts by itself lends to the confusion. In an ironic way, the confusion itself is a good sign. For literally the first time in the history of the IT industry, the way forward is not a clear-cut path, and that fact is forcing us to take our blinders off, put aside our euphemisms, aphorisms, and platitudes, and think. Cloud is not so much the light at the end of the tunnel as it is the fork in the road. The only way forward, whichever way that may be, is for organizations to stop postponing the inevitable decision about how their business will be structured for this century.
One of the major potential benefits of cloud dynamics is the institution of a much simpler, easier-to-manage, cost structure for computing resources. The existence of that cost structure is an effective safety net for any organization willing to conspire to reroute the structure of its budgeting and spending authority. A CIO suddenly finding herself in charge of day-to-day IT operations, rather than information strategies, will be comforted by the pragmatic, elementary nature of utility pricing models. That said, the mastery of those models may not be the most valuable skill on the CIO’s résumé. What has yet to be determined is how a strategy leader whose role has been shifted to that of an operational leader, will be able to craft effective strategies for the organization, especially if she is now to report to someone who has no responsibility or even interest in strategies.
Commoditization remains the wild card. Part of the self-provisioning concept is that services are divided into discrete, metered units. Wherever a competitive market develops around these services (e.g., storage, identity, infrastructure, runtime platforms, middleware, data integration), instantaneously those services become commodities. Vendors can still find unique ways to craft competitive advantages and command premiums, but even the institution of premiums serves to cement the foundation of regular pricing. Where various providers of the same regular service coalesce upon a price, they must be extremely careful to avoid the appearance of that coalescence becoming a coalition or a conspiracy. The way service providers choose to address this problem will determine whether the cloud concept succeeds or goes down in a portal of flames.
In addition to these ten distinguishing factors between cloud dynamics and all the attempts at IT revolutions that came before, there is one more factor that deserves special discussion. It’s something I call the nuclear option, and it’s a big red button that the executives of companies that implemented SISP and EIP and portal never had. Its power alone may be irresistible, and it’s the subject of the next article in this series.
