Basics of Business Software Integration for Non-Technical Managers

This article is for the non-technical manager preparing to commission or oversee an integration of two or more pieces of business software.

The aim is to provide background information to facilitate discussions with your software technology team, enabling you to better understand and communicate with your developers. Although you don’t need to understand all the technical details of your integration, this article can help channel your attention to the right places, allowing for better decisions that can impact the short- and long-term usefulness and cohesiveness of your business systems.

Business data and connecting it

It is best to start by defining business needs and then shop for integration options.

If you are interested in the functional specifics of a business software integration, here is a checklist of functional integration requirements (a/15) for integrating an online store with an inventory system. You can extrapolate specification questions for other types of integrations from it.

Important background on business data and data models within business process systems that might not be obvious:

1. Business systems typically have many data models (a model may exist for a customer “contact”, for a sales order, BOM, stock move, product, and many more things). Simple business systems may have fewer than 50 models, each with 5 to 20 data fields. More complex business software has easily 500+ models. Expect business software systems to range between 500 and 20,000 data fields. A typical business suite setup we do at Steersman has around 8,000 data fields, for example. The bottom line is - it is easy to link up 10 data fields (often the case with out-of-box integrations available for popular software systems), but an “optimal” integration for a seemingly simple data exchange can require mapping 100+ data fields.
2. Different systems store different data, and, potentially, in different ways. Example: one system keeps a client’s first name, middle name, and last name in three separate fields, and the other lumps them into a single field. It’s easy to join them programmatically, but parsing them into separate fields can be time-consuming.
3. When a user enters information into a software system via the system interface, the system often creates additional related data points to populate the necessary data models properly. This consideration is especially important when a system has been or will be optimized/customized to increase user efficiency. In such a case, a proper integration may require transferring data that isn’t immediately obvious.
4. There should be a “source of truth” for various types of data. It is easy to decide that the inventory system should manage inventory counts, and that the online store should manage product descriptions. But what happens when there are multiple sales channels and the inventory system is used for processing quotes and phone orders? What if the company sells a broader range of items than what’s listed on its online store? Where should the product titles, pricing, and availability be managed in that case? More on that in the functional integration checklist.

Systems can be integrated in a variety of general ways

It is crucial to have a technology strategy/plan for a few years (see a full article on business software scaling for SMBs here) (/a/21). Do you only need to connect an online store to the inventory system, or do you intend later to implement a CRM for the outside sales team and set up a retail store for local buyers? Your total spend on software and integrations can vary significantly based on where you end up in 2-3 years and the path you take to get there.

Here are a few basic notes on integration types:

Point-to-point integration – data transfer between two systems, mapping/translating data between just these systems with minimal effort. The cheapest and easiest way to connect two systems. The connection and its maintenance become more complex once you have three or more systems connected this way:

• Vertical integration – a point-to-point integration between 3 or more systems, where systems are connected in a chain. This often requires multiple data “translations” as data moves from one system to the next (sequentially). You need to set up each read/write separately to pass the info on. This is a simple setup for a basic integration that remains static, but will become expensive and cumbersome if you intend to work on system efficiency and make upgrades over time.
• “Star” integration – a point-to-point integration between 3 or more systems, where each system is connected to another directly (not sequentially). This allows for reusing some of the integration code – if a system must send information to three others, you may be able to reuse the “sending” portion of the integration code. However, if connecting many systems, you may need to maintain many connections (to fully inter-connect five systems, you’d need 10 connections, so if one system has some upgrades, you may need to tweak four connections).

Horizontal integration – using a separate sub-system as a standard data interface between other systems. It is commonly referred to as an Enterprise Service Bus (ESB). Each business system has a single connection to the ESB, and the ESB accepts/distributes data. This approach works best if you intend to scale the system and continually add more systems/components. However, this also requires that the ESB store syncs all the data, which requires a significant effort and investment to start.

Data transfer between systems

The actual transfer can be done via various avenues or combinations thereof – direct API, FTP, message queue, EDI, and more. The best route depends on technology compatibility, developer ability, data volume, and the needed speed of sending/ingesting data. Here are the basics on a few transfer options:

• Direct API transfers are great for most data transfers when both systems are always available. Issues may arise if a large chunk of data is sent all at once – the receiving system may not write data fast enough, causing system slowness and potential crashes with data corruption. Connection via API is usually easy to set up, as long as both systems have API capabilities.
• An API integration via message queue is suitable for cases with large data transfers or differences in send/write speed between systems. It also protects in instances where the receiving system might be down temporarily. With such a setup, the sending system sends its requests to the “queue,” and the queue then initiates the transfer to the receiver, waiting for all data to be ingested at the receiver’s pace and as it becomes available.
• FTP helps inject files/data from one system into another. It doesn’t use the system’s built-in communication interfaces (like an API) if such interfaces exist. Using an FTP is somewhat like having a budget horizontal integration – files get uploaded into an FTP location, and downloaded from there by the other application. In a way, you then need to map two integrations, even if you are connecting just two applications. FTP is typically used for periodic synchronization, rather than continuous integration with live updates. FTP data transfer is somewhat likely to pose security risks, largely due to its setup.

Further reading on business software oversight in SMBs

I hope this information helps you get into a better position for managing and commissioning your business software and software integrations. For additional information related to integrations and business process automation technologies, see my other articles:

• Functional requirements for the technology team: integrating an e-commerce site with an inventory management system
• Scaling business software in growing SMBs - common issues

~ by Andrey Kolesnikov, business development manager at Steersman