Basics of Business Software Integration for Non-Technical Managers

technical planning.jpg

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 some background information for you to discuss integrations with your software technology team, helping you better understand and communicate with your developers. Though you don’t need to understand all the technical details of your integration, this article can help channel your attention to the right places, and allow for better decisions that can affect 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 functional specifics for a business software integration, here is a checklist of functional integration requirements 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 less than 50 models with 5 to 20 data fields each. More complex business software has easily 500+ models. Expect business software systems to range between 500 and 20,000 data fields. A common 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. Its easy to join them programmatically, but can be time-consuming to parse them into separate fields from one.
  3. When a user enters information into a software system via the system interface, the system often creates additional related data points to properly populate the necessary data models. This consideration is especially important when a system has been or will be optimized/customized to increase user efficiency. In such 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 wider 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). Do you just need to connect an online store to the inventory system, or do you intend to later get a CRM for the outside sales team, and setup a retail store for the 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. Cheapest and easiest way to connect 2 systems. The connection and its maintenance gets to be more complex once you have 3 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 setup each read/write separately to pass the info on. This is a simple setup for a basic integration that would stay static, but will get 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 reusing some of the integration code – if a system must send info to 3 others, you may be able to re-use the “sending” portion of the integration code. However, if connecting many systems, you may need to maintain many connections (to fully inter-connect 5 systems, you’d need 10 connections, so if one system has some upgrades, you may need to tweak 4 connections).

Horizontal integration – using a separate sub-system as a common data interface between other systems. It is commonly called an Enterprise Service Bus (ESB). Each business system has a single connection to the ESB, and the ESB accepts/distributes data. This works best if you intend to scale the system and keep adding more systems/components. However, this also requires that the ESB store and synch 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 que, 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 with this may arise if a big chunk of data is sent all at once – the receiving system may not write 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 que is good for cases with large data transfers, or differences in send/write speed between systems. It also helps with protection for instances where the receiving system might be down temporarily. With such setup, the sending system sends its requests to the “que”, and the que then initiates the transfer to the receiver, waiting for all to be ingested at the receiver’s pace and as it is 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 normally used for periodic synchronization, not a continuous integration with live updates. FTP data transfer is somewhat likely to produce security risks, in large part due to why and how it is 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:

~ by Andrey Kolesnikov, business development manager at Steersman