Thinking Out Cloud

Why (and What) Every Business Exec Needs to Know About Cloud Computing

A couple of weeks ago Harvard Business School professor Andrew McAfee posted the following question on Twitter:

@amcafee Is cloud computing something that every exec (even NON-IT ones) needs to know about? Should I cover it in my MBA course this semester?

My answer to Professor McAfee is that it is, because cloud computing is as much a business phenomenon as it is a technological one. Most industries will be affected by cloud computing as it catches on and is embraced by the mainstream.

I classify the importance of cloud computing to business in two broad categories: operational and strategic. But before I jump into details, a quick general note. Increasingly, industries are driven by IT. From manufacturing to travel & shipping to telecommunications to financial services, growing aspects of the business run on computers and software. So much so, that some industries, such as capital markets trading, are primarily technology businesses. With that in mind, if we accept that cloud computing is a "once in a decade" kind of innovation, then surely it will have a significant impact on a multitude of businesses. An obvious previous example of this is the Internet.

But still, the question remains if cloud computing should be primarily the concern of the IT execs. After all, much of it is about deep technical issues (or so it is perceived) and many of the business execs lack the knowledge of those details to make a contribution to the decision-making -- or so some have suggested.

The Operational Importance of Cloud Computing

The operational importance of cloud computing is for the most part a tactical benefit, but it can evolve into a strategic one. Cloud computing -- and I include in this IaaS, PaaS and SaaS -- acts as an efficiency driver. It reduces costs and increases agility through the combined benefits of outsourcing and on-demand pay-per-use as opposed to over-utilization and a large upfront investment. It also gives a scalability guarantee: quick access to additional resources in case additional capacity is needed to handle success.

The implications of some of the decisions about cloud computing are so substantial to the business that every executive in the business needs to understand the key high-level considerations and the possible consequences. This is especially true because in some cases the IT execs may have various vested interests in the decision and are not basing it purely on what's best for the firm. For example, because cloud computing is an act of outsourcing, this may affect IT jobs in the company. An opposite example might be that the IT execs want to adopt cloud computing because it removes "headaches" from them.

In a presentation I have been giving to executives at different companies I discuss at length the various issues that business execs need to understand as they discuss cloud strategy with their IT counterparts. They include assessing whether the proposed cloud-sourced functions are core to the business or not, whether they create a competitive advantage, vendor lock-in and strategies to minimize it, and how the company can get the most bang for the buck (ROI analysis). I also discuss what elements of a company's business should be "cloudsourced". Does it make sense to build an internal cloud or a hybrid?

The Strategic Importance of Cloud Computing

But perhaps far more interesting is how cloud computing can be a transformational technology that drives innovation and creates a breakthrough strategy. 

Consider the case of Amazon and their rationale for coming out with Amazon Web Services. As CEO Jeff Bezos explains in an interview with Om Malik, Amazon needed to develop the various services in AWS for their own internal purposes -- specifically, to create more efficiency in the interactions between network engineering and application development groups. They quickly realized, however, that they have come up with a true innovation that would benefit external users as well.

Amazon, by the way, has a history of looking at their business in this fashion -- trying to identify where their core strengths are in a way that may not be obvious to external observers. Years ago, they were one of the first companies on the Internet to open up their platform for other retailers. Amazon understood that one of its distinct competencies is running an extremely efficient infrastructure for online retailing -- payment processing, warehousing, supply chain management, personalization and recommendation engines and so on. 

Like Amazon, many companies have developed distinct competencies that go deeper than the products and services they sell. For example, I talked to a Wall Street investment bank that developed what they believe is a very powerful platform for Value-at-Risk (VaR) analysis and other intense calculations. It provides a full infrastructure which allows plugging in various models and algorithms. The bank is already providing the platform as a service to hedge funds and insurance companies, but this service is almost an afterthought and is extremely ineffcient. The bank is now seriously onsidering opening it up as a full-fledged Platform-as-a-Service to which companies can sign up online and use a self-service approach to run their models on it.

