Six Cautions for IT in the Cloud Planners, or Why Bernard Golden is Wrong

Six Cautions for IT in the Cloud Planners, or Why Bernard Golden is Wrong

CIO Magazine ran a story this week (July 29, 2010) on six predictions on how cloud computing will change IT, taking it from the hodgepodge of today’s options into the smooth waters of a post-cloud world where IT only has one choice.  Even the opening premise leaves me flat, because as we move to a post-cloud world, some other disruption will be on the horizon which will make Bernard Golden’s readers think about the cloud differently than they do today. They will still have doubts and options, just different ones than they do today.

Here is my take and six cautions for cloud computing planners. (You can read Bernard Golden’s analysis here: How Cloud Computing Will Change IT: 6 New Predictions at – I have not used all of the same headings to summarize Golden’s points).

First my take on Golden’s/CIOs predictions:

Every system will be architected with the illusion of infinite capacity. This prediction is probably true, but I’m not sure it matters all that much. As an IT professional, this means one less thing to worry about—a checklist item removed—will the system be able to process the anticipated volume of data? Check. Sure. I want to hit though, on the final sentence in this prediction, which states “the illusion of infinite capacity.” One of the biggest issues with the cloud is the rolling threat of distrust. If something goes wrong, as it has, from systems outages, to power fluctuations to cyber-terror attacks, then trust will erode. If planners buy into “the illusion of infinite capacity” and they find their system’s capacity at threshold (or even worse, unavailable), then they will start sharing cautionary tales. And remember, one near-term uncertainty: has your choice of cloud provider architected their system in a way that doesn’t deliver on this illusion? You probably won’t know the answer to this question until its too late (see caution—You need a backup plan below). When playing with an illusion, you can’t be sure what is real and what isn’t real until reality asserts itself.

The “Internet of Things” arrives. There are several ways that the “Internet of Things” plays out. One is relatively intelligent devices that represent views of “our” data to systems that take action, much as Golden describes with his blood pressure example. But there is also a distributed computing view, where things interact with things on and for their own purposes, as proxies for our needs and priorities. I don’t think we get away from human-centered computing, however, because the devices and the apps represent humans and their needs. If they do not, then we have a bigger issue that has nothing to do with “The Cloud.” The value proposition of technology using resources for no discernible human need is disturbing and challenging by itself, and a good topic for a future post.

The cost of IT components declines precipitously. If scale is everything, reliable components are the foundation. I can imagine increases in costs of switches, routers, disks, and memory as the high-end of the IT market goes from commodity to specialization of hardware. I can imagine a future where premium services employ premium components all around. Why risk my business on some open source component when I can run it on a high-performance platform, one that comes with service level agreements, guarantees, and options for financial retribution? That will cost more, just as high-end recording studio audio equipment costs more than consumer audio equipment. I may be able to get by with my cheap DVD burner and ear-buds, but that isn’t going to cut it at Interscope.

IT Restructures IT. I don’t think IT is going to be compared to cloud pricing in any real way. They are going to do their own analysis, and if the cloud makes sense, they are going to migrate to the cloud. But the cloud, as I discuss in the cautions, isn’t all about total-cost-of-ownership, it is also about risk and performance. One option for IT is to keep doing what they are doing. Many large banks, for instance, have no possible way to move anything except commodity systems to The Cloud. Their internal systems are jumbles of legacy-upon-legacy, including integration from multiple mergers and acquisitions. Same for governments and large NGOs. Sure, IT can outsource things like e-mail, but that isn’t going to cause wholesale restructuring of operations, organizations or systems. And rather than strictly reducing costs, as Golden suggests, perhaps CIOs need to get better at driving the strategy dialog. IT isn’t a commodity, it is also a competitive differentiator. Competitive differentiators aren’t driven by how cheaply you can do the thing the other guy isn’t doing, it’s about keeping the differentiation in play. That often means proprietary (unless you differentiate by being the low-cost provider, but that doesn’t really apply to most organizations).

