Natural Cloud Salespeople

..

So, in the definitional piece called “Defining Cloud Services Brokerage: Taking Intermediation to the Next Level”, we said (free peek):

Since CSB is not a technology. It is necessary to describe it in terms of a business model, providers, deliverables, functions and enablers:

• CSB business model: A model where a business acts on behalf of consumers of one or more cloud services to intermediate and add value to the service being consumed. Providers of cloud services can benefit as well through establishment of an ecosystem of partners, such as brokerages, who enhance the provider’s service and draw customers to it.
• CSB providers: Specific companies or other legal entities that offer CSB.
• CSB deliverables and functions: Business and technical value-added capabilities delivered by a CSB provider.
• CSB enablers and enabling technology: Various IT services, software or hardware assets used to deliver CSB.

But that wasn’t enough. We had to go on and provide a logical reference model (See “A Logical Reference Model for Cloud Services Brokerage“, by me - sorry about the pay wall) and some basis for the judgement that CSB is going to be big Big BIG! So, we used simple logic. We looked at the companies entering the CSB-related markets and companies that were already there. Now, from here, you can do the math.

Use whomever’s market numbers you want. Add up the custom development markets for SIs, SI application and integration projects, B2B integration markets, Process outsourcing (BPO) markets, API governance markets, context brokerage markets, security brokerage markets, value-added reseller markets, internet performance acceleration/content delivery markets, backup and recovery markets and…well, I could keep going but you get the point – we’re getting into the range where there is a “tr-” in front of the “-illion”. Now, let’s go conservative and attribute just 10% (that’s only one customer in 10 doing cloud stuff) of those market totals to companies in those markets doing what they do – but doing it for cloud services. And, if the number you come out with isn’t BIG, then I’ll ask you to count again.

Cloud services brokerage is not one market. It is a composition of parts of markets that are really significant in size. I’m not saying that all the revenue in those (and more) markets will be CSB revenue. I am saying that a non-trivial part will be. If cloud computing will be big, brokerage will flow right along with it. And just like the accessories markets for your iPod, Android phone, PC, and Honda accord, you will find the value-added intermediaries (brokerages) may command the lions share of the spend happening in cloud computing.

Some people feel intermediaries needlessly complicate things in the cloud. I feel the opposite. And, opportunity awaits.

A lot more is coming on this, so join the dialog!

Cheers, Daryl

The essential issue here is that software products licensed for on-premises deployment are not always able to be deployed in the cloud without license changes or additional cost. This is because the company that purchased the software purchased it for their own use and moving to the cloud arguably means that another company (the service provider) is now affecting the terms of use. Now, common sense says this is not rocket science to figure out. The original buyer is still the user of the product. The cloud provider is just hosting the product in another location. Still, the issue comes up more often than you might think.

Check your license agreements before moving that software to the cloud.

So, the thought occurs to me that there might be some massive movement towards cloud providers stockpiling licenses of databases, middleware, tools, or even apps so that they can provide those software options to customers even when that software is not part of their line of business. I don’t mean companies that are in business to deliver those products as a service but rather companies that will deliver them as a value-added capabilities to make configuration, deployment, and licensing (and possibly even more critically – maintenance) easier for their potential consumer base.

Sure, there is “software as a service” out there, there is “platform as a service” out there, there is “database as a service” out there, but I am talking about availability of software to be managed and maintained by the consumer while using a provider’s “infrastructure as a service”, not the software delivered “as a service”.

So, if Amazon acquired bulk licenses of middleware products from Tibco or Software AG, or even IBM, would you buy them? Certainly if you would, it could open up a new line of revenue for software vendors that are constantly under pressure. And yes I know that the model of cloud moves away from just running software in the cloud and towards software delivered as a service. However, there are a host of products being run on premises right now that need to be migrated to virtual servers in the cloud or many companies just can’t act.

And what about those companies that want to buy licenses of new products without the hassle of having to start on premises at all? They can get the license for a cloud deployment from their software vendor at a price subject to their individual buying power; or, they could get it from a bulk supplier who can combine all its purchases into massive price pressure and pass the savings on.

So now I ask you these questions: Is it desirable or feasible that bulk software licenses from cloud providers will become an important line of revenue for software vendors? Is it at all feasible for general cloud infrastructure providers to also sell software licenses acquired in bulk? Or, is it more likely that the continued pressure on software licenses and maintenance will keep building until it all goes BOOM!?

