Enterprise automation technologies can help organizations reduce their reliance on human effort, but understanding the different types of tools is key.
The majority of automation in the IT world happens "under the hood" of our systems and tools, which hide their inner workings from us. Volume failover in RAID arrays in the storage infrastructure, BGP route failover in a router and form field auto-population via a web browser all bespeak sophisticated, hidden automation of tasks that were once manual.
In between manual operations and fully submerged automation lies the world of ad hoc automation: people using a variety of tools to automate parts of their work life. Tools range from very old-school, that is, writing short programs, to very new, for example, cloud-based event-driven integration engines.
Traditional scripting options are many and varied and are still important types of enterprise automation technologies. They include the following:
shell scripting in all the various UNIX and Linux shells;
PowerShell on Windows systems;
cross-platform languages as varied as PERL and Python; and
application-specific languages, such as SPSS's command syntax.
To be useful for ad hoc scripting, tools should interpret a language, not compile it. They should also expose to the person writing the script a broad set of options for working with relevant entities: files, user accounts, system resources such as storage devices, network connections, and so on. Ideally, a scripting language will be relatively easy to get started with, but powerful enough to accomplish a huge variety of system and network management tasks. In essence, working at a programming level should allow the IT professional to manipulate any aspect of a system. It should provide the ultimate in reach and capability, even if it has a steeper learning curve than some other approaches.
Low-code automation engines
Perhaps one of the most talked about automation technologies is low-code automation. These systems make automation easier for non-IT users, presenting them with a variety of visually oriented tools that reduce or eliminate the need for actual code writing.
Ideally, a scripting language will be relatively easy to get started with, but powerful enough to accomplish a huge variety of system and network management tasks.
In low-code automation systems, users can automate tasks by building flow charts, for example, or filling out templates of actions and answering questions about what they are trying to accomplish. Such tools can provide help with extracting and parsing the contents of files and establishing connections to other systems. In a well-designed tool, IT can pre-build some components for other staff to use and establish guardrails that prevent common errors or enforce good practices.
On the plus side, low-code systems can dramatically lower the barriers to entry for automation. Almost anyone in an organization can learn to use these tools, and they make it easy to automate typical knowledge worker tasks and workflows. Low-code systems can be less useful for systems and network admins. This may be due to lack of complete access to system functionality. For example, the low-code tool may not be able, or allowed, to do things a sysadmin wants to do, such as force a reboot on a server. In addition, a skilled scripter can probably write a script for the same task more quickly than someone can develop an application in a low-code system. Executing automation may also be slower in the low-code environment than in a scripting environment.
Event-driven integration engines, or iPaaS
Recent developments in the low-code market focus on the kinds of automation that span systems.
Event-driven integration engines, such as automate.io or tray.io, watch for events in one platform -- usually a SaaS system, such as Notion or Slack -- and take action in response, most often initiating action in some other system. For example, posting a new message in an "ask the expert" chat group in one system might trigger an action that replicates the post in a help desk ticket in a different system.
Such tools are usually cloud based, and such systems are referred to as "integration platform as a service" or iPaaS tools. IPaaS systems can act as simple cross-platform triggering engines, as just described, or they can do more. Instead of simply triggering a single action, with replicated data, an iPaaS system can perform complex transformations on data, reach out to other systems to retrieve more data and trigger actions in multiple systems rather than just one. These systems are low-code, with real emphasis on ease of use based on the assumption that the folks using them aren't likely to have programming experience. The goal is to enable quick integrations across systems with a minimum of labor.
Unlike the other tool types discussed here, iPaaS tools tend to be "pay by the drink" SaaS offerings: You pay based on the number of actions you set up and the number of times -- per second, hour, day or month, variously -- that they are triggered.
Declarative automation
Ansible, CloudForms and other declarative automation tools focus on the work of network and systems administrators. Declarative systems automate configuration work not as a series of commands -- for example, "enable P, enable Q, enable R, disable S, disable T, disable U" -- but rather as a series of assertions about how things should look and work -- "A functioning system will have settings P, Q and R enabled, and settings S, T and U disabled." IT staff say what should be, not how to do it. The tools are responsible for bringing managed devices or services into those states.
This is a considerably different form of automation, verging on the "hidden" style, and one intended to shift focus from methods to outcomes. This focus on the desired end state is a powerful way to make it easier to achieve, especially when the end state is a complex one, since the whole point is to describe that state, rather than the step-by-step process of achieving it.
Declarative automation tools require modules for each kind of system they will manage, or each cross-platform protocol someone can use to configure systems of multiple types. Such modules will be available for major platforms, usually, but may not be present for less common or older ones. The tools themselves often rely on YAML as their configuration description language.
However created, automation will continue to be a key focus of IT for the next several years, as the tumult of post-COVID technology and talent development adaptations needed for a hybrid workforce, the "Great Resignation," cloudification and a demographic dip in the labor pool for IT continue to play out across all industries and sizes of company.
About the author John Burke is CIO and principal research analyst with Nemertes Research. With nearly two decades of technology experience, he has worked at all levels of IT.
