Anna Totterdell
Projects Director
The automation industry has a jargon problem. Every vendor pitch, every analyst report, every conference talk is filled with abbreviations and terms that sound important but rarely get explained.
This is not accidental. Jargon creates distance between the people selling solutions and the people buying them. If you do not understand the language, you cannot challenge the recommendation. And if you cannot challenge the recommendation, you buy whatever sounds most impressive.
Here are ten terms you will encounter in almost every automation conversation, explained in language that actually means something.
1. RPA - Robotic Process Automation
What the vendor says: "Software robots that automate repetitive tasks across your enterprise applications."
What it actually means: A programme that clicks buttons and types into screens the same way a human would. It watches what a person does on their computer - open this application, copy this field, paste it here, click submit - and replays those steps automatically.
When it works: High-volume, highly repetitive tasks where the underlying systems cannot be connected any other way. Data entry between two legacy systems that have no API, for example.
When it does not: Anything where the screen layout changes, the process has exceptions, or the underlying systems could just be connected directly. RPA is often a sticking plaster over a data and systems integration problem.
2. iPaaS - Integration Platform as a Service
What the vendor says: "A cloud-based platform for connecting applications, data, and processes across your organisation."
What it actually means: A subscription tool that lets you build connections between your software systems without writing code from scratch. Think of it as plumbing - it moves data from one application to another based on rules you define.
When it works: Connecting cloud applications that have good APIs. Syncing your CRM with your email platform, pushing form submissions into your project management tool, that sort of thing.
When it does not: Complex data transformations, high-volume processing, or connecting legacy systems that do not have modern APIs. iPaaS platforms are good at simple connections but get expensive and fragile when the logic is complex.
3. ETL - Extract, Transform, Load
What the vendor says: "An ETL pipeline that extracts data from source systems, transforms it to meet business requirements, and loads it into your data warehouse."
What it actually means: Taking data out of one place, cleaning it up or reformatting it, and putting it into another place. Extract is "get the data." Transform is "fix the data." Load is "put it somewhere useful."
When it works: Consolidating data from multiple systems into a single reporting database. Building dashboards, analytics, or AI models that need consistent, clean data from several sources.
When it does not: Real-time requirements. ETL is traditionally a batch process - it runs on a schedule, not in the moment. If you need data to flow instantly, you need a different pattern.
4. API - Application Programming Interface
What the vendor says: "Our platform offers a comprehensive REST API with full CRUD capabilities and OAuth 2.0 authentication."
What it actually means: A door into a software system that other software can use. Instead of a human logging in and clicking buttons, another programme can send a request to the API and get data back or make changes.
When it works: Almost always, when both systems have one. APIs are the standard way modern software systems communicate. If a vendor tells you their system has a good API, that is a genuine positive.
When it does not: When the API is poorly documented, rate-limited to the point of being unusable, or when the vendor charges extra for API access. Also when the system you need to connect simply does not have one.
5. Orchestration
What the vendor says: "End-to-end workflow orchestration across your entire technology stack."
What it actually means: Coordinating multiple automated tasks so they run in the right order, handle errors, and produce a coherent result. If individual automations are the instruments, orchestration is the conductor.
When it works: When you have several automated steps that need to run in sequence or in parallel, with logic to handle what happens when something fails. Order processing that involves inventory checks, payment processing, fulfilment, and notification - that needs orchestration.
When it does not: When you only have one or two simple automations. You do not need a conductor for a solo performer.
6. Low-Code / No-Code
What the vendor says: "Empower citizen developers to build applications without writing a single line of code."
What it actually means: Software tools that let people build automations or simple applications using visual interfaces - dragging and dropping components instead of writing code. The "no-code" claim is almost always an exaggeration.
When it works: Simple workflows, internal tools, and prototypes. If you need a form that collects data and sends it somewhere, a no-code tool will get you there quickly.
When it does not: Anything complex, custom, or performance-sensitive. Low-code platforms trade flexibility for speed. The more your requirements deviate from what the platform was designed for, the harder it gets - until you hit a wall that only proper development and build can solve.
7. Middleware
What the vendor says: "Enterprise middleware that bridges your legacy and modern systems."
What it actually means: Software that sits between two other systems and translates between them. System A speaks one language, System B speaks another, and middleware handles the conversation.
When it works: Connecting old systems to new ones without replacing either. If your ERP was built in 2008 and your new CRM needs data from it, middleware can bridge that gap.
When it does not: When the middleware becomes its own maintenance burden. Some middleware implementations become so complex that they need their own team to manage, and the "bridge" becomes a dependency that is harder to change than the systems it connects.
8. Webhook
What the vendor says: "Real-time event notifications via configurable webhooks."
What it actually means: An automatic notification from one system to another when something happens. Instead of checking every five minutes whether a new order has arrived, the order system sends a message the moment it happens.
When it works: Event-driven automation where timing matters. A new customer signs up, a payment fails, an invoice is approved - webhooks let your automation respond immediately instead of waiting for a scheduled check.
When it does not: When the sending system does not support them, or when you need guaranteed delivery. Webhooks can fail silently if the receiving system is down, so you need error handling around them.
9. Digital Twin
What the vendor says: "Create a digital twin of your operations for simulation, optimisation, and predictive analytics."
What it actually means: A virtual copy of a real-world process or system that you can use to test changes before making them. Adjust a variable in the model, see what happens, then decide whether to do it for real.
When it works: Manufacturing, logistics, and complex operations where testing changes in the real world is expensive or risky. If changing a production line takes three days and costs ten thousand pounds, simulating it first makes obvious sense.
When it does not: When the model is so simplified that it does not reflect reality. A digital twin is only as useful as the data and logic behind it. If the twin does not behave like the real thing, it is just a diagram with ambition.
10. Hyperautomation
What the vendor says: "A disciplined, business-driven approach to rapidly identify, vet, and automate as many business and IT processes as possible."
What it actually means: Automating everything you can, using every tool available - RPA, AI, iPaaS, low-code, orchestration - all at once. It is a term coined by Gartner to describe the trend of combining multiple automation technologies.
When it works: In theory, at very large enterprises with mature technology teams, significant budgets, and a high volume of standardised processes.
When it does not: Almost everywhere else. For most mid-market businesses, hyperautomation is a recipe for complexity, cost, and confusion. You do not need every tool. You need the right tool for the specific problem you are solving - which is exactly what good business automation scopes before it builds.
The real glossary test
If a vendor uses any of these terms without explaining what they mean in your specific context, they are selling you capability, not a solution. The right question is never "do you support orchestration?" It is "can you show me how this connects to our specific systems and solves our specific problem?"
Technology is only useful when it is applied to something real. The language should describe what happens, not obscure it.
