I'm a massive fan of IT
Automation and I really enjoy doing it (especially the coding part),
but at the same time I am realistic about the benefit of it.
I think there was a
quote “if you do anything more than twice (in IT) automate it”.
This is a fine thing to say, and yes, in an ideal world where you
have the time to invest to automate all your tasks, it makes 100%
sense, but in the real world it does not necessarily make sense.
My point is best
illustrated with an example.
Example:
Say I have a manual
task, this manual task takes up 10 minutes of my time, and I
have to do it every week. So that's 520 minutes a year.
Now, say my manager
says “you must automate it”. Okay fine. But how much time do I
need to invest in automating this process.
Say it takes me 40
hours to automate this process (2400 minutes). That means that to
start saving time, it's got to have run for over 4.5 years
(2400/520). And that's not considering the fact that the
automation might need updating in that time, constant monitoring that it runs, troubleshooting when it doesn't...
My point is this:
When considering
automating something, also consider the investment in time in
creating that automation, and when you will start to see time savings
from that automation.
Unfortunately this seems to get forgotten in the drive to “automate
everything”.
Q: How much time is
being spent creating the automation?
Q: When will you
actually start saving time from the automation?
Some automations will
never save time. Still, a benefit in going through the process of
automating something that will never save time, is that potentially
you develop tools and methods that can be used to automate something
of more value in the future, and that thing will have clear time
saving benefits.
Don't get me wrong
though, there are massive benefits to be had in IT automation. Some
task that regularly needs to happen is a perfect candidate for
automation. Or a particularly complex task that won't happen often,
but when it does happen you don't want it go wrong (like a
Disaster Recovery workflow), is also a good candidate for automation.
And many other cases...
DevOps Doesn't
Work With Everything
I
also think some people are getting too caught up with the word “DevOps”.
DevOps is great for software that needs/benefits from constant
evolution. But for a write once and forget application, there's
really little point in shoe-horning it into a DevOps process, it just
complicates things and wastes time.
End
of ramble.
"Never spend 6 minutes doing something by hand when you can spend 6 hours failing to automate it."
ReplyDeleteWell said Anonymous!
DeleteHello Vidad,
ReplyDeleteI found this very similar to Solar Energy also. You will only start to retrieve benefits at certain point... But in IT clock probably when you get there, the solution is already different and you have to re-code again.
Maybe sharing the code...could help others to automate the same thing, and that i think is the way.
PF
Hi Pedro,
DeleteI totally agree that sharing the code would be the way forward. Alas, a lot of awesome code is developed within the walls of large enterprise or secure customers that will never see the light of day.
Really, every IT person needs to have a blog, and when they do something interesting/useful, they should post it on their blog (removing any customer specific stuff and heeding intellectual property laws), then one can just google and find loads of awesome stuff :-)
VC