Skip navigation

Today GigaOm posted my latest thoughts on compelling cases for clouds. Here is a more in-depth compilation of viable business models for the cloud. I broadly define CLOUD as an acronym that encompasses not only cloud computing, but any Common, Location-independent, Online, Utility, on-Demand service, including hotel chains, electric utilities, mortgage lending, and rental car services, so I use some analogies from outside the “Cloud Computing” domain. In any event, the business models / use cases that I list here apply to most definitions of cloud computing and cloud services, and can also be viewed as being relevant to many on-line services or the web. In fact, if my analysis is correct, any web site or cloud service that has a valid business model should fall into one or more of the following buckets.

– Connections
– Communications
– Conversations
– Casting
rightarrow Connections are a natural function for the cloud. Until 1878, phone connections were done on a point-to-point basis. Starting in January of that year, the first cloud bridging function, aka telephone exchange, was deployed in New Haven. As a result, instead of needing multiple phones at your residence—one physical phone for every other party you might want to call—you just needed one phone to connect up to the cloud. Communications take place over connections, and conversations are the long running transactions of communications. Also, communications need not be unicast, but can be multicast, anycast, or broadcast. The key reason such functions need to be processed in the cloud is that n connections to a hub are less costly than n squared point-to-point connections.


Examples: telephony, microblogs

– Correspondences rightarrow Another type of connection is matching, or correspondence. For example, dating sites make connections between people, and search sites make connections between advertisers and people searching for information. To best determine a correspondence requires the greatest number of options for each user, inherently driving a cloud-based solution.


Examples: search and dating sites

– Collaboration
– Competition
– Co-opetition
– Commerce
rightarrow Collaboration occurs when multiple parties communicate, or interact, for the sake of achieving a common goal where all can simultaneously achieve the goal. Competition occurs when they interact for a common goal, but only one or a subset can achieve that goal. Commerce is a mix of collaboration and competition. People gather to brainstorm. They gather to compete in arenas or engage in commerce. They gather in real-world markets such as the New York Stock Exchange or a neighborhood flea market. Similarly, collaboration, competition, commerce, or other interactions are best done in a common location—real or virtual—because collaborators benefit from more collaborators, it’s not a competition without other competitors, buyers benefit from more sellers, and sellers benefit from more buyers.


Examples: on-line gaming, vertical market sites, on-line auctions.

– Clearing rightarrow When two parties engage in commerce, clearing, payments, and settlements can best be conducted in the cloud, by a neutral and trusted 3rd party. This is why lawyers have escrow accounts, and banks and brokerages utilize 3rd party financial intermediaries.


Examples: on-line payments and electronic funds clearinghouses

– Conversion rightarrow Whether natural language translation, file format conversion, currency conversion, media gateways, transcoding, transrating, or the like, conversion functions are often (but not always) best done in the cloud. This is especially true when there may be a multitude of parties interacting in many formats. Exceptions would be compression and encryption, which are best done on the originating end, and of course decompression and decryption, which are best done at the destination.


Examples: audio and video bridging, currency services

– Community rightarrow Communities are the pinnacle of the spectrum from connections to collaboration. Communities are built on connections where there are also shared goals, values, or interests. Since communities are made up of many participants, it doesn’t make sense for the community to reside with a single participant.


Examples: social networking sites

– Crowdsourcing rightarrow Crowdsourcing for prediction markets, recommendation engines, or tagging tends to be a cloud function. Although crowdsourcing or open innovation for a particular initiative might occur at a single participant’s site, maintaining a regular community of crowdsourcing participants belongs to the cloud.


Examples: on-line movie rental / streaming sites, news or tagging sites with popularity voting or recommendation engines.

– Commons
– Collections
rightarrow Anytime that access to resources is partial or intermittent, a commons generates economic value. For example, it is difficult to single-handedly use all of Central Park for all eternity. Space-division and time-division multiplexing of common (shared) resources is less costly than dedicated resources. A collection, e.g., the Library of Congress, is an information resource. This cloud model dates back thousands of years. Even when the same information object can be used simultaneously, such as an online books or patents database, economics still favor sharing, because the cost to assemble the collection is incurred once and/or is roughly proportional to the size of the collection, whereas the value or revenue is derived in accordance with the number of users and uses.


Examples: online book or patent databases

– Continuous Cross-Device Access
– Continuous Cross-Network Access
rightarrow Information on an untethered device may not be available to even the owner of that device, unless he or she is co-located. Putting the info in the cloud means it can be accessed from anywhere and any device, given the right user access control.


