Three levels of readiness

IN THE WORK THAT I’VE DONE, I tend to group the state of readiness and the order of attack in 3 stages – resource efficiency, operational efficiency and sourcing efficiency.

1. Resource efficiency
This is a state whereby you have standard hardware that can be deployed to meet a high proportion of your use cases and workloads. Of course most organisations don’t have standard hardware, especially when it has organically grown and either the standard evolution of the part introduced differences between different age stock or the intended project had different budgets or requirements that forced deviation. Either way, there is a solution that helps drive some uniformity out of the disparate hardware.

That is abstraction of that hardware layer through virtualisation. Many organisations have already made some progress along the path of virtualisation and although this might not contribute too much in standardising the hardware it does drive standardisation in deployment of applications as the base is the same for all. The more mature a virtualisation programme is within an organisation, the greater the resource efficiency. This is true without factoring in the over provisioning and consolidating effects of virtualisation.

2. Operational efficiency
This competency focuses on the amount of human effort is required to complete an operation on the service. Essentially this is a measure of how labour intensive your IT service is. In order to reach “cloud readiness” you need to be as close to fully automated as you can get but this is a huge challenge for organisations with existing infrastructures and processes. Let’s not forget that the biggest allocation of time on many IT tasks is not the execution of the work itself but the handoff between functions within the workflow. Therefor fixing this issue is not simply a case of automating the individual tasks but the complete workflow. This process does however give us our order of attack here. First analyse all of the workflows and use cases your IT team deal with. Look at it in terms of time taken to receive, execute and hand off the task. Pay careful attention to wait times as this indicates where the bottlenecks in your processes lie. Once you have a table of tasks identify the sources of work and targets for hand off. Keep it simple so that where a job requires a different function to complete a task during the process, record that as a handoff and then a new source when the work returns.

The diagram below is an example of a simple workflow analysis. Bear in mind that the times shown do not include the times whilst waiting for external teams or the inherent latency in moving tasks between teams or crossing horizontal lines into other domains in the diagram below. This can vary greatly depending on the other teams workload, prioritisation and internal process.

Once you have the list you can start seeing where a majority of your time is being spent. This process should be familiar to anyone that has spent time debugging the performance of a single server, watching the processes and IO wait times. It’s just at the macro scale. Target the large time blocks that are actual work first as this is the simplest task to automate as it remains within a team. Once you have automated as much of that as possible you can start work on the transition and wait periods. These are trickier as they can often cross political borders and may require negotiation and collaboration between teams. The more standardised your processes with clear ingress and egress procedures for work, the smoother this process will be.

Ultimately you will end up with your operations becoming ever more efficient. You may never reach 100% automation but that’s fine as long as you understand where you are not able to automate and why.

3. Sourcing efficiencies
Contrary to how this sounds the sourcing efficiency isn’t concerned with the ability of the IT department to source hardware and software, that is really covered by the resource efficiency element, rather this concerns the process users follow to provision services from IT. In most organisations this tends to be the hardest part of the process to get right. The reason being is that it’s difficult to provide a user choice without confusing them or offering too much. Most users of IT services have no idea about the underlying infrastructure or the physical requirements that the task they wish to perform places on it. They simply know what they need to get done and the parameters around that task that differentiate success from failure in business terms. A different team often has to concern themselves with security and compliance aspects of those tasks.

Here is where the first mistakes are usually made and why most simple application requests turn into big projects with programme managers and architects jumping in and adding to the timescales and costs. The IT department tends to ask the user for the technical requirements which then are not well understood and get translated to something slightly unique and non-standard. This is the road to having a collection of slightly different but similar servers being held together with scripts and customisations.

To avoid this scenario IT should ask business users simple, business questions and have a framework that transcribes these to match service offerings. The core component to this is an IT service catalogue, which describes a limited number of configuration options and provides the technical capabilities of those options.

Essentially this is a catalogue of components and the mistake a large number of organisations make is making this highly technical document available to their users to pick and choose from. This is the equivalent of a doctor sliding her catalogue of drugs across the desk to the waiting patient and asking “what do you need?” Expertise is needed to interpret those choices and make intelligent decisions. What you don’t want to encourage is your users to turn to Google in an effort to translate your catalogue and make their decisions based on false or incomplete assumptions. Instead, offer services that the user can understand at a higher level such as Email, business intelligence app, CRM.

If a new application is coming along then simply advertise the standard capabilities of your platform to the project team along with the standard interface points or Application Programming Interface (API). This will allow the developers of new applications to query the platforms capabilities directly and manipulate their own configuration in the micro chasm of their own tenancy.

So those are the three main areas of measurement when assessing your current Infrastructure and making some steps to push the needle towards readiness. I’ve included this diagram above that I often use when describing the readiness of an organisation, which provides a great executive view of readiness and helps describe the journey needed to get to the cloud.