I've presented these concepts at large companies in a range of insudtries, and invariably a flow of ideas comes streaming on what aspects of the company's internal operations can they open up as a service.

Another classic example is Salesforce.com, which opened up the underlying platform on which they built their salesforce automation (SFA) and CRM application for anyone to build applications with. Salesforce.com goes even further. It allows these third-party applications to access customer data already entered into the SFA application (with the customer's permission of course).

Another interesting example is Intuit, which announced last year that it is opening its Quickbase PaaS for 3rd parties to develop applications on. But here's the twist: there will be easy integration to customers' existing Quickbooks data (and presumably to data on TurboTax and Quicken). Intuit realized that it has distinct competencies in 1) building an extremely secure, reliable and scalable application platform, and 2) possessing vast amounts of financial data of American businesses, households and taxpayers. And it wants to leverage these assets -- perhaps opening up a whole new high growth business.

Similarly, many businesses should take a long, hard look at their distinctive competencies (note that this is different than "core competency", but I will dive into that another time). This might be on all levels of cloud computing, for example:

Infrastructure-as-a-Service: A healthcare company might provide infrastructure that is HIPPA-compliant for use by other businesses in the industry.

Platform-as-a-Service: A logistics and supply chain management company such as FedEx might open up its platform for companies to build customized versions of applications that target specific industry or niche needs.

Software-as-a-Service: Many companies that today provide different services via software that is used in-house only, can expose that software to the end consumer. We've seen many examples of this on the Web for years. A classic one would be the travel industry, which opened web versions of reservation and booking software that was once exclusively accessible to the travel companies themselves or travel agencies.

I've been working with a number of companies on ways to uncover and develop such ideas by looking at the principles underlying cloud computing and combining them with innovation models such as those found in Blue Ocean Strategy and Seeing What's Next.

For example, I ask the question "Are there areas in your business that were traditionally considered too complex for end customers to access in a self-service model?" There always are and it often turns out that with today's technology developments many of the assumptions no longer hold true.

But more importantly, it often turns out that cloud computing enables targeting new kinds of customers and opening new markets, or what Clayton Christensen calls in Seeing What's Next nonconsumers, overshot customers and undershot customers.

In conclusion, cloud computing is a game-changer, both technologically and business-wise and wise business execs should understand the forces that will impact their industry. So Professor McAfee, please teach your students about Cloud Computing.

Open APIs and Cloud Computing Standards

My previous post, Beware Premature Elaboration, discussed some of the issues around cloud computing standards. If you want to hear more about the topic, and especially GoGrid, one of the most innovative cloud providers in the market, check out the Overcast Show #6. My co-host, James Urquhart, and I interview Randy Bias and Michael Sheehan of GoGrid.

We discuss many topics (see Show Notes below), but I think the most interesting is the fact that GoGrid recently open sourced their API specification. As I said before, this is the right way to go. We have a number of open source APIs, including GoGrid, EUCALYPTUS, Enomaly and others, and now the market will start determining the winner.

The GoGrid case is particularly interesting because of two main reasons. The first is that it is a proven API that is up and running in production and reflects a lot of experience from the trenches. The second is they are making a proactive attempt to reach out to other cloud providers and other members in the ecosystem to support their API, as Randy discusses in the podcast.

Listen to the podcast here.

Here are the full Show Notes:

Show Notes:

After a long hiatus we are back with the Overcast podcast. In Show #6 we have a discussion with Randy Bias and Michael Sheehan of GoGrid. Some of the topics we cover include:

• The distinction that Randy and Michael have made in their blog posts between a Cloudcenter and Infrastructure Web Services, and the different approach GoGris is taking to cloud computing compared to Amazon Web Services
• The role of Platform-as-a-Service players, such as Google App Engine, and a glimpse into some of GoGrid's thoughts on opening up their infrastructure for other to offer a PaaS on top of it 
• Cloud computing standards -- do we need them now and it what is the correct approach for achieving them? 
• GoGrid's recent open sourcing of their APIand their efforts to work with other cloud providers and related vendors and projects (such as Flexiscale, RightScale andEucalyptus) to rally around the GoGrid API
• The role of projects such as Puppet andChef in cloud computing, and GoGrid's plans for these technologies 
• GoGrid's Cloud Connect offering - a hybrid model for dedicated and cloud-style hosting  
• GoGrid's storage offering 
• and more... 