Bill Baker did a quick piece on this last year in “Don’t Overlook Legal Issues in the Cloud”, as did Chris Edwards in “Uncovering the legal issues behind cloud computing”, and a host of others.

And yet, even with all those pieces out there, where is the firestorm that should be building? Most customers want to talk about public and private cloud but when I bring up the legal side I get blank stares half the time. Its like they know there is a party going on, but either they weren’t invited or they don’t want to hangout with Denny Crane and Alan Shore any longer than they have to.

The legal party is heating up around “Guarantees” – like what will, and what will not be guaranteed a consumer of cloud services by the provider?

-         Will they guarantee where your data is?

-         Will they guarantee that the regulations of your home area will be applied to their services delivered from another part of the world?

-         Will they guarantee up-time, privacy, security, bandwidth, or anything having to do with living up to your expectations?

Denny Crane would probably just ignore those issues and bribe the judge whenever he was challenged. But back in the real world, those are still outstanding questions among many others that might relate to future legal action in the cloud.

But don’t worry, it may not be as gloomy as it might seem assuming you don’t like to party with those esteemed and educated jurist jockeys. Just keep in mind that, in many ways, the lawyers will be the ones who urge cloud providers to get off their collective “briefs” and start providing some of the guarantees Enterprises need from cloud services.

So, I recommend this – if your cloud planning meetings do not include legal staff, get them there now. If your legal staff is not rapidly coming up to speed on cloud computing issues, get them on the phone with me before breakfast. And, if you don’t think you need legal representation in cloud computing efforts, get ready to be deposed.

Where Mike leaves off, I feel compelled to comment. Certainly, we are at greater risk of losing something we come to value when it is out of our control. But there are two things that Mike did not mention which leave me less concerned (Oh, and I had never heard of this Debbie Downer person but I ain’t inviting her to the next investors club meeting).

1 – The Ecosystem: Who is to say that when a cloud provider goes out of business that they don’t have assets to sell? If something is important enough to draw a lot of eyes or attention then somebody is usually willing to step in and to buy up whatever assets are left to capture those eyes for another purpose. So, providers may disappear, but content might not. Who is to say that a site we relied on won’t morph into something different while we move on to other sites? Many of the forums I have used over the years have morphed or changed membership or even content. I just keep following where the interesting noise is. Who is to say that our stuff stored in the cloud is not valuable to a number of potential suitors? Buyouts happen all the time in the physical storage word, why not in the cloud world? Imagine the brand-value of “Wikipedia”!

Sure, some providers will disappear with all our stuff or will lose it to bad processes (e.g. T-Mobile Sidekick) or something but those types will either correct their failures or be weeded out over a short time; and, the ones that remain will become much more reliable. That is the way of the market and business ecosystems. (Oh, and remember that the T-mobile failure was a process failure, not a cloud failure but we have to live with the results).

2 – Regulation: The dreaded R word. We hate it but we must acknowledge that some Cloud services or Web 2 sites may grow to a point where they become subject to regulation or government support. Perhaps not the Wikipedia of today but I suggest we are not far off from an online crowdsourced information utility that gets either industry or government regulation. If it becomes important to the masses and important to government, it will get regulated.

Don’t mistake my position. Mike has pointed out some practical realities of the Web 2 and cloud movements. He will undoubtedly be right and we should be cautious (especially about the backups). But let’s not forget that this stuff is still in its infancy. It is not a mirror of what happens with technology. It is a mirror of what happens in the real world – which has dealt with service-orientation for thousands of years. The mechanisms are out there. All we are waiting for is the cloud to catch up on how to use them and to discover new ways to reduce the risk.

In the mean time, back it up yourself, find a broker to protect you, or don’t use the cloud – not many other choices. I think the rewards will be well worth the risks and the inevitable failures.

What is he rambling about now, you ask? Well, the gist of it is this. When you approach cloud computing, one of the things you might be seeking is elasticity of the cloud services and platform. You know the ability to have capacity on demand and to release that capacity when you are done with it? And you pay only for what you use? It’s nice not to have all those fixed assets lying around when you want to reduce your reliance on them. But, have you considered how On-Demand might affect your expenditures that are no longer fixed?

I call it On-Demand Overspending. Nice little name to go alone with my previously named IT Overdraft protection. That was about what some call “Cloud bursting” – where you get more capacity from the cloud automatically when you run out; and, you pay as you go. But the history is pretty clear on this. When we have variability of expenditures with fewer controls, we can run into overspending (BuddyTV had a nice video on this). Some research done by Onecompare.com was highlighted in a web article recently citing how mobile customers in the UK were overspending on their mobile plans because they had been sold plans smaller than their actual needs. These users either talked using more minutes than they expected they did, or talked beyond the number of planned minutes they had paid for. The same will happen, both intentionally and unintentionally with cloud services.

