Recently I’ve seen a couple of comments about customers feeling like they don’t know how to “approach” Cloud Computing. Jay Fry, VP of Strategy at CA recently remarked that a customer felt like they were behind the curve when it comes to Cloud Computing adoption. (The power of market hype at work.) Scott Sanchez, author of a great blog on Cloud Security called CloudNod recently provided some advice on where to start with Cloud Adoption (take some non-essential intranet images and store them at S3, Rackspace or another cloud storage provider).
I think these comments point towards the need for a framework that allows enterprise technology and development organizations determine where they are on the spectrum of Cloud capabilities — a Cloud Computing Maturity Model (CCMM). And once they have an understanding of where they are, what are the next steps to build a world-class Cloud Computing capability? A clear Cloud Computing Maturity Model would help large development organizations provide a talent development ladder that is visible throughout the organization.
A well-developed CCMM would also marry market best practices with an organization’s particular development needs and create a clear roadmap for organizational IT transformation. Having a clear understanding of how to develop organizational using this framework would give CIOs of large enterprise companies comfort that they are incorporating this fundamental IT shift in a conscious, prudent manner.
The concept of a Cloud Computing Maturity Model has already been raised in the market and great discussion has already been started:

• • James Urquhart addressed this issue in a great blog post in late 2008. He proposes a five-stage model along the lines of: Consolidation > Abstraction > Automation > Utility > Market.  I would argue his proposed model appears to be heavily weighted towards the infrastructure side of the Cloud Computing equation.
  • Jake Sorofman offers a slightly different version that seems more “middleware/glue” oriented in this post. His stages are: Virtualization > Experimentation > Foundations > Advancement > Actualization.

I would note that a pure maturity model really focuses on whatever processes you are currently doing and drives them towards optimization, but these two discussions are good places to start.  Regardless, as the market begins to catch up with the Clouderati discussion, it may be time to dust this concept off again and continue to develop it.

As early adopters share their use cases with benefits gained and lessons learned, models for organizational adoption of Cloud Computing will begin to emerge. These models will help larger, more deliberate organizations put together concrete adoption strategies and provide confidence to the entire organization that they won’t be left behind by the shift to Cloud architectures.

SAP announced today that they are acquiring Sybase for $5.8 billion.  Forbes’ magazine thinks its because SAP needs to get bigger. I disagree.

SAP is acquiring Sybase for two reasons, none of which have to do with getting bigger for bigness sake:

1. SAP has had real issues launching their SaaS efforts. In fact, Oracle’s recent agility and determined efforts to deliver next-generation platforms is driving SAP to move quickly. Sybase’s database offerings can help transform SAP’s architectural offerings to be more “cloud” like. Just like Oracle’s “there-is-no-cloud” Cloud offerings.
2. More importantly: Now is finally the time for enterprise apps to go mobile! Thank you Mr. Jobs for the iPhone & iPad. It has catalyzed the long emergent mobile enteprise application market. First, Google acquired Admob for $750 million. Then HP acquires Palm for $1.2 billion. Now you have SAP realizing that they need address this application access shift in a serious way — Sybase’s mobile capabilities will help them do that.  In fact, the acquisition was telegraphed in their earlier partnership established in March of 2009.  At that time, Bill McDermott, president of Global Field Operations for SAP, said during a press conference, “There is also a mega-trend that we see: the mobile enterprise worker is now the most important worker, because the mobile enterprise worker is now touching the customer.”

Will Sybase make SAP nominally bigger? Sure. But this is more about capitalizing on new opportunities through the technology than size considerations.

I had a great time discussing Cloud Security with Mike Masnick of Floor64 and Sam Quigley of Emerose today during an IT Innovations Webinar. During that talk, I discussed my view that Cloud Computing is really two different markets today: “Cloud Forward” & “Cloud Backwards”. As illustrated below, Cloud Forward refers to a market that is composed of new, web-oriented applications and companies that are purpose built to leverage web technologies and Cloud Computing.  Think Web 2.0, Social Networks, Social Gaming, etc… most of these companies were engineered to rely on OPI (Other People’s Infrastructure) by design. This is largely because many of them followed a “Lean Startup” path and didn’t have nearly enough capital to build out a robust web datacenter with significantly scalability from the start.  In fact, very few companies have that kind of dough. These are the start-ups that have really powered Amazon and other PaaS providers’ rise. But they are completely different from the Cloud Backward market — the desire of many traditional enteprises IT shops and vendors to exploit that same leverage with existing applications.  This is a much more challenging market because Cloud Backward is competing against mature, highly-tuned infrastructures that are purpose built for applications with very low latency requirements. The separation of these two markets and the implications it has are far-reaching. For enterprise IT groups and developers, understanding what workload you are dealing with will largely dictate which type of Cloud technology you will use and subsequently which vendor you will be working with.  For vendors, there is a stark difference in selling to the Cloud Forward community and the traditional enterprise market, especially as you engineer effective channel strategies for growth.  As William Vambenepe states on his blog:

