This is a fairly simple classification for IT automation “levels” on teams or departments.

Each level reflects the organization point of view or state about automation, and my point is to help focus on where they’re at and where to put the effor to evolve.

To be honest, I do constantly find people thinking that “automation” is just about “building scripts”. It may be true in some isolated scenarios where the company or business model is just about… creating databases, providing infrastructure or any result from just some scripts execution.

But talking about web applications or services on corporate business, scripts are just part of the process that goes from the backlog to the production deployment: scripts are the technical execution steps in a chain that goes from the needs to the desired result. That why I strongly recommend to reach the third level for any company with several IT teams.

So, here are four levels of automation stages that I’ve seen many times in different teams at work and in other companies.

Best efforts

At the first level, IT automation is just about scripting: the personal interest and own initiative of technical people trying to optimize the most repetitive tasks.

Automation is seen as something useful, but there isn’t any strong investment from the management layer or consensus about how to do it.

Those scripts usually have hard coded parameters or configuration (paths, hostnames, etc.) and lie in the same servers where they’re executed.

The most common tools are just the bare programming languages, scripting shells (like bash or powershell) or specific product CLIs that the technical guys better know.

Managed scripting

In this stage, the scripting usage is not longer optional; is mandatory: all the team should use them to provide the same service level.

The most important milestone here is that there must be a “production branch” where the scripts are executed and a “development branch” where they’re built and tested. The script developer role appears here for the first time.

All the good practices in software development apply here: version management, testing, issue tracking, etc. Even naming schemes, parameters values and returns should be coherent between scripts in order to avoid confusions.

Common tools for this level are Red Hat’s Ansible, SaltStack, Puppet and many Infrastructure as Code frameworks.

Automation execution as a Service

At this level, the IT service is provided by a front user interface that manages script executions (usually as a self-service). It hides the technical complexity and gives a human readable response instead a verbose log a script could generate. It can even support workflows or service orchestration/integration for chaining executions and provide the desired service.

Here is where most cloud providers are at: you can create virtual servers, databases or configure an AI service from the web console of your favourite cloud service whitout worrying about the scripting and configuration behind the result you ask for.

This integration and orchestration requires a more specialized role: the DevOps engineer, with the goal of taking the requirements of the target service or product, identify the configuration and parameters needed and join the scripting exections to complete the task.

Some tools for this stage are VMWare’s vRealize or IBM’s Cloud Orchestrator.

Enterprise level service

Finally, in this ideal stage the company can use or invoke IT services from their business processes as any other business unit.

Imagine a company where as soon as a new employee arrives, all his IT resources like database access, security grants or user configuration are setup by the same internal business process started from the HR team.

I haven’t seen any comercial tool or product at this level; just a proof of concept of an internal development at my previous company where we built a BPMN based automation framework for IT operation.

Reaching this level is hard and relies on many departments; it depends more on the company focus than the IT team.