There is a common perception that after you make the move “to the cloud” your life will be simple, carefree and inexpensive.
And so it will.
If it already was simple, carefree and inexpensive.
If you are being sold this vision as the cure for your chaotic business, you’d better get ready to break out the checkbook.
Your life is about to get complex, stressful, and expensive.
Here’s the basic economic reality: it takes a certain amount of investment, know-how and activity to move electrons around, which is in the end what IT is all about. It seems mysterious because we can;t see the little electrons dancing around, but in the end that’s all we do: make electrons go from Point A to Point B, and sort themselves into useful combinations and patterns. If it was easy, we wouldn’t have to pay people gobs of money to do it, but there’s little difference between what the very best organizations do and what one that is barely functioning does. The difference is in how it is done.
If you are having difficulty doing that effectively today, consider that you’re doing it on your premises, where a few short-cuts might not be noticed and the 3 a.m. patch-rollback crew can come in and make heroes out of themselves with minimal impact on the bottom line. Maybe you were able to save some money on self-taught admins, and keep up with the pace of business by “just doing it” rather than wasting time with those tedious change control forms and boards. You might even get by with running some expired software licesne or security certificates … just for a while, of course. Maybe you can save a bit of capex by running out-of-date equipment and software. Let’s face it, your organization can’t be very high on the list for the Bulgarians (or whoever) to attack.
But all this shuffling of the peas under the cups is tedious, and all those late nights on weekends are really wearing the team down.
Enter Willy Loman, 21st century style, still with a shoeshine and still wearing that smile. “You could get rid of all those problems and save yourself a bundle of money besides. All you have to do is go to the cloud.” It stands to reason that the big vendors can generate some serious economies of scale with just a few people running those massive server farms. And from that point of view, they do. not only do they run economically, but they are fully compliant with whatever security regimes you’ve paid for.
We’ve seen this problem before, of course. Outsourcing is nothing new. Nor are dashed expectations. Whether it’s a complex IT environment or the grass-mowing chores at your house, passing the problem off to someone else doesn’t always generate cost savings, doesn’t always provide a result better than what you could have done, and may not even relieve you of any time burden. The real difference will be in the nature of the effort you are going to have to put into it.
If it’s done well, outsourcing can bring you:
- Fully trained personnel doing the job whenever it needs to be done, and doing it right the first time
- Economies of scale
- Freedom to focus on strategic priorities rather than routine operations
- A shift to managing the outsourced work instead of doing it.
Of course, if you were managing the work that is to be outsourced all along, you won’t actually see much change on that last bullet. You could have gotten the same effect by setting performance standards for the execution teams instead of micromanaging them … or letting them run wild.
In actual practice, if you go to the cloud without good internal practices, you have some choices:
- Do everything their way. That’s how their business model is set up. Within their boundaries, they probably know what they are doing. So you don’t do that. You let the vendor execute the services the way they think is best, changes are controlled, and performance is measured. However, all those short cuts are gone. You must work through a change control process. You have nobody to give orders to, nobody to make stay late over the weekend.
- Keep trying to do things your old way, or some variant of it. Some organizations just don’t have the right kind of culture to outsource. Some are so insistent on micromanaging that you’re going to end up being assigned your own account representative, billable to you at an exorbitant rate, because you’re so special. You may end up with your own enclave within their data center, again at an elevated cost to you. in the worst case, you are now requiring the vendor to do everything you were doing, even the silly stuff, using very highly-qualified (and expensive) resources. What happened to “cheaper”? The macabre good news is that now you’re the one posing the threat to their system integrity and they’re probably going to fire you as a customer before long.
- Continue to let things drift along in a laissez-faire sort of way. You’ll be shocked when your bills skyrocket as your engineers invoke instance after instance of this service, and your vendor will be hounding you constantly for approvals to do things; your people will be chasing after you to get approval for more funds for special engineering services to fix your enclave from all the things that got approval to be done. Again, no savings and higher network risk.
- Demand customization of the service to match your processes and systems. For instance, Office 365 works very nicely, as long as you let it work the way Microsoft intended. Wrap a few “refinements” around it, because your organization is “different” from the tens of thousands of others for whom it works just fine, and you will indeed the different: you’ll be the one who can’t get your key applications to work properly. And whenever the foundation gets an update, your unique twists may get wiped out and have to be re-done, leaving you with downtime of one of your key business assets, or saddling you with yet more bills for expensive analysts to help you unravel the customizations yet again.
What sorts of things will you still have to worry about to make this work? Everything. It’s just that you’ve shifted from being “responsible”, on the RACI matrix, to being “accountable”.
The accompanying sketch shows a business architecture for running a cloud service, but with the exception of the central role of procurement, it could be for any other means of managing technology. With a few adjustments, it would work for many non-technology businesses; management concerns tend to be similar across all industries and modes of delivery, and in the 21st century there aren’t all that many business models that don’t involve a healthy dose of technology.
When you’re offered the opportunity to move to the cloud, ask the vendors for their business architecture models. If they don’t have a fairly elaborate one, then you should run for the nearest exit.
Mo
st are pretty open about these models because, after all, their fundamental sales pitch is they understand at least this aspect of the business even better than you do. Among those that have made their models quite easily accessible are Microsoft, Juniper, Cisco, Oracle, and VMWare.
Unusually, for an open source group, one that didn’t make the grade was OpenCloudManifesto.org. Their website has been taken over by a Groupon artist, although some of the blog posts remain in place. At one point their approach was quite widely cited, at least in the Air Force. Maybe their graphics were too ugly; some day i will rebuild this one just to get some decent colors into it! It is quite a useful model.
- IBM shows its reference architecture and processes: https://github.com/ibm-cloud-architecture/refarch-cloudnative-csmo. It is interesting that they only see 3 of the 24 ITSM processes as critical; or maybe that is all they are sharing! [Photo credit: the headline photo in this post is one of the artifacts offered for public sharing at that site].
So what does it take to allow your IT business to move to the cloud where it can run efficiently and effectively?
- Sound governance models and practices so you know what is going into the cloud, what should be coming back out, and what you should be paying for.
- Sound testing practices. Rapid deployment and scaling opens the door to massively scalable errors.
- Sound architecture. The more your backend and applications are in different clouds, the more you really need to understand how the interfaces are going to work, because you won’t have them handy to work on if something goes wrong.
- A couple of engineers who understand how infrastructure works so you can understand what the vendor is trying to tell you
It’s entirely possible that if you had all those things already, you wouldn’t be in search of a headache remedy.
Do you have experience with cloud operations? What did you do right to make it work for you? Your comment could spark a useful discussion!