How many times as a developer or IT admin have you wondered “Should I automate this?” Here is a simple framework for thinking about this decision tailored to hybrid cloud.
This is a two part blog post about making automation decisions.
It’s really worth taking the time to think through this. Both from the perspective of an individual making decisions about automating tasks. And, as an organization making decisions about automating hybrid cloud management. Fortunately – the same decision framework works for both.
As an engineer, I asked that question to myself many times. Can I write a shell script or Python script to do what I’m about to do manually? Should I use an orchestration tool?
You can apply a bit of math in order to play with different variables and analyze their impact on your decision. And it’s best to think about this in terms of return on investment, and consider your investment of time and effort as a quantifiable cost. Time is money, right?
Generally, it makes sense to automate a manual IT process if:
1 – You can run the automated process a large number of times to spread out the cost of the automation capability (development, testing, and ongoing maintenance).
Pattern – “I’m going to do this task 100 times in the next year and I can spend an hour writing and testing a script to add to my bag of tools.
2 – Each automated execution has lower cost than you doing the work manually.
Anti-Pattern – every time I run the automation I end up spending more time tweaking things because the environment or process keeps changing, than it would have taken to just roll up my sleeves do the work.
This is a bit wonkish – but these simple ideas can be expressed in a model developed by Brown and Hellersten at the IBM Thomas Watson Research Center.[i] We can then use this model to “tweak the knobs” and consider the impact of different variables on the “Should I automate?” decision.
The model compares the fixed and variable costs of manual process versus automated version of the same process. The cost calculation is based on the variable N, which represents the number of times the automated process will be executed.
Consider 4 key variables
1 – Manual fixed costs – cost of developing the manual process. How much does it cost to produce a box of ball bearings? 1st you need a factory (manual fixed cost) then you need some steel rod and 5 minutes labor (manual variable cost). But don’t dwell on that “factory cost” as it drops out of your final decision calculation.
2 – Manual variable costs – the amount of time and effort involved each time you do the work manually. Think of this is the pain you are trying to eliminate. Every time X lands on your task list – you are about to experience manual variable cost.
3 – Automated fixed costs – this is the cost of the tools you need to support automation. Python or Perl – no problem. Orchestration tool or cloud management platform – need to get PO approved.
4 – Automated variable costs – the amount of time and effort involved in doing the work. Ideally it is close to zero. But in reality, automation doesn’t always work and you have exceptions or failures that need to be manually addressed.
We can then solve for NT which we call the Automation Tipping Point. This represents the cross over point at which it becomes cost effective to automate the process. Keep reading. This will get interesting.
As seen below, automation is justified when NT is greater than the ratio of automation fixed costs divided by manual variable costs minus automated variable costs.
Lowering the tipping point
Lower is better. If you could wave a magic wand you would create an “easy button” for everything you do and NT would equal 1. But consider the impact of your reality on this ratio. IF the numerator goes down – tipping point goes down e.g. it is easier to justify automation. If the denominator goes down, the tipping point goes up e.g. harder to justify.
- Automation fixed costs – if the cost of automation platform goes down, then you can more easily spread that cost out and justify automating a specific task. Makes sense.
- Manual variable costs – if doing things manually is getting harder, then you can more easily justify the cost of automating that task.
- Automated variable costs – if you have more process failures or have to manually handle exceptions, it makes it harder to justify automation. This is key.
I’ve used this framework for years as a tool for thinking through the automation decision. Both for my personal task automation, and for bigger tool purchase decisions
In the next post…
I’ll apply this to the decision to automation deployment of applications in a hybrid cloud management scenario.
In that scenario, we’ll assume:
- Self Service – The person who creates the automation isn’t the user of the automation –you are giving someone else an easy button. So the automation needs guardrails to control the automation. That can that increase automation fixed costs, which can raise the tipping point.
- Hybrid – Different environments may need different automation tools. Application and infrastructure automation tools may be separate. And automation of both application and infrastructure may be hard wired to the environment. All of which drives up automated fixed costs even further. And raises the tipping point.
- And the variability of different datacenter and cloud environments increases exceptions and variation that must be handled manually, which raises the tipping point.
Seems like free is always better. But sometimes “Free” means free like a “Free puppy”.
That is why a good cloud management platform like CloudCenter can demonstrate real hard value when you are automating application deployment and management across different datacenter, private and public cloud environments.
More on this in part 2.
[i] Reducing the cost of IT Operations – Is automation always the answer? IBM Thomas J. Watson Research Center. Proceedings of the 10th conference on Hot Topics in Operating Systems, June 12-15, 2005, Santa Fe, NM