I’ve now done quite a few business modeling sessions with ISVs about operationalizing their cloud strategies. Every case has its unique needs, but there are some commonalities as well.
When asked about services layer elements, like monitoring, metering, billing and provisioning, all claim to have a handle. However, when you scratch the surface none have all services elements thought out and automated. A whole ecosystem ecosystem of services layer partners exists. Some are more mature than others, but all seem to require a degree of configuration and customization to work with complex enterprise solutions. Green Button plays in an interesting space with regards to burst compute provisioning, but I cannot see ISVs agreeing to their margins for long. The ability to provision compute from hot nodes on demand should be an in built PaaS feature.
Financial transaction modeling is also an area were ISVs need help. It is not that mature ISVs would not have advanced financial systems for accounting or that they would not be able to calculate their cloud costs. It is more a need to have the ability to do sensitivity analysis based on average deal sizes. What is required for breakeven? What is realistic? What is in it for the channel? Often ISVs real their modeling at reaching an acceptable breakeven model, but neglect to calculate what profit margin that would offer for partner who is looking to commit a full time resource to promoting the solution. Partners are not in it to breakeven. They want a profit margin on top of cost of sales and/or cost of support.
ISVs that are not used to SaaS pricing need to rethink their incentive models. A 100k on premise solution with 20k S&M component, for a partner with 40% margin on first year, will provide less than half the profit margin as a reoccurring SaaS deal, all else being equal. We need to look at the life time value of the deal. If we were to provide 10% on subsequent years for both S&M and for SaaS renewal the partner would still not benefit from a SaaS sale over an on premise sale. Assuming that a typical technology depreciation cycle is 5 years, a SaaS partner would not breakeven with an on premise partner before the on premise partner sells a whole new solution with perpetual licensing and the whole cycle starts again. Pricing in all models needs to be based on roles and responsibilities of parties concerned. The question is what are the roles and responsibilities in a SaaS model and how they differ from a perpetual license sale?
Value articulation can also be tricky. ISVs often fall victim to separating their core value and value derived from the cloud. Faster, cheaper and easier associated with cloud in general doesn’t differentiate any more. What that specific solution can do when powered by the cloud differentiates and should be integrated into the core value messaging. One value often under utilized is big data inherent to large multitenant solutions. This degree of benchmarking and data analytics has not been possible on premise and is one of the core value adds of the cloud.
I have a back ground in business process reengineering and it came to me last week that companies going into the cloud need reengineer their business strategies. I binged business strategy reengineering and found a wiki for business engineering.
Here’s the definition according to Wikipedia:
Business engineering circumscribes the domain of designing new business fields. Unlike business development, business engineering does not only include marketing related tasks, but also most of the other business administration tasks. Financial and operational tasks are of equal importance, for example.
Business engineering includes all activities that are necessary to develop and maintain an independent line of business. It is comparable with starting a business, but includes the novel component. That means that there is no core market yet and market opportunities need to be created. Most likely, the output of business engineering substitutes known forms of supply, in existing markets.
Therefore business engineering aims to establish new, future oriented forms of businesses but with reference to existing or emerging needs. Business engineering is most likely related with the area of future technology. To abstract it, business engineering combines the establishment of a completely new business in a prospect business environment.
Business engineering is a holistic approach. My personal preference is to use the Business Model Canvas for a holistic approach to business modeling. Business engineering is likely related to an area of future technology. In my case I focus on cloud and social technologies.
Most of my clients are ISVs that have had an on-premise solution and they are facing a need to reengineer their business to meet the new reality. Hence, my niche is Business Reengineering.
You do not know how excited I was to see both the Data and App marketplaces finally launch. When the rest of world is moving at 55 mph, I tend to cruise (figuratively) at 160 mph. So you can imagine my frustration about envisioning solutions and business models that would fully embrace Code Name Dallas in all its potential…. don’t even get me started on how information security intelligence could play into this. I’ve also commented on a number of articles about the lack of an Azure App Marketplace. Well now it is here!!! Go and register your offerings: http://windowsazure.pinpoint.microsoft.com/en-US/getlisted
The App marketplace is still beta and really just an apps listing service… more so than a ecommerce site. Eventually I’d expect to buy seat licenses using my credit card on the site for ISV partner apps on Azure. This should be as easy as iTunes and there is no excuse for it not being so. For the more highly priced solutions Pinpoint should enable creation of corporate accounts with monthly billing arrangements.
Azure is technically a great platform and the only offering that provides true DaaS. However, ISV partners need to be able to advertise and sell their solutions… and Microsoft should also benefit financially.
The data marketplace is what clearly differentiates Azure. Technology is great, but what a vendor enables you to accomplish with it is what truly differentiates. The data marketplace creates a community around Azure. Data is user generated, valuable and the ultimate consumable… an inexhaustible resource that is often generated as a byproduct. By enabling the community to share and repurpose data to create massive data mash ups we will see the whole new generation of integrated cloud applications, the likes of which we can hardly even imagine today.
I toke my 8 year old daughter to see TRON (Disney movie) over the weekend. Driving home after the movie we got into a discussion about the ‘grid’. We also touched upon Second Life, Habbo and Club Penguin. What I got out of the conversation was that for today’s eight year olds the notion of cloud is nothing fantastic. They will grow figuratively 24/7 on the ‘grid’.
I’ve recently interviewed hundreds of independent software vendors about their cloud aspirations. An interesting find was that the large majority of respondents stated that their business drivers towards the cloud was scalability and deployability. Fair enough. But aren’t those also the drivers for hosting and virtualization? Is the cloud just a more refined architecture for hosting and virtualization? Or could it be more?
What excites me about cloud computing is the degree of integration and interoperability within a cloud. The physical cloud offers near limitless storage capacity and computing power. Capacity, power, integration and interoperability offer the ingredients for more that just a more scalable and deployable virtual hosting environment.
FIRSTLY ARCHITECTURE… think about what is done on the client and what at the server end. The cloud will inevitably drive computational tasks away from the client and into the cloud. The role of the client is becoming more driven towards providing a high quality user interface. Most devices are networked and have real time access to the cloud. Most applications do not need extensive off-line capabilities. Also, to be a true cloud solution your solution should be multitenanted. Running multiple instances in the cloud is just having it hosted, but not a true cloud solution.
SECONDLY EXPANDED VALUE… think about core functionality for your solution. Now think about a second layer of added value that is not core. Can this value be offered through integrating with other solutions in the cloud or information mashups between a number of providers?
THIRDLY BUSINESS MODEL AND COMMUNITIES… think of your business model. Yes, going from perpetual to monthly models is typical for the on-demand cloud, but how would it differ from a normal hosted model? Think about the integration and interoperability. Can your solution become communal? Communities are a beautiful captive source of services revenue and potential for add on sales. Not only your services, but services provided by a partner community. Also think of user generated content and how you can broker intelligence between users of your solution. Don’t just think what value the generated intelligence would have for you or your clients, but new audiences (look at Code Name Dallas).
The above three values really come to life in a Microsoft PaaS setting opposed to an Amazon IaaS setting.
Cloud computing is a style of computing in which dynamically scalable and often virtualized resources are provided as a service over the Internet. Users need not have knowledge of, expertise in, or control over the technology infrastructure in the "cloud" that supports them.
The concept generally incorporates combinations of the following:
–infrastructure as a service (IaaS)
–platform as a service (PaaS)
–software as a service (SaaS)
Other recent (ca. 2007–2009) technologies that rely on the Internet to satisfy the computing needs of users. Cloud computing services often provide common business applications online that are accessed from a web browser, while the software and data are stored on the servers.
In summary: The major difference between traditional solutions and cloud solutions is that solutions developed for the cloud support multiple tenants within a virtual architecture. Traditional solutions only support multiple accounts or user within a single tenant.
Macro versus Micro
An example of a Macro Cloud is Microsoft’s Azure. As an analogy, it is a wide open field with a single set of construction guide lines. We can add as many houses from the same mold in the field as we like and charge the tenants a monthly fee. They can furnish their home to their liking, but not alter the layout of their home.
In the future Macro Clouds could support a large ecosystem of Micro Clouds. Continuing the same analogy, the field could be carved up into zones with family homes, town homes and condos. Now the tenant can choose from a list of available floor plans to fit their needs.
Virtualization enables multiple solutions to inhabit a single server. If these solutions support multiple tenants, we can build Micro Clouds that are uniquely tailored to a specific group. In terms of the analogy, we can now tailor our home layout exactly to our needs without having to wait for the zoning to happen.
Creating a Micro Cloud for just one tenant doesn’t make sense, but when we have a small group with synergistic needs, then we can achieve significant benefits. Micro Clouds enable us to customize applications for small groups of tenants that have common highly unique needs… vertical needs. When the tenants in a Micro Cloud interact and share data Partner-To-Partner (P2P) we can multiply the returns of the cloud.