February 29, 2012 | Written by: Chris Dotson
Share this post:
In our last installment, I wore my system administrator hat and tried to explain why system administrators might be resistant to the types of change that infrastructure as a service can cause. As an equal opportunity annoyer, I will pick on the business managers today.
Business manager’s brain, post-cloud. The top pretzel is “Service Design.”
So, here are examples of how business managers might be required to change their processes to take full advantage of cloud technologies. These are simply examples, so they might not apply to your organization, but hopefully they will get you thinking about change:
- Cloud technologies might cause additional risks, and might mitigate some risks to the point where they are now acceptable risks.
Everyone is familiar with one potential for increased risk with cloud – security. Cloud can help mitigate other risks, however. One of the hats I wear is to lead an internal service provider for development and test environments, and one of my tasks was to develop an engagement process that ensures requests get fulfilled as quickly as possible and with high customer satisfaction. We are a cost recovery organization, so from our perspective, a very important part of the engagement process is ensuring that we get paid!
It is not at all uncommon for one part of the business to want a service, but be unable to provide a sufficient business case to get funding for it. In 90 percent of the cases, funding would come through; but in 10 percent of the cases, if we got started before approval, we might have expended 10, 20, 40, or more hours of labor with no way to recover for that effort. So, until cloud, we had a policy to not begin building an environment until funding was secured (which could take days or even weeks). This annoyed the developers, who were often spinning their wheels without a proper development environment.
When we put the cloud in place, we re-examined this policy. There were two risks: that we would not recover for the labor, and that we would not recover for the hardware allocated. With developers self-provisioning on the cloud, the marginal labor cost for a new environment approaches zero, so that’s not a problem. As for the hardware, we realized we were quite willing to eat the equipment cost for a few days if the funding didn’t come through. The result? We now provide a “grace period” to allow time for funding to come through (and we can easily suspend or destroy the environment if it does not). This took days or even weeks out of the process and added very little additional risk.
- Cloud technologies can change your billing and/or funding processes.
As an internal service provider, we have traditionally sent in the charges for January so that they appear in the ledger in January, in February for February, and so on. With cloud, we’re billing hourly based on what is provisioned, so if the team destroys a server on January 25, they should not be billed for that service January 26-31. This means that we now need to send the bill for January services in February. If you don’t think this is a big deal, you’ve obviously never tried to change corporate billing processes! I still have pencil scars from the accountants; many of them look harmless but they can be a determined bunch. They kept screaming “Debit this!”
And if you think that’s bad, imagine if you’re an internal service provider that is a cost center instead of a cost recovery organization – that is, you’re funded at the top and have to allocate out resources, rather than doing internal billing (chargeback) for the services you provide. At that point, a true self-service cloud environment would allow your internal clients to come in and get whatever they want without any consequences to their budgets. Techniques such as notional charging (sending a bill even though it doesn’t have to be paid) can help reign in consumption some, but I’m not really sure how you would implement a true self-service model without some form of chargeback. Accomplishing a major organizational change like that will need strong executive support (“air cover”) and will upset a lot of people who are more comfortable doing things the old way.
- Cloud technologies can impact your service design.
Traditionally, as an internal service provider, we offered services that were “provider-centric.” That is, we would define services where our clients would come to us, have a conversation, and then we would deliver that service. I believe that most service providers will continue to have these types of traditional services – after all, even with online banking and ATMs, sometimes you still want to go into the bank and talk to someone, especially for more complicated services.
Self-service offerings are nothing new – many organizations have had self-service methods to reset passwords, request storage, and other processes like that for many years. What other things can offer using a self-service model? Can you give someone a database, or a message queue, or an IP address, or anything else self-service?
Look, you’re not realizing the real benefits of cloud if you’re just using it as a fancy provisioning engine to implement the same processes and services. This is what IBM means by “Rethink IT. Reinvent business.” Get creative! Try to figure out the various services that your clients use, or would like to use, and figure out how you can get “out of the way” as much as possible. Ask yourself: “Do my clients really need to talk to a human for this, or can we save the human effort for something more important?” You’re not writing yourself out of a job – you’re changing your job to compete better. If you, as a service provider, don’t do this, someone else will.