Examples: web mail or photos accessible from your laptop or your smartphone, or anyone else’s, if you choose.

– Cost rightarrow The cloud may be cheaper than do-it-yourself, depending on your costs and the cloud service provider’s prices. Cost may be lower due to economies of scale—the cloud provider has lower HW costs, SW costs, tooling, cooling, power, etc., which are low enough to offset some additional expenses, such as SG&A. Or the provider may have better statistics of scale—by multiplexing demand from multiple sources can achieve better utilization. Or, the provider may have end-to-end architecture benefits—for web sites, it may cost less to be hosted by an integrated service provider because all that traffic does not then need to further be transported to an enterprise data center.


Examples: electricity, cheaper to buy from the grid than run a nuclear power plant in your back yard

– CapEx
– Cash Flow
rightarrow Capital expenditures aren’t bad, unless they are for fixed capacity which is underutilized or insufficient, which is almost always the case. The other issue for smaller companies is that large capital expenditures may mean that there is not enough cash left to run the business.
Complementary Capacity for:
– Cloudbursting
– Continuity
– Center Migration
rightarrow I’ve explored the cloudonomics of hybrid clouds both at and in some articles. Briefly, lowest total cost can be achieved through judicious investment in dedicated resources and on-demand use of pay-per-use resources, subject to additional concerns such as cost to store and transport data. These can be used for cloudbursting, where the dedicated resources are temporarily insufficient to handle a demand spike and the cloud is used for the overflow. They can also be used for business continuity, in terms of both failover and data availability via mirroring or replication, when the dedicated resources are impaired, unavailable, or destroyed, and the cloud becomes the home for applications, services, or data. Or, the cloud can be used for data center migration, where applications can be housed temporarily.
– Comparative Advantage
– Context vs. Core
rightarrow David Ricardo showed that even when one entity enjoys cost advantages over another, it still makes sense to trade. Implications for IT shops: even if you can do everything yourself, it’s better to let someone else focus on context (non-core) activities, so you can devote your finite resources to things that develop or enhance competitive advantage.


Examples: outsourcing HR, CRM, tax prep, or stock picking via a mutual fund.

– Capabilities and Competencies rightarrow Sometimes, you can’t do it all yourself, so that’s not an option. Cloud providers, especially as the SaaS market continues to evolve, develop unique expertise based on learning curve effects, “economies of skill,” and specialization.


Examples: proprietary search algorithms and heuristics

– Celerity rightarrow “Celerity” is synonymous with “speed.” Cloud services can accelerate software development, testing, and deployment, by ready access to platforms and pre-deployed resources. Of course, using existing software in the cloud by definition is faster than trying to develop that same software from scratch.


Examples: software, platform, or infrastructure as a service

– Customer Experience
– Convenience
rightarrow Customers demand optimal experiences, or will go elsewhere. In today’s highly interactive world with globally distributed users, customer experience is enhanced through a geographically dispersed architecture. This is true on the web, with CDNs, but in the real world as well. It’s why there’s a coffee shop on every corner, rather than forcing you to fly all the way to a single consolidated location just to grab a cup of coffee.


Examples: content and application delivery networks.

– Consistency
– Currency
– Change Control
– Coordination
rightarrow The cloud is great at providing a single reference copy or golden master, whether it is the official time, the length of a meter, or the most up to date version of the presentation you and your colleagues have been working on. A single update applied to this master defines the current version.


Examples: or any SaaS service.

– Checkpoints rightarrow Checkpoints for controlling and validating transactions or entities entering a system from outside the system are optimally deployed at the perimeter of the system, because perimeters are smaller than areas, and surfaces are smaller than volumes. This is why customs, immigration, and border patrol are performed at points of entry.


Examples: network-based firewalls, anti-DDoS, email filtering for anti-virus or anti-spam.

– Chokepoints rightarrow Even if all transactions are valid, chokepoints for traffic management help manage the volume of inflow into a system to prevent the system from internally becoming too congested.


Examples: network traffic management, in digital networks, air traffic networks (gate delays), or highways.

– Choicepoints rightarrow Providing a multitude of contextually relevant choices is a natural cloud function, partly because these choices form a collection, and partly because the choicepoint acts as a point of entry.


Examples: on-line portals, including search results pages

– Combinations rightarrow Any or all of the above can be used together.

One Comment

  1. Outstanding Classification. Thank you.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: