An evolving dictionary of Intelligent Automation

When I was actively involved as a researcher, it was a running joke (and also a truism) that scholarly distinction wasn’t earned through originality, but through the invention of new terms to describe old things. The same is most certainly true when it comes to industry jargon. And it’s especially difficult to keep up with terms used to describe the use of artificial intelligence to automate business processes.

The following is a list of common — and frequently confused — terms. This is an evolving field, and in some cases there is still no general consensus around terminology. If you feel a term is missing, or a definition is lacking, please leave a comment below.

Autonomous Enterprise

Sarah Burnett (2022) simply describes an autonomous enterprise as one in which most, if not all, high-volume, repetitive, and transactional business processes that make up core business functions are automated. According to Burnett, key characteristics of the Autonomous Enterprise include:

  • Conducts core, daily business functions using AI, with minimum human touchpoints
  • Employs people who are required to perform few repetitive tasks
  • Empowers staff to automate repetitive tasks for themselves
  • Uses operational data to create digital twins in order to identify inefficiencies and improve processes
  • Analyses operational data to support strategic decisions, including risk management and innovation

Autonomous Operations

Most commonly, the term is used to refer to the operations of vehicles, heavy equipment and physical robots in ways that make use of webs to sensors and AI in order to automate things like transportation, manufacturing, mining, agriculture, and the like.

For the sake of clarity, I would recommend the term ‘Autonomous Business Operations’ to describe the use of AI to automate decisions, actions, and self-learning in the business process domain.

Decentralized Autonomous Organization (DAO)

Decentralized autonomous organizations (DAOs) are blockchain-based organizations fed by a peer-to-peer (P2P) network of contributors. Their management is decentralized without top executive teams and built on automated rules encoded in smart contracts, and their governance works autonomously based on a combination of on-chain and off-chain mechanisms that support community decision-making.

Santana & Albareda (2022) Blockchain and the emergence of Decentralized Autonomous Organizations (DAOs): An integrative model and research agenda


Hyperautomation is not a thing or a specific set of technologies. Instead, it is an organizational mindset according to which everyone is automating everything that can be, all the time.

Intelligent Automation

While many definitions would tie the term Intelligent Automation explicitly to particular kinds of technology (i.e. as the combination of Business Process Management (BPM), Artificial intelligence (AI), and Robotic Process Automation (RPA), I prefer the more common sense and technology-agnostic definition proposed Coombs, et al (2020): “the application of AI in ways that can learn, adapt, and improve over time to automate tasks that were formally undertaken by a human.”

Virtual Enterprise (VE)

A virtual enterprise (VE) is a temporary alliance of businesses that come together to share skills or core competencies and resources in order to better respond to business opportunities, and whose cooperation is supported by computer networks. (Wikipedia)

Bots don’t care if you live or die

The best approaches to automation don’t automate everything. Where processes are automated, exceptions are bound to happen. And when those exceptions happen it’s important that humans are able to address them…especially when the life and death of humans are concerned.

When too much is automated, humans lose skill and vigilance. They become less responsive and less capable when things go badly. It’s for this reason that responsibly-built airplanes automate less than they can, and in fact intentionally build friction into their processes.

A bot doesn’t care if we live or die, succeed or fail. That’s why a robust approach to hyperautomation must consider, not just whether a process CAN be automated, but also whether and the extent to which it SHOULD be.

How American musket manufacturing paved the way for low-code software development

The early days of computing relied on mechanical devices. From the abacus through to Charles Babbage’s engines, these devices — much like the modern computer — were developed to increase the speed with which individuals could perform calculations in support of commercial (accounting, insurance), scientific (especially astronomy), and military applications.

The purpose of these machines was not to perform mathematical operations that were impossible by human beings, but to really democratize access to mathematics in much the same way as the printing press democratized access to the rest of human knowledge.

The history of computing is concerned with automating mathematical calculation in support of some practical end.

As a result of the mechanical nature of these devices, it should come as no surprise that there is a strong relationship between computation, mass production, and the military.

Manufacturing muskets in the 18th century

Up until the mid-18th century, armaments needed to be built by skilled craftsmen using custom fitting parts. The move toward standardization and the ability to measure with exacting precision made it possible by 1765 to produce interchangeable gun carriages.

By 1785, Honoré Blanc’s experiments with interchangeable musket parts came to the attention of Thomas Jefferson, who saw Blanc’s vision for interchangeability as a solution to a chronic shortage of skilled craftsmen in the US, which made the US dependent upon Europe for most of it weapons manufacture.

In 1798, based on his vision for a water-powered machine tool, Eli Whitney won a contract to deliver 10,000 muskets to the US War Department despite having no factory, no workers, and no experience in gun manufacturing.

Whitney struggled to deliver, so in the same ‘fake it till you make it’ spirit that characterizes modern Silicon Valley, Whitney bought some time through a demonstration of what he called the Uniformity System in 1801 the demonstration was likely faked. He was only ever able to deliver 500 muskets, none of which had any interchangeable parts.

Despite early failures of the Uniformity System, the vision remained, was eventually perfected by John Hall in 1827, and became known as the American System of Manufacturing.

Low-code, craftsmanship, and competitive advantage

What does this have to do with low-code software development?

Just as in the early days of American weapons manufacturing, today specialized craftsmen are in short supply. by the end of 2021, there were nearly 1 million unfilled IT jobs. And by 2030, the number of software job vacancies is expected to rise by almost 22%.

And just as in the early days of American manufacturing, a heavy reliance on professional developers (craftsmen) means that reuse is limited, patching is difficult, and quality is inconsistent.

Looking back at the history of manufacturing, the ‘app factory’ metaphor is a powerful way of describing the value of low-code approaches to software development. It would be silly to hold on to old notions of craftsmanship (which are slow, inconsistent, and non-interchangeable) when there are wars to be won. And it is just as silly to hold on to romantic notions of craftsmen approaches to software development when the global landscape across every industry is as competitive as ever.