I mentioned in the last blog post that one of the issues I had with a Microsoft Private Cloud POC I built for a subsidiary was that it was too focused on a technology solution for a specific business problem. The problem with trying to launch an initiative like cloud that is as one dimensional as getting VMs built quickly, is that it is often difficult to articulate or justify what the time saving will actually mean in terms of offsetting against the effort and cost required to implement this new capability.

Getting VMs to developers when they need them doesn’t necessarily need automation and self service, it might just mean having better processes and being better at planning. This is a fair argument I have heard made when discussing merits of Private Cloud adoption in scenarios relating to agility.

I guess my argument is that there is a difference between speed and agility and that process and planning might make sure you get things when you need them, but if you need to change direction quickly then having manual processes or stopping to re-plan, actually impedes agility.

The mantra ‘fail fast, fail often’ that often accompanies the adoption of agile development, or more of a prototyping type mentality to building new services, often means requirements will change or that you discover something you thought might be a good idea actually isn’t. The value is weeding out the bad ideas early and progressing to the next, to prove the good one that will deliver business value.

The challenge that I have found in my own experience is that as you move up the management food chain you are faced with people who built their careers on waterfall development and project methodologies like prince2 where they are delivering big projects over a long period of time with the pay off at the end of the project, the ‘go live’. Lots of planning and scheduling and no real need for servers to be provisioned dynamically as and when required as the requirement’s are typically fixed. If agile and prototype development requires a shift in mind-set, then throw DevOPs, continuous delivery and the like into the mix and watch the paroxysms of the IT dinosaurs as the IT landscape starts to move underneath their feet.  As an infrastructure guy brought up on Wintel client / server these new paradigms were as difficult for me to accept initially!

The businesses expectations of IT are also changing. I don’t really need to cover the consumerism of IT in any great detail, or the fact that business users are now far more tech savvy and have far greater expectation of corporate IT, as it is a well established fact. The days of IT dictating one model of PC, laptop and phone are long gone, the days of IT having a monopoly over IT provision are long gone, the day of IT being the technology experts and being able to pull the wool over the eyes of their users are long gone.

The business doesn’t want a year long waterfall project to build a solution to deliver a business benefit, if they can consume a SaaS service via a credit card in the space of a few minutes, test and then scale within days or weeks. The additional bad news for IT departments is that IT companies know this and target the business users of their product rather than the IT function; before you know it the solution is in and you are supporting it. ‘But!’ I hear you say ‘we have corporate IT policies around software only being purchased by IT!’ ‘The business users can’t just buy software!’. Good luck with that… try using that argument with your Chief Finance Officer or the Chief HR Officer: its already too late and to be honest who can blame them if we as the internal IT functions are taking too long to deliver it and it costs far more to do so.

If IT departments (and I mean the build and run teams or Infrastructure and Operations in Gartner speak specifically – NOT development areas) are to be relevant and add business value going forward, then we need to reposition ourselves and take a good look at the services we want to offer and the ones where frankly we cannot compete.

This is where as an overarching strategy of IT as a Service (ITaaS) is in my opinion a better reflection of the service models we are trying to adopt, then just stating Cloud, whether Private, Public or Hybrid as the end goal. ITaaS in my opinion describes how IT will fulfil two roles:

IT as a Service Provider
IT as a Service Broker

Cloud is typically an enabler for this, whether building the private clouds to deliver services internally more consistently and more quickly, or brokering in a hybrid model to other service providers. But it is not just about building servers quickly, its about delivering all sorts of services that are consumed via business users using models that embrace Cloud characteristics.

So the Blog is called Cloud Journey and already I’ve started to contradict myself already by saying that actually ITaaS is what we need to be aiming for, but hopefully the logic of it makes sense. This is MUCH bigger than provisioning VMs quickly, it about how IT becomes more focused on the services the business needs and repositioning, retooling, re-educating and refocusing its efforts in order to better support the business.

If delivering VMs quickly is a strong enough requirement for Cloud for you then that is fantastic and you should be able to demonstrate business value quickly and easily. However for my organisation it was clear that the scope needed to be wider and look more fundamentally at what services we offer and how we offer them, in effect how are we going to do business with the business in future?

The next blog post is going to look at some of the resources that have influenced my approach and thoughts to ITaaS and cloud adoption and ultimately helped shape our Cloud Adoption Strategy.