As more workloads move to cloud style deployment, there will be a corresponding, but not necessarily equal, movement of expenses from fixed capital outlay to operating outlay to cover variable use and supply. The problem with this is that it means there is a lot more variability in budgeting (which budget people don’t always like), and there may be fewer controls on who uses how much of what when. In fact, operating expenses dwarf fixed capital outlay for most technology organizations. Operations maintenance costs are already high. But with a pay as you go model, or a “plan” model, we will see some companies begin to overspend on compute resources simply because they use what they can use and may not have the controls to say when they should stop using.

Let’s take an example. In a previous life, I delivered a system to allow legislators to print their own reports rather than relying on a developer to write them. What happened after a short time was that the legislators began printing reports multiple times in multiple formats and multiple copies. Now this was valuable to them so it was encouraged. However, it did require an increase in the capacity of the database platform, the servers, and the network bandwidth (not to mention printer ribbons and paper). The side-effect costs were higher than imagined. This is a trivial example but it illustrates a simple but important axiom. Call it Plummer’s 2nd and a half axiom of overspending – to wit, “a consumer of an unlimited capability will consume unexpected amounts”.

Now this is not to say that IT organizations will not try to put controls in place to meter and limit usage. And, we know that capacity is not unlimited even from the cloud. My colleague Lydia Leong pointed out that even Amazon limits the number of servers (nee services) that you can spawn. This is only logical. But the axiom still stands and there must first be metering in place on cloud services usage. It would be a good idea for that metering to be exposed to the ultimate consumers of the services just as the electrical meter on your home is exposed to you. The Cloud paradigm will eventually evolve a metric equivalent to the “Kilowat-hour” in order to communicate clearly and simply to business decision-makers how much service capability they are using.

On the IT side, the metering is likely to be in place earlier as developers build and use cloud based resources. But, again history provides a warning. When we first began to build serious Web applications, the cost of testing that came from developers all hitting our web resources, or from customers trying everything out that they could pushed us beyond established “plans” of use and changed our budget expectations.  Developers especially are notorious for using whatever resources are within reach. They had better have limits or your money will fly out with their ambition. And back to testing. When you use services owned by someone else, you have to test what you build but the tests will often run against the live services (unless the provider gives you test images to use) – and you have to pay as you go. Is the cost of this testing built in? The days are gone when we can duplicate their environment in-house for testing purposes. Can your budget handle this variably as well?

At the same time, when we go to limited plans for usage of cloud services, we will inevitably run into situations where we buy less than we actually need and have to start paying (perhaps at a premium) for usage beyond our plan. And just as with mobile phones, this will lead to a degree of variability in our costs that we cannot always predict or control.  As cloud computing grows, there will be pay as you go plans for services, there will be limited plans and unlimited plans. Not everyone will want a per-message or per-transfer price. But no matter which kind of usage plan you devise. You had better have a corresponding plan to scope and ensure that usage itself is within a set of limited bounds or at least well-understood bounds.

If you do not, you may find there ain’t no “rollover minutes” left over to bail you out.

So, the nice thing is that all these companies have some thing to offer from network to carrier relationships to governance to deep customer knowledge. And guess what – they all know how to be service providers (See my post on ISVs failing this test).

I keep looking at this and trying to ferret out the real opportunities for telecom companies with cloud computing and so far, I can’t say that I am convinced they will be able to beat IBM at the “Enterprise” cloud game, but I can say that if they are bold (and if they can weather the economic crisis), then there are several areas of key interest from my perspective:

1 – The network touches almost everything – think about it.

2 – Do your carriers have deep relationships with the ultimate consumer that you can leverage?

3 – Can you do something that others are not good at, given your historical position as pre-cloud service providers (i.e.  billing support, customer service, monitoring, provisioning, metrics, payment model)? If so, you might find an entry point.

4 – Are you doing all you can with context awareness and communications-enablement?

If all these things are on your drawing board, then you may find an easier entry to this cloud game than others who are not looking at them. But be warned – these things are not a secret, and you either have the ability to generate interest by delving into them, or you need to partner with someone who can. Those who are giants in this area – and you know who you are – make haste.

The clock is ticking – and you need to make a splash before all the other emerging cloud players make this a moot point.