How to Make Money in the Cloud: Microsoft, SAP, the Partner Dilemma and The Tools Solution

It’s cloud’s illusions I recall, I really don’t know clouds at all…..

One of the primary devils in the details with cloud computing will always be found in the chase for margins, and this is becoming abundantly clear for Microsoft’s market-leading partner ecosystem, gathered this week in Washington, DC. for their Worldwide Partner Conference. Chief cheerleader Steve Ballmer repeated the standard mantra about how great life will be in the cloud, something I tend to agree with. But missing from Ballmer’s talk was the money quote for Microsoft’s partners:  “…..and here’s how, once we’ve stripped the implementation and maintenance revenue from your business, you’ll be able to make a decent margin on your cloud business.”

More than the coolness of the technology, it’s the coolness of the possibility for profit margins that will make or break Microsoft Azure and any other vendor’s cloud or cloud offering. This is hardly just Microsoft’s problem, SAP has grappled with this margin problem as it has moved in fits and starts towards this year’s re-launch of Business ByDesign. And it’s top of mind across the growing legions of ISVs and developers looking at what they can do to capitalize on this tectonic shift in the marketplace.

The trick with chasing cloud margins is that the chase dovetails nicely with a concept I have been touting for a while, the value-added SaaS opportunity. What is obvious from watching Ballmer and his colleagues discuss the future according to Azure is that much of the profits to be gained from moving existing applications and services into the cloud will largely go to Microsoft. That’s the first generation SaaS opportunity – save money by flipping existing applications to the cloud and reap the economies of the scale inherent in consolidating maintenance, hardware, and support costs. To the owner of the cloud goes the spoils.

This is the same issue, by the way, bedeviling SAP’s By Design: SAP will run its own ByD cloud services, and in doing so, assuming that the problems with the cost-effectiveness of ByD have been full resolved, sop up the first order profits inherent in the economies of scale of the cloud. How SAP’s partners will make the healthy margins they need to be in the game with SAP has been, in retrospect, a bigger problem than the technology issues that stymied ByD’s initial release. And, by the way, thinking that value-added partners – the smart, savvy ones SAP wants to have on board selling ByD – will be happy with a volume business won’t cut it. Smart and savvy won’t be interested in volume, IMO.

But there is an answer to the answer that will appeal to everyone:  build net new apps that, in the words of Bob Muglia, president of Microsoft’s server and tools business, weren’t possible before. This act of creation is where the margins will come from. And the trick for partners of  any cloud company is how easy the consummation of this act of creation will be.

The easiest way to do for partners to create this class of apps is for the vendor to offer the highest level of abstraction possible: from a partner/developer standpoint, this means providing, out of the box and in the most consumable manner possible, a broad palate of business-ready services that form the building blocks for net new apps.

Microsoft is starting to do this, and Muglia showed off Dallas, a data set access service that can find publicly and privately available data sets and serve up the data in an Azure application, as an example of what this means. As Azure matures, bits and pieces of Microsoft Dynamics will be available for use in value-added applications, along with value-added services for procurement, credit card banking, and other business services.

This need for value-added apps then begs two important questions for Microsoft and the rest of the market: question one is what is the basic toolset to be used to get value-added SaaS app development started? And question two: who, as in what kind of developer/partner, is best qualified to build these value-added apps?

I’ll start with the second question first. I have maintained for a while that, when it comes to the Microsoft partner ecosystem, it’s going to be up to the Dynamics partners to build the rich, enterprise-class applications that will help define this value-added cloud opportunity. The main reason for this is that the largest cloud opportunity will lie in vertical, industry-specific applications that require deep enterprise domain knowledge. This is the same class of partner SAP will need for ByD as well.

Certainly there will be opportunities for the almost all of the 9 million Microsoft developers out there, especially when it comes to integrating the increasingly complex Microsoft product set – Sharepoint. SQL Server, Communications Server, etc. – into the new cloud-based opportunities.

But with more of the plumbing and integration built into Azure, those skills, like the products they are focused on, will become commoditized and begin to wane in importance and value, and therefore limit the ability of these skills to contribute to strong margins.

The skills that will rise like crème to the top will be line of business and industry skills that can serve as the starting point for creating new applications that fill in the still gaping white spaces in enterprise functionality. Those skills are the natural bailiwick of many, but not all, Dynamics partners: Microsoft, like every other channel company, has its share of great partners and not so great partners, depending on the criteria one uses to measure channel partner greatness. Increasingly, in the case of Azure, that greatness will be defined by an ability to create and deliver line of business apps, running in Azure, that meet specific line of business requirements.

The second skillset, really more ancillary than completely orthogonal to the first, involves imagining, and then creating, the apps “that have never been built before.” This may task even the best and brightest of the Dynamics partners, in part because many of these unseen apps will take a network approach to business requirements that isn’t necessarily well-understood in the market. There’s a lot of innovative business thinking that goes into building an app like that, the kind found more often in start-ups than in existing businesses, but either way it will be this class of app that makes Azure really shine.

Back to toolset question: Microsoft knows no shortage of development tools under Muglia’s bailiwick, but there’s one that comes from his colleague  Stephen Elop’s Business Solutions group that is among the best-suited for the job. Muglia somewhat obliquely acknowledged when I asked him directly that this tool would one day be part of the Azure toolset, but it’s clear we disagree about how important that toolset is.

The toolset in question is xRM, the extended CRM development environment that Elop’s Dynamics team has been seeding the market with for a number of years. xRM is nothing short of one of the more exciting ways to develop applications, based on a CRM-like model, that can be run on premise, on-line today, and on Azure next year. While there are many things one can’t do with xRM, and which therefore require some of Muglia’s Visual Studio tools, Microsoft customers today are building amazingly functional apps in a multitude of industries using xRM.

The beauty of xRM is that development can start at a much higher level of abstraction than is possible with a Visual Studio-like environment. This is due to the fact that it offers up the existing services of Dynamics CRM, from security to workflow to data structures, as development building blocks for the xRM developer. One partner at the conference told me that his team can deliver finished apps more than five times faster with xRM than with Visual Studio, which either means he can put in more features or use up less time or money. Either one looks pretty good to me.

The success of xRM is important not just for Microsoft’s channel partners: the ones who work with xRM fully understand its value in domains such as Azure. xRM is also defines a model for solving SAP’s channel dilemma as well for ByD. The good news for SAP is that ByD will have an xRM-like development environment by year’s end, one that can theoretically tap into a richer palate of processes via ByD than xRM can via Dynamics CRM.

Of course, xRM has had a double head start: it’s widely used in the market, and there’s a few thousand partners who know how to deploy it. And xRM developers will have the opportunity when Dynamics CRM 2011 is released (in 2011, duh) of literally throwing a switch and deploying their on premise or in the cloud. Thus far, ByD’s SDK only targets on-demand deployments. And there are precious few ByD partners today, and no one has any serious experience building ByD apps.

What’s interesting for the market is that xRM and its ByD equivalent both represent fast-track innovation options that can head straight to the cloud. This ability to innovate on top of the commodity layer that Azure and the like provide is essential to the success of Microsoft’s and SAP’s cloud strategies. Providing partners and developers with a way to actually make money removes an important barrier to entry, and in the process opens up an important new avenue for delivering innovation to customers. Value-added SaaS apps are the future of innovation, and tools like xRM are the way to deliver them.  Every cloud  has a silver lining: tools like xRM hold the promise of making  that lining solid gold.