Platform-as-a-Service. I agree with Platform-as-a-Service. I like the term but I am skeptical about the ability for Cloud providers to create valid offers that meet the neatness of the meme. The question is:  can organizations build differentiated value atop outsourced commodity infrastructure? The answer is yes, but then we must ask if a business model will evolve that will permit such developments. To some degree, that is what outsourcing does, but this is much more about a generic outsourced infrastructure acting as a support for differentiated applications (not, as in the outsourcing model, the infrastructure is turned over to the outsourcer to operate at a lower cost while continuing to seek every imaginable saving in order to remain the outsourcer of choice). This is, of course, what Amazon and Microsoft are offering with their platform services, and it appears that many firms are building interesting solutions atop these platforms. But we’ve already had issues, so as with other items on this list, read the backup plan item in the caution section for how to plan for a dream you wake up from.

Application developer shortage. I don’t think this will be limited to the cloud, it will be more general. And I don’t think it will necessarily be a long-term problem. We are already starting to see more end-user-friendly forms of computing, so business application modifications and some development will be pushed back out to the end-user community, much as it was in the 80s and 90s with tools like dBase III and Lotus 1-2-3. The very idea of an app-dev shortage will mean someone will figure out an innovative way to create technology to compensate for it. Also, we are seeing huge investments in emerging markets now to upgrade their IT-level technical skills, within Universities and complemented by large system houses like Infosys and Tata. As those programs generate more capable talent, this shortage will ease. The shortage prediction also assumes increasing demand. Major economic disturbances or hot wars could reduce the need for IT services, or shift them to a less commercial orientation, where the shortage is on threat deterrent and response, not on processing e-commerce transactions or generating business intelligence from social media marketing campaigns.

My first caution, which I won’t count, is the reiteration of one read here often: don’t predict. Forecast, speculate, reason about, but don’t predict. Golden falls into the trap of making the future sound deterministic, and it is far from that. So when you have the opportunity to predict, resist. Be transparent and tell people where you might be wrong. Mr. Golden, what nagging doubts did you hold back from this article that could have taken one or more of these “predictions” in a different direction?


Six Cautions for Cloud Computing Planner

Technology Lock-In. The cloud is supposed to provide the world of computing with the ultimate in flexibility. Scale, however, is different than flexibility. Being able to increase the capacity of something that isn’t right, will make it even more wrong than leaving it at lower levels of performance. People get more of a not-good thing, which will just be more distracting. Organizations need to be very cautious because too much data is the equivalent of too much code in decades past. Even though the illusion of easy migration may be part of the cloud myth, the reality will be that once you have all of your data in the cloud system of choice, you will find it very hard to migrate. The cloud will create the next level of legacy applications for two reasons: all of the data will be hard to migrate, and you won’t really understand how to map the logic, so any competing system will be an opaque leap rather than a journey down an informed path.

You won’t control updates. When you own your own shop you get to make the call on the mods. Sure, changes to systems are expensive, and many firms increase costs with approval and review teams, but in the end, regardless of the cost of architecture constraints, the company that owns the code makes the call on what changes get implemented. Now if you have been a CIO for a long time, you have seen the laundry lists of ideas, suggestions, and demands from your business constituents. Imagine now that you are a cloud service provider receiving those lists, albeit filtered, from dozens or hundreds of firms. Where does your top idea fall on the list of all of those other requests? And remember, everyone on their list is “big enough to influence them” which makes even the biggest customer voice hard to differentiate among the screaming cacophony of big company CIOs yelling at the top of their lungs. If you want to control your updates, you need to own the code.

Understand the models you are using The “Internet of Things” will generate a lot of data that will pump “information” into devices and other portals. Software will mashup this data and try to make sense of it for you. If you aren’t careful, it will draw incorrect conclusions, mislead and deceive, if only unintentionally. How does something mislead and deceive unintentionally? By offering analysis without all of the information. You may be looking at your organization’s total carbon footprint, and be proud of your achievements. You make work for a company where people travel a lot. Your total carbon footprint for a building may not take into account the carbon footprint of the travel undertaken by its occupants. You think you are doing well, but adding in that data may tell you that the building is located in the wrong place. That is not a question such a system was designed to consider. As a CIO, you need to worry about information and insight.  If your systems are providing a lot of data without insight, then you aren’t providing the value you need to provide.

