Systems Integration — The Power of APIs

This is a general guide to post-pandemic business management; it is not a technical IT document.

If you have done your systems overview, or a system overhaul (if need be) and migrated most of your systems to the cloud, you will realize that most of these systems do not speak to each other. They are born that way. You need them to talk to each other, so you have to introduce them to each other, and teach them how to talk. That process is known as Systems Integration.

Some modern systems are born ready to talk to others. The ability to talk to other systems is a desirable feature. It is made possible by an open API. This is an acronym for Application Programming Interface. This is essentially a connection point between two computer programs or systems. The reason why it's called an application interface is that it allows other applications to connect to the system. In contrast, the user interface allows a person (human user) to connect to the system.

When an API is said to be open, the standard or specification for that system’s API is disclosed to the public, for all who want their systems to connect to the relevant system to be able to follow the instructions and connect.

The power of the API lies in its ability to eliminate data capturing and duplication of efforts. This obviously results in time and costs savings. It also results in data that is consistent across the entity.

The most common redundancy across organizations is that of capturing the same data twice. Government departments are the worst when it comes to this, but almost every company has data redundancy problems due to using multiple systems that do not have open APIs.

The most burdensome form of redundancy and duplication of effort exists between Enterprise Data Systems and Accounting and Reporting systems. Client data is often captured in the Enterprise System by the originators of transactions, typically okes from Sales and Marketing. The same data is captured again in the accounting system by bookkeepers and debtors’ clerks. Data that is captured in the Warehousing and Inventory system is often captured again by the creditor's clerk because the stand-alone inventory system does not have a live integration with the accounting system.

Data captured in the CRM system is often captured again in another system. Data captured in Productivity Apps such as MS Excel is often manually captured again in the CRM system, or in the Accounting System. Data captured in the communication apps is usually captured again (now in an organized format) in other systems (CRM, Practice Manager, file storage, productivity).

Entire job roles exist for capturing data (i.e., Data Capturer). It ought not to be so. Those resources can be used for other things, unless if the sole goal is to employ people, whether it is productive or not.

In the pre-pandemic business environment, it was acceptable for files to be printed from one system and leave the big pile in front of the Data Capturer, awaiting to be captured into the other system.

The perfect entity, the one desired by the post-pandemic business manager, aims to capture data only once and let the data flow from one system to another, without too much interference and re-capturing.

The desirable way of achieving this “data flow” from one system to another is via the API. The post-pandemic business manager should contact coders that can make use of APIs to connect the disparate systems that are used in his/her organization. APIs are basically instructions, but not everyone is good at following instructions, so it makes sense to leave the job of writing the script that connects systems to an expert.

It is the duty of the business manager to pursue this seamless flow of data between systems. The end goal is the maximization of profit. That being noted, the entity that fails to tick this box in the post-pandemic business environment might find itself lagging behind competitors, burdened with a heavy cost structure and data that is unreliable for decision making.

APIs are ideal for live integration. However, they are not the only solution available. For practical purposes, one might want to make use of other integration methods.

  • Zapier
  • Batch Uploads
  • System Forms

Zapier (powered by a company called Zapier) automates the task that involves taking data from one system to another. They essentially build APIs between the most commonly used systems so that you don't have to build one yourself.

Zapiers are very useful in automating tasks between communication apps and productivity apps, and vice versa. An example of a quick zap would be that whenever you get an email with an attachment, the zap should save the attachment in a Dropbox folder. Another zap could upload the files in the Dropbox folder onto Receipt Bank, which would then process any document that looks like an invoice/bill straight into the accounting system.

Another example would be to auto-populate a Facebook lead onto a Google Sheet so that you don't have to manually capture data regarding that lead. Zaps work well for commonly used web applications.

Beyond zaps, a very simple form of integration can be implemented. Frequent batch uploads are not exactly live integration, but they work well where live data is not a priority. Most systems allow for batch uploads of data using a CSV file. Data can be exported from one system, customized as a batch, and imported into another system. This can be done regularly to the desired frequency. Batch uploads save time, they ensure consistency of data formats and nuances such as naming conventions (e.g., Name Surname vs Surname, Name). Batch uploads are the default type of integration if you are dealing with legacy systems.

Another way of ensuring data capturing is automated is by using forms. It is not really integration, but it improves the data flow between systems. Most systems allow data to be captured in forms. For accounting systems, creating an invoice is basically populating a form. For CRM systems, forms are typically the default input mechanisms. Web-based forms can be developed, where clients or users can populate their data once. The forms feed the data into the system, which then feeds data into other systems (using APIs, zaps, batch uploads, or other forms). Thus, the company totally eliminates the capturing of data that can be captured by users/clients (e.g. bio-data).

The excitement that comes along with integrating systems should not blind the business manager from implementing quality control measures across the data flows. There will be times when the data flow needs to be halted, checked, and then released into the next system.

A case in point is the integration between the accounting systems of two companies. Company A buys from Company B, they both use Xero's online accounting package. Leveraging on Xero-to-Xero Connect, Company B can send its invoices straight into Company A’s accounting system. The sales invoice in Company B becomes a supplier invoice (i.e., bill) in Company A. Let's say the number of invoices sent by Company A comes to around 100 a month, the time saved on data capturing is significant. Moreover, accuracy is retained because Company A gets exactly what is generated in Company B (same dates, references, description, quantities, price, and tax amounts).

This is exciting. However, the business manager in Company A must implement checks before approving the invoices (the correct terminology is “bills”) coming from Company B. They need to correspond to purchase orders (if any), and they need to ensure that they correspond to what was delivered.

The point here is that integration, even though it reduces errors, does not guarantee that the data received is always correct, it only guarantees that the data is received in exactly the same format that it was sent.

Another example would be for banks. Banking and payments systems are the de-facto ‘apex’ of integration even though they do not make use of publicly open endpoints. Straight-through-processing (STP) allows clients to make instant payments. A transaction can move from Bank A’s banking system (say Temenos T24) straight into the national payments system (say Perago RTGS), and from there straight into Bank B’s banking system (say FlexCube) and into the recipient account, all this done within a minute.

The excitement of it should not blind a bank manager from implementing controls, say for amounts above a certain threshold. No instant payments for amounts above $x dollars. If there was a mistake by the client, the transaction would take longer to reverse. And then for settlement issues, you need to plan and budget, so you cannot suddenly get a billion-dollar transaction lined up for batch-settling the supposedly instant payments later when you did not expect it. I make use of the word ‘supposedly instant” because in reality instant payments are just instant messaging and instant credits advanced awaiting for settlements to be completed later.

The post-pandemic bank manager would monitor and update limits for ‘instant’ EFTs. In short, he will not let the excitement of live integrations get in the way of sound risk management.

The integration of systems is an issue that should be on the discussion table of the post-pandemic business manager. The conversation should be alive and gradual implementation should be on cards.

Ciao!

Financial Analyst, Cloud Accountant, Citizen Data Scientist, FPL Boss