Originally posted on LinkedIn
Some thoughts utilising my experience as an independent consultant & director as well as an advisor to many of NZ’s largest companies on how we can improve technology use in business in the future using cloud, business analysis and better stakeholder engagement to drive better business outcomes for all.
I (Ben) am from a technical background in software development, infrastructure and web development which means I love technology such as Linux, SQL, MySQL, Powershell etc.
As a technical person sometimes buzzwords like automation, IaaS, Saas switch me off because they can get used and abused a lot as something that is the “latest and greatest”.
From my perspective, automation has been around for at least 15 years, probably longer. I started my career as a data analyst and management consultant in The Forestry Industry which has a number of automation processes already well established. For example in the late 90’s I remember visiting timber mills where hardware and software was used to measure, prepare and cut timber for production export.
Getting back to how this relates to the IT world, I could say my first automation project was working for the Ministry of Social Development in NZ where I was involved in a massive infrastructure rollout of Windows 2000 desktops and servers.
For this project, rolling out desktops manually to 100 or so desktops could make sense with 5-10 desktop engineers on the ground. But this was an environment with over 8,000 desktops, hundreds of servers and distributed offices with minimal IT staff.
So automation was done using traditional software development methods, existing desktop imaging products and a project team consisting of myself as a QA engineer, Perl developers, Engineers, Systems Architects and using your standard, out-dated Waterfall SDLC approach.
I was impressed at the level of complexity we had baked into the automation system. Of course using Perl and associated software we ended up with 100,000s of lines of code which needed to be maintained. This was well before any of today’s simplified automation frameworks such as Ansible, Salt Stack, Powershell DCS, Chef and Puppet.
On that note testing was completely manual, which meant testing every script against all desktop configurations. Nowadays we can completely automate unit and configuration testing using automated testing frameworks such as Selenium. And we can be Agile while maintaining quality code and deployments – no more surprises as in the days of Waterfall projects.
If you’re considering automation think about how it benefits at scale, for example it doesn’t make sense for a small environment necessarily, but when you hit 10-20+ servers and more complex applications then automation really adds a lot of value. Why? Because the initial time invested reduces repeatable tasks such as installation, upgrades, patching, monitoring in the future so you don’t need to spend hours doing one manual task.
This helps you to focus on what you’re good at.