Don’t Give Up the Architecture Just because you have outsourced to services in The Cloud, that doesn’t mean you can absolve your team of the obligation to understand information and technical architectures. If you ever need to migrate or integrate, you need to understand what and how the service provides its data, its forms, its documents. You also need to evaluate if you think the service has a solid, professional, sustainable, and reliable infrastructure, which means you need to understand their technical architecture and their operational practices. Again, just because you aren’t running it, doesn’t mean the responsibility for success has been outsourced, all it means is you have taken a different path to fulfil a need, you are still on the hook to ensure that it works.

You need a backup plan. Golden’s predictions offer a deterministic set of idealistic pronouncements. As you enter what he calls the “post-cloud” world, all will be good. Get your legacy stuff moved over, then lower costs and let those tech guys at the outsourcer worry about everything. You worry about delivering value through the service. First worry about what happens when one or more of your outsourcing choices, be it a traditional outsourcer or a Cloud service provider, unravels. What happens when the system is down and as the CIO, you’ve been engaged to navigate the customer-service hierarchy of the service provider? Why you? Because you are ultimately on the hook, and you were the one that forgot to negotiate meaningful service-level agreements, retributions, and ramifications. You trusted your partner too much. Don’t trust your partner at all, not during negotiations. Find out everything you can about them and treat them like they are one of your functional leaders. Write performance clauses that are clear and meaningful…and include the ramifications for under- or missed-performance. And have a backup plan. If this doesn’t work out, what do you do? You can only answer that question if you still understand the architecture (see above) and you have a backup plan.

Cloud advocates will tell you are backward. I am not, nor have I ever been, an overly cautious technology adopter. I jump in with both feet. I think security issues are overthought and overwrought. I think people refuse to change because it is just too much work with everything else that needs to get done. I work issues internally with sensitivity to people’s positions and a recognition of the time they can assign to changing. With all of that, I think people like Golden who say, “These are people unable to break free of their past and unable to recognize the rapidly changing world around them” as a way of getting people to change miss the mark, and also miss the opportunity to engage in meaningful dialog. I put Dropbox on my iPad within seconds. Tablet to cloud. If I’m advising a large bank about outsourcing key systems to a cloud provider, I’m saying no initially, and then helping them understand, as I just wrote above, all of the issues about risk and reward together. If the reward doesn’t outweigh the risk, then now is not the time to migrate. Never may be the right time to migrate, not because you don’t want to accept the change, but because the change isn’t a reasonable approach to the problem.

For many businesses, the cloud will give them the ability to do things only big firms could do. For big firms, the burden of commodity IT services could be mostly alleviated and their costs reduced. For heavy, proprietary, differentiated systems, the cloud isn’t ready yet. And it may not be. Don’t let salespeople and executives from cloud providers tell you that you’re strategically backward as a way of forcing your hand. Look at all of the trouble Marty McFly got into in the Back to the Future series until he realized being called “chicken” or “yellow” were just words, and simple words shouldn’t force one to act. The only thing that should force a CIO to move to the cloud is a compelling business case, vetted and proven with the partner, a business case afforded all the due diligence he or she can afford.

Daniel W. Rasmus

Daniel W. Rasmus, Founder and Principal Analyst of Serious Insights, is an internationally recognized speaker on the future of work and education. He is the author of several books, including Listening to the Future and Management by Design.


    comments user

    Robert Liley

    I agree with much of the premise you are putting forth here. Unlike you, I tend to be skeptical when someone presents a solution to everything (remember the /360?). Cloud computing is clearly a vendor-driven initiative and those often worry me. I believe some caution and skepticism is warranted. However, there are a number of typos in your piece (real words, but misapplied) that I find unfortunately distracting. You may want to fix those.

    Robert Liley

      comments user


      Thank you. I just did another edit pass. If you find additional distracting typos, please be specific. Thanks!

    comments user

    James Pennington

    Your antidote of sensible thought to the Golden article on the Cloud is really where people need to be. I can’t agree with you more, from a business and investment perspective.
    Your comment on the platform absolutely rings true. The platform architecture may have some foundation elements that are enterprise and industry neutral, but there are elements that have to be enterprise and industry specific. The enterprise will still have to be responsible for ensuring the platform architecture is an enabler not a limitation or source for information muddle.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.