Beware Premature Elaboration (of Cloud Standards)

There is an ongoing discussion about the need for creating standards in the cloud computing space, including the establishment of the Cloud Computing Interoperability Forum (CCIF) of which I'm a member. 

Motivation for Creating Cloud Computing Standards

The drivers for establishing industry standards for cloud computing are quite straightforward and similar to the same drivers in other areas of IT and other industries. From a user/customer perspective standards (at least theoretically) eliminate vendor lock-in. If all cloud providers use the same provisioning API, for example, customers don't need to bet and commit themselves to a particular provider. They will be able to switch with little time, cost or effort and use any other provider's provisioning API.

From a vendor point-of-view there is also motivation for standardization. Given the customer lock-in concern, the approach many companies will take is stay on the sidelines or only dip their toes in the cloud computing waters, and not dive all-in. In other words, lack of standards is an adoption barrier.

Furthermore, the absence of interoperability across the entire cloud computing ecosystem -- not just cloud providers, but also tools that add value to them such as management and monitoring -- reduces the overall value of cloud computing.

Consider the case of the shipping container as described in the excellent book The Box: How the Shipping Container Made the World Smaller and the World Economy Bigger. Before standardized shipping containers, sending a shipment from, say, Kansas City to Tokyo was extremely expensive and ineffcient. There was no way to send the shipment in one container as a whole. Trains used containers of certain shapes and sizes, trucks used different ones and ships used different ones. In fact American ships and trains used different containers from European and Asian ones. Sometimes, even within the U.S. or Europe, different kinds of containers were used. That also meant they were extremely difficult to stack and secure, and the goods being transported had to be moved multiple times to different containers. The effect on international (or even cross-region) shipments was chilling. Furthermore, many companies in the shipping business had to maintain infrastructure and equipment to serve multiple proprietary container specs.

By standardizing on uniform container specifications, the industry removed the barriers to long-distance shipping and greatly increased the demand for it, while reducing their own costs. A boon to everyone involved.

Similarly, we can assume that if there were standards across the board for cloud computing, the uncertainty and fear of vendor lock-in would be greatly reduced and the ecosystem as a whole will become more beneficial to customers, freeing presumably pent-up demand. In Gang up now before the *aas cloud gets you, Simon Wardley makes a powerful argument for consumers to push cloud vendors towards interoperability and portability, and what he calls "open source standards" (his presentation in the link above is a must watch). 

The Case Against Standards

As almost everything else in life, standards too have a downside. Standards stifle innovation - by definition. It's true that good standards should only dictate what the product/technology needs to do, and not how. In other words, and specifically in the software world, a standard should only dictate the API sematics, and not the underlying implementation.

The problem is that in an emerging, dynamic area, such as cloud computing, the "what" is still a work in progress. We are only at the very early stages of understanding what the use cases are for cloud computing, what exact functionalty is needed by various constituencies, and what are the missing pieces. Trying to codify this highly fluid situation in a set of standards is a huge mistake.

Standards are only appropriate when an industry (or class of technology) has reached a medium level of maturity (and then standards will carry it to a high level of maturity). This is why, despite the resistance in the "cloudosphere", Gartner is probably right with their prediction that cloud computing will only reach "mainsream critical mass and commoditzation" between 2012 and 2015.

The Optimal Way to Standardize

There is another reason to avoid forcing a formal standardization process in cloud computing. It's simply not the ideal way to create a standard. There are two kinds of standards: de jure and de facto. Both phrases are from the Latin, the former meaning "by law" and the latter "by fact" --or in other words, there are official standards and standards that were not defined formally, yet have become standards in daily practice.

