System integration planning is the process of incorporating smaller sub-systems into one larger system to ensure they all work together. Integration is a cornerstone of today’s enterprise environments with their multitude of enterprise resource planning (ERP) systems.

The power of those software applications does not lie only in the functionality that they provide themselves, but in their ability to communicate with one another, in order to make data flow seamlessly through the environment. This improves processes and makes a company more efficient as a whole.

When thinking of integration, web services standards such as SOAP and REST come to mind. Those are meant to simplify the integration with the large number of support tools that are built around them.

Unfortunately, the tools themselves are not the solution to your integration problems, but only the means to a faster implementation. The real solution is proper system integration planning and design, which need to be based on the right criteria. And that is not always the case in a project.

So, what are the best methods for the design when integrating two systems? Well, there are a number of questions that need to be answered in the planning stage.

Let’s go through these 5 key questions:

1. What is the data that the target system requires to complete the integration task?

Identifying the target data is an important first step. It defines what objects or tables need to be accessed, and the rules the data needs to comply to. Typically, the target data model drives the design of a custom integration point, should one be required.

2. Where is the data required by the target system located in the source system, and what transformations are needed?

Common examples for data types that need to be transformed are numbers and dates. For example, date formats and time zones may be different between the systems and have to be converted.

3. What is considered a transaction within the integration task and are there any dependencies between the transactions?

A transaction is an atomic unit of work. It only changes the state of the target system if the data was successfully transferred and processed.

If any failure occurs, whether it is during the transport or processing (i.e. validation), it must be ensured that the target system remains unchanged. For example, if a transaction creates multiple records in the target system (i.e. an account and a contact, and the account was successfully created but the contact failed the validation), it must be ensured that the account record is removed again. This way the target system has the same state at the end of the transaction as when it started.

4. How will you connect to the target system (domain name, IP, etc.) and what security constraints apply (certificates, credentials, etc.)?

Connectivity and security constraints should be identified and verified early on in the project. As those can often be reasons for a project to be delayed or even fail altogether. The reasons are manifold like: missing firewall rules, required certificates, setup of new security roles and credentials, protocol incompatibilities between source and target system – just to name a few.

From a technical perspective, most of those issues can be resolved. But it is often the processes or additional constraints that are only identified during the validation, which add more risk and effort to the system integration project.

For example, the target or source system may need to be patched up before they can communicate with one another. On the other hand, the networking team may need to open up the firewall and create new domain name (DNS) entries for the connection to be established. These are typically not very complex technical problems, but depending on the size of the company, they may require approvals and involvement of other groups requiring additional time.

In some cases, changes such as patching a system may introduce conflicts to other parts of the organization, which may make the integration much more difficult or even impossible.

 5. What interface options do you have available (REST, SOAP, Custom, etc.)?

The interface options have an impact on the tools and implementation design. This is because they help determine whether the solution must be entirely custom or whether productized solutions are an effective system integration method.

Creating the right design may not always include the path of the simplest or most straightforward solution.

The Influence of Transactional Requirements on the System Integration Process

To demonstrate the impact of transactional requirements on an integration design, let’s look at the example of an order submission from a Customer Relationship Management (CRM) system to an order management system (OMS). Before the order can be submitted, the system needs to ensure that an account exists since the order must be linked to it. If it does not exist, let’s assume the requirement is to create one as part of the integration as well. The account should only be created for a successful order submission, but not if the order submission fails.

The OMS provides a standard SOAP interface that allows for the typical data operations (CRUD – created, updated, delete) on the entities, such as account and order. It also provides the ability to create custom web service endpoints exposed through the same SOAP interface.

Now, choosing the standard SOAP interface has the advantage that no custom development is needed inside the OMS. The CRM can first create the account using the account interface and then create the order through the order interface. However, while this seems like a desirable approach for the implementation, there are disadvantages that need to be considered.

Since the account and order interface are separated by different endpoints, it requires two independent SOAP requests to submit the order. This means that the risk of a communication channel causing an error doubles. It also means that it requires an additional request to delete the account if the order submission fails to fulfill the transactional requirement for accounts to only be created with a successful order. That deletion request itself has the risk of failure, and that would leave the OMS in an invalid state, because the account exists, but the order does not.

Better Integration Planning

To address all those issues mentioned above, a custom endpoint could be created in the OMS that would consume the data for the account and order in a single request. The logic processing the request would have the ability to validate all the transmitted data for the account and order creation before even attempting to persist the information in the database. And it would be able to handle the cleanup of the account should the order entry fail.

On top of that, only a single request would be made from the CRM, which means less overhead, less risk of failure, and the overall integration process is completed faster than if using the multiple requests through the standard interface.

This is just one example. Of course, even though there are many reasons to consider custom endpoint in the given case, it does not mean that it is always an option to go down that path. Using the standard interface is obviously a feasible option as well, but it comes with increased risk and complexity, and that needs to be understood and included in the project planning.

Every system integration comes with its own challenges. Answering the questions listed above will help to solve those challenges the right way. In addition, if the right validations are done upfront to identify and address those risk factors around connectivity and security, it will just be a matter of time until the two systems are integrated with one another, boosting the productivity of your company.

Need help with your system integration plan?

Our enthusiastic and highly experienced team can assist with your software integration planning and contact center integration needs.  Let us know how we can help!