An API is like a bridge, a file I/O batch is like a ferry, and RPA is like a raft. Which one would you choose?
A large healthcare customer of ours recently used a fantastic metaphor to describe different methods to connect enterprise systems.
Imagine you are responsible for getting people across a river from one city to another.
You have different options for getting the people across the river:
|Suspension Bridge Fast, reliable traffic between the cities||Ferry Boat Reliable transit, but forces people to wait for the next boat||Flotilla of Rafts People will get wet|
Now, let’s imagine the two cities are systems in your enterprise, and instead of people, you need to get data from one system to the other. Maybe you need to automatically update customer records in Oracle, purchase orders in SAP, or employee data in Workday.
You have different options for this, too:
|APIs Fast, reliable data transfer||File I/O Batches Reliable data transfer, but not real-time||GUI Automation Slower data transfer and prone to breaking|
APIs should be your default method for automatically pulling or updating data in systems. Just like the suspension bridge, they’re real-time, fast, and reliable for the long-term. Most modern SaaS applications provide APIs, and applications like Catalytic provide turnkey integrations for you to get connected within a couple minutes. Many organizations will build and manage API connections to on-premise and legacy applications by taking advantage of tools like SAP Cloud Platform Integration and Oracle Integration Cloud. APIs are also easy to govern and manage, since the access rights can be controlled with users and tokens that are easy to enable and disable.
File I/O Batches have been around for a long time and have not changed much. A common approach here is to generate a CSV file that has multiple record additions or updates and drop it in an SFTP folder that is monitored for automatic import into the system of record. This can be a useful approach when a system does not have APIs available, but it does have the ability to generate flat-file or spreadsheet reports and import batches of records in the same format. The downside to File I/O Batches is that they are not real-time. Typically, files will be auto-imported once a day, which is sufficient for some use cases, but far too infrequent for others--for mission-critical data the ferry boat will be too slow.
GUI Automation (aka screen automation or surface automation) automates the clicks of the mouse, typing of the keyboard, and screen scraping to simulate the work done by a person within a system. It is the predominant method that’s used by Robotic Process Automation (RPA) providers like UiPath, Automation Anywhere, and Blue Prism. There are 3 main challenges with GUI Automation:
- It’s brittle. The “bots” are prone to errors and need constant maintenance whenever the UI changes or sometimes when the UI controls are in an unexpected position or state. In our bridge metaphor, these UI changes are like a rush of water or inclement weather that destroys the flotilla of rafts, whereas the suspension bridge is unaffected.
- It’s slow. The equivalent of a single API call (that can be completed in milliseconds) often requires a dozen or more GUI Automation actions each with a necessary time lag.
- It needs a dedicated environment. Unlike APIs and File I/O Batches, GUI Automation requires a computer or virtual machine to simulate the actions that a person is performing. The suspension bridge can hold hundreds of cars across lanes on a highway, but the flotilla of rafts needs people to walk in a single file line.
Considering these three different methods of connection is especially important when you reflect on the complex landscape of systems in most organizations. It’s not simply connecting two cities across a river. It’s more like connecting hundreds of islands of an archipelago. You may not be able to construct suspension bridges between all of them, but you’ll want to use the best available method of connection for each one.
At Catalytic, we take a flexible approach to integrations, supporting all three types discussed above. We have a clear bias toward which is the best, but our belief is that it’s always possible to get data in and out of systems in an automated way--you simply need to explore these different methods.
Want to talk APIs and archipelagos? Connect with us!