Formal standards are the ultimate form of "design by committee." They require compromises and involve politics and ulterior motives. They also tend to be too slow and bureaucratic. They are not the optimal way to come up with the best solution the market needs for a particular problems. The marketplace is the best tool for that (and when I say "marketplace" I also include free open source). As a particular class of technology matures, it is actually good to have a number of competing approaches and let the users vote with their feet for the one that best suits their needs.

A good example of this is what happened in Java. Although I'm sure some will argue with this analysis, essentially the Java Community Process (JCP), the official standards body of the Java platform and language was slow to adopt new programming practices and adapt to developer needs, so alternative, unofficial frameworks evolved. One of them, the Spring Framework, came out as an open source framework in 2004, and was so rapidly adopted by the community that by 2008 it was alreaddy considered by many to be a de facto standard.

Another problematic standard was WS*. Where the standards body attempted to keep up with the rapid developments in web services technology -- an impossible tasks, and ended up with numerous half-baked standards, many of which enjoyed little if any adoption in the marketplace.

The evolutionary approach to standards is even more evident in the Ruby on Rails community, which has no standards body or dominant vendor. Multiple Ruby implementations (e.g., MRI, Rubinius, JRuby), multiple frameworks (e.g., Rails, Merb, Sinatra), and multiple app servers (e.g., Mongrel, Thin, ebb) are all competing to become the de facto standard, and we will soon see which ones emerge victorious (and if it makes sense to have multiple approaches for different needs). Already there is some convergence with the merger of Rails and Merb.

In summary, the correct approach to developing standards is to first let the marketplace converge on de facto standards. A formal standards body can step in at a later stage to tie up loose ends and manage a more stable process.

The State of Standards in the Cloud

It's immportant to first make the destinction between cloud-specific standards and standards that are related but are moving on their own trajectory regardless of the developments in cloud computing. These include programming languages, operating systems, many security issues, web services and databases, to name but a few.

We then need to ask ourselves, what then, are issues unique to cloud computing that need to be addressed. The blogosphere has been abuzz lately with the discussion about exactly that. In order to understand what standards are required, we first need to understand what are the techologies that are involved in cloud computing and how they relate to each other. In other words, a taxonomy and ontology for cloud computing. In the Wisdom of Clouds, James Urquhart discusses The need for a standard cloud taxonomy. And inspired by John WIllis's Unified Ontology of Cloud Computing, Chris Hoff developed an excellent diagram of a Cloud Computing Taxonomy & Ontology. These are examples of the correct first step to standards at this point time, which is merely trying to put everyone on the same page in terms of terminology.

Reuven Cohen, who initiated the Cloud Computing Interoperability Forum writes about the need for a Semantic Cloud Abstraction , which he calls the Unified Cloud Interface, a sort of meta-API. As already mentioned, the correct approach for standards is to define the 'what' and not the 'how', so the abstraction approach is correct and I applaud Ruv for it. But as also stated, it is way too early in the game to get into this level of detail.  Patrick Kerpan of CohesiveFT expresses a similar sentiment in his blog post Cloud Interop Caution.

Sales people are taught not to fall into the trap of "premature elaboration" when it comes to product feature pitches. "First, ask questions and listen" is the good sales person's rule. I think the same applies when it comes to standards. 

Off Topic: Twitter Un-Follow Vs. De-Follow

Warning: If you don't use Twitter, this post will not make any sense to you, and you will not appreciate the Seinfeldian obsession with the minutiae of Twitter.

I think we should make a distinction between un-following someone on Twitter and de-following. 

The former -- un-follow -- is a public statement that I no longer care about what this person has to say because s/he [fill in blank, but generally, pissed me off].

The latter -- de-follow -- is more of a technical move as part of a clean-up of people you follow because they don't really update, they post way too many updates, they tweet about things that aren't really relevant to you (and you don't remember why you followed them in the first place) or some other more mundane reason. Generally, you have nothing against the person, you're just cleaning up the clutter.