“All in all, the distinction between backward-compatible and forward-compatible Clouds is not a classification (most Cloud environments are a mix). Rather, it’s another mental axis on which to project your Cloud plans. It’s another way to think about the benefits that you expect from your use of the Cloud.”

There will be overlap between the markets. As indicated, at the enterprise level, we see marketing departments as the driving force in approaching Cloud Forward models.  Marketing groups are aggressively using new web-based formats to approach, acquire and maintain relationships with customers. Often they are hiring forward-thinking consultants who are comfortable with the Cloud Forward architectural style.  The good news is that they are seeing such good results, they are pushing back strongly when internal IT inevitably shows up wanting to rope those workloads back in house. Often internal IT just can’t keep pace with the agility that Cloud Forward provides. However, I believe that we will some internal enterprise groups move aggressively to offer “cloud-like” architectures which move fast enough for marketing departments and have the added advantage of providing familiar security controls that will provide comfort to many executives suites.

We’ve all been to a few conferences now and have heard the same attempts to define Cloud Computing over and over. Pundits, analysts and vendor strategists can barely contain their sanity when it’s brought up again. I’m not going to create a new definition, but I did want to help people understand what I call the Cloud Spectrum.

The Cloud Spectrum helps people understand how the various flavors of Cloud — Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and Software as a Service (SaaS) — fit into the larger Cloud umbrella.

By examining what layer of the compute stack is being abstracted and delivered, it’s pretty easy to differentiate a service as belonging in the IaaS, PaaS or SaaS category.  This categorization also helps vendors think about what value they are selling into the end-market (not to mention which end-market they should target!).

• IaaS vendors should be emphasizing value propositions that compare to a customer’s physical computing choices and any (all!) associated problems that come with that infrastructure.
• PaaS vendors probably have the most esoteric positioning and message development challenge because they have to promote the value of an architectural platform.  This is why smart vendors like Heroku and EngineYard have largely drafted and supported a platform that is already gaining gaining its own traction, Ruby on Rails.
• SaaS vendors should clearly focus on higher-level, business-oriented messages. This may be why Salesforce.com initially ran into some challenges when they launched Force.com – their existing user base, salespeople, didn’t really understand (or care about) messaging related to application frameworks.

IBM recently bought Cast Iron Systems to accelerate its Cloud efforts. According to @monkchip’s download from WebSphere GM Craig Hayman, IBM was specifically interested in the “specific application integration patterns” nee adaptors (“Cast Iron generates adapters that run on existing integration tools such as WebSphere MQ, or JPA.”) as well as Cast Iron’s capability to manage API proliferation in the enterprise. As IBM is squarely involved in the heart of enterprise Cloud Computing, this validates the idea that data integration is a key to getting Cloud right. They wouldn’t make this move if they weren’t encountering the issue in many customers.

But data within silo’d within applications has been a problem for quite some time, why is IBM moving on this now? Based on some work I’ve done with sales GTM organizations and their implementations of Salesforce, I would posit that Salesforce has reached the tipping point as a major system of record when it comes customer data. I have worked with one client where there is absolutely a tension between the incumbent SOR: Oracle, which they use to report to the SEC and Salesforce, the SOR that the sales organization depends on. In an age of Sarbanes-Oxley, it’s clear that maintaining both sets of datasets concurrently is priority for executives that must certify their public filings.

Salesforce is by far the largest SaaS vendor, but there are many others out there that are growing rapidly as well. While long term I am a believer in unified data pools for the enteprise, it seems like the next 3-5 years will be dominated by loosely-coupled data pools that are increasingly “networked” through API proliferation and services enablement. In the long term, I expect the market to start thinking from the perspective of “What does this do to my data pools?” instead of “What does this do to my application?”.