“I want to do private cloud because I want to be more agile and because I want to be much more efficient at IT operations”.

Um. Private cloud will most certainly help you with the first objective – it will stand up development, test and production environments (i.e. server/storage/network and middleware and dev, test and production applications) much more quickly. And it will “cut IT out the loop” allowing users to have their requests actioned without humans holding up the process.

But as regards using private cloud to make IT much more efficient, not so sure about that.

Actually, I think the answer is, “no – not directly, but yes, indirectly”.

Telco operators have been “doing automation” and using catalogs for many years. They have two concepts that will help us here.

  • They talk about “the service lifecycle” – this is where the service is requested to be built.  This is private cloud territory – standing up a test server, a dev environment, and so on
  • And they talk about “the consumer request lifecycle”. This is where a user makes a request against an existing service. These are things like adding a user to a service, deleting a user, changing capabilities, and so on

There are, of course, many many more “consumer requests” than there are “service creation requests” in a telco.

And the same is true for private cloud in an enterprise. In a reasonable sized organization during any month, there may be 50 requests for a new development environment, 50 requests for test environments and systems to test against, and 20 requests for production systems.

But during the same period, there may be thousands of “consumer” requests in IT. In fact, if we broaden out our consideration to not just consumer requests, but IT automation in general, we see that potential efficiency gains thru the use of automation are huge:

  • Automation of “consumer” requests – add an email user, add more capacity to an email user, delete and email user, change her name, add a public distribution list, add a sharepoint, change a sharepoint type, etc
  • Automation of incident remediation – modern service management systems are able to associate an automated remediation workflow with each type of problem that can occur. Typically, a number of flows are initiated for each problem. For example, if we have a problem with a switch, we would fire off a workflow to collect the switch’s log as fast as we can. After we were happy it was a switch problem, we’d have a flow reset the switch. And then, once the reset is done, we’d have a flow to test the switch and check the logfile. These are not exactly mega-exciting flows and each one only lasts a few minutes, but there are thousands of them a month, so they quickly add up to good efficiencies. As we get more sophisticated, we can have these flows “play in the ITIL world” – they can update the CMDB if changes are made; they can tell the service desk what they are going to do, what they are doing and what they did.
  • Automation of change requests – an IT department and a service desk generates a lot of “internal change requests”. Things like upgrading software to the latest version, adding memory, moving stuff, consolidating stuff, and so on. We can automate this. This is heavy workflow and it must integrate with our change management systems and our CMDB. Such a workflow may include a/ putting in a RC b/ waiting till the RFC is signed off c/ setting system state and dependent system states to “under maintenance” d/ updating service desk state e/ making the change f/ checking the change worked g/ updating service desk status h/ setting the systems and their dependent systems to “running”.  There are fewer of these than there are auto-remediation and user-requests, but they are complex
  • Automated compliance scanning and remediation.   In order to achieve continuous, rather than “once a year just before the audit” compliance, we need automation. And we need automation to fix compliance errors should we find them. There are many such tasks performed every month.


So, we may have 120 private cloud automations per month, but many thousands of “non-cloud” automations during the same period. Each private cloud automation is valuable – there is more to this than just numbers of automation. But in order to really improve IT efficiency, it’s the thousands of general automation tasks we need to look at. 

Why then, am I talking about this in a cloud blog? Because when you have private cloud (at least, HP’s private cloud) you can use this for more general automation too. You have an orchestration engine. You have the ability to automate server tasks. You have the compliance monitoring and remediation. And you have a catalog into which you can put your “consumer request” options. You may need to add things like network and storage automation (which the private cloud system can also use), and you may find you need to increase license sizes – but the base system for wider automation is in place.

And this “evolution” is something we see a number of customers doing. A European customer started by providing private cloud production services for their networks and servers in the data center. Once they have done that they, “took a step back” and put in place more general automation across the datacenter.

I’d like to go back to the “private cloud and efficiency” argument. I think that more general automation can give you more efficiencies than putting in private cloud. But private cloud gives you something else. Thru its agility it gives the business the ability to generate more profit because applications will better track the needs of the business. And that is almost certainly worth more to the company’s bottom line than IT efficiency. The sad thing is that IT probably isn’t measured on the contribution it makes to business profitability – but its private cloud can very positively affect it, non the less.