Blinded by the Cloud

First, please afford me my ‘Cloud’ rant: we all understand the Cloud is nothing more than a highly virtualized and self-service automated datacenter run by another company right? There is no magic there; Harry Potter isn’t in the cloud waving his magic wand around your servers as they float up in the air. They are sitting in a datacenter; just like the one you moved them out of and all the same risks are there to be understood and rationalized.

The cloud follows the same guiding principles as a traditional IT services outsourced deal. It also exposes you to the same potential pitfalls. So, what exactly are the pitfalls to watch out for when outsourcing critical infrastructure components? Here are some real examples of cloud migration challenges I’ve seen:

• Institutional knowledge gaps: I’ve seen simple new server deployment requests go from 3 days on premise to 3 months in the cloud. You wouldn’t expect your core operational infrastructure team to be able to provide support for an application in a new datacenter with new automation tools and scripts without some ramp up and preparation; yet, often enough, they are expected to support cloud infrastructures as if they’ve always been doing it. Expect a slowdown in project delivery while these gaps are filled.
• Tooling: A commonly missed aspect of an organizations cloud journey is tooling. The cloud introduces a whole set of inherited architectural components that your existing tooling may not be able to integrate with seamlessly. Expect a lot of headaches with incident and problem management efforts as well as an increase in operational load if you miss this piece.
• Incident management procedures: I’ve seen metrics spike to a doubling of quantity and duration of incidents for applications in the cloud. Seems like a simple enough area but organizations often forget to update call sheets and escalation procedures to account for the new cloud dynamic. Expect applications to go down more often and stay down longer if this and the tooling are not addressed in your cloud strategy.
• Security: You will never hear me fear monger about security but I don’t advocate for recklessness either. In regards to the cloud, make sure you take the time to understand and prioritize the new risks associated with the change in how you do things. Remember, just because you are outsourcing the component doesn’t mean you are absolved from the risk; you need to get validation from the vendor that their security controls meet your risk tolerance or you need to put additional controls in to cover the gap.
• Cost Sprawl: I can’t even count the number of times I have seen organizations make the decision to move to the cloud for the cost savings only to have the first few months of bills come in with cost overruns that set everyone scrambling. A few things are going on here. Often, the controls on internal expenditures are not carried over to the cloud; Jane Analyst can spin up a server, driving up costs, whenever she pleases. In addition, the ease of adding compute, storage and processing power breeds bad habits. It is much easier to add capacity to the database then figure out why that complex query is chewing it up in the first place. This sprawl has a hard limit check point when you have the servers in your own datacenter; in the cloud, no such check point exists unless you purposefully build that intelligence into the solution.

How do we avoid these pitfalls? Believe it or not, the answer is in the often overlooked business process design. Most businesses would never push changes to a customer exposed API without putting some thought into design, functional and regression testing, and release management activities inclusive of customer education of the change. What is often overlooked is that a process is much like an API. It takes an input, executes an operation on it, and produces an output based on some routines, protocols, and tools. Take the same care with process change as with API change and your cloud journey will be supportive of the processes instead of disruptive to them. Here is a lightweight model to start with:

• Define what and how things get done now: Start with a list of all your use cases; how do people (don’t forget to include your infrastructure administrators here) and applications (don’t forget to include your dash boarding, analytics, reporting applications here) request and consume infrastructure assets today? What are the business processes and cost controls around that consumption? Define a process map for these interactions so each step is understood. The end state goal is to have a SIPOC (supplier, input, process, output, and customer) definition understood for each use case.
• Define your solution requirements: Take each SIPOC from the previous step and overlay the things needed to maintain the functionality of each existing activity. For example: your use case is application owners request a new server with a 4 hour turnaround time; your SIPOC may be:

Supplier: Application owner

Input: service request ticket – new server, 4 hour OLA (operating level agreement)

Process: ticket created, ticket approved by manager, automated build process started, tools deployed, CMDB updated, and ticket closed

Output: service request ticket – new server closed; server available

Customer: Application owner

Write a process requirement(s) for each step. The process requirements might look like:

1. Solution must provide automated self service provisioning of servers in under 4 hour OLA.
2. Solution must provide integration with existing ticketing system and automation workflows.
3. Solution must provide automated provisioning of tog agents.
4. Solution must capture and update CMDB with any newly provisioned assets.

• Define how things will get done going forward: This is the bulk of your design work. Define all the technical requirements around each of your process requirements. Identify any process requirements that are impacted in any way; these are the things that will impact your customer. Example: In the above process we are provisioning a server. If I am an application owner and I put the same type of ticket with the same information in and get a Server that is accessible the same way I have always accessed new servers then no problem here; the back end technical details are sufficiently abstracted from the consumer. If different data is required on input, the server configuration is different in some way or I have to access it a different way than that process requirement needs to be flagged as changing; it will cause confusion.
• Understand the difference between the old and new: For any process requirement that is changing you will need an updated piece of documentation, a communication strategy around the change and some level of re-training on the new way of interacting with the platform.
• Prioritize the findings: Ensure your migration strategy accounts for appropriate risk ranking and mitigation of identified process impacts. In my experience these items almost always warrant a very high risk ranking due to their potential impact on implementation complexity, acceptance and potential for business disruption.

By focusing in with a business process lens to identify changes you can ensure some of the common pitfalls are avoided and adoption of the new platform is more seamless. Traceability of the process changes through the project lifecycle are a critical component to adoption and often get lost in the push towards the shiny new technology excitement. Keep them in the forefront of conversation and drive understanding of these impacts through the entire project team.

About the author – Brett McParland

Service and operational improvement focused information technology executive with over twenty years of experience translating information technology theory and strategy into action. My passion is leveraging continual improvement concepts to deliver efficient, effective and secure IT services to the business. My expertise is built around successes in solving organizations challenging and lingering issues utilizing iterative cycles to gain traction, provide directionality and build a self-sustaining momentum aligned to strategy.

I encourage you to reach out and start a conversation about your biggest concerns. Often a quick conversation and outside perspective can provide enough insight to set you on the path to change. I can be reached at bmcparland@makeitsilent.com