All posts by : Julian

Integrations can be pretty complex. Technical challenges, diverse organizational structures, people with varying skill sets and agendas, distinct processes, and separate applications are all factors adding to this complexity. 

We will focus on one portion of the process, examining whether to build a custom integration using existing company resources or buy one of the commercially available software applications that provide this service. We will also focus on how the build vs. buy debate pans out in cross-company integrations.

But before we do that, let’s look at the different steps in an integration project. 

Phases of the Integration Project

Gather Requirements and Plan

• Start working out the pain points. Identify what’s going to be the most difficult part of your integration. Is it assigning new users to platforms? Or copying data between applications, or sharing information via email and chats to keep track of statuses? Is going back and forth between different workflows becoming confusing for everyone? 
• What does the communication path look like?  What sort of deployment models do you and the other environments you are integrating with use? What sort of security, authorization, information, and authentication issues are likely to arise during the integration? 
• Plan both the internal and external resources: Work out not just the budget, but the amount of work and effort required. Make sure the right people are involved from the start.

Design the Integration

• Work out your common data model. Carefully map data exchanges and transformations between systems. A three-space text field won’t t map to a two-digit text field, and no amount of wishing will make it so. 
• Figure out redundancies. Identify what potential failure paths and proper notification protocols will be. You also need to have a formal rollback system in place in case of inevitable system crashes. After all, no system is perfect. 
• Account for data tracking: Make sure you’re logging all data transfers so you can conduct regular audits and be sure of system reliability.
• Design the integration scope: Look at all the data you’ve gathered and determine what your unique information flow requirements are. Do you want one or two-way integration? Which fields do you and don’t you want to sync? These are important questions to figure out before you begin. 

Implement the Integration

Your developers can now start to code in or buy, an integration solution with the required functionality. This might seem pretty simple, but the hard part comes in figuring out how to handle errors and exceptions without causing the applications to terminate.

Validate Your Integration Solution

It can be hard to figure out the validation process for the functionality of your integration. To make sure everything is running smoothly, you need to subject the process to testing for performance and functionalities, as well as future pain points. Testing to ensure there are no unexpected errors is of paramount importance: a system crash can lead to irretrievable loss of data.

Manage Your Production Release

So you’ve got your integration solution ready to roll and validated, and now you want to release it to the production systems. Sometimes, the release can also involve deployments across company borders(aka cross-company integrations).

It also needs to be delivered to your end users in a way that’s transparent and easy to understand for everyone. Disruptions cost, and you need to take that into account not just for your business, but any businesses you’re integrating with.
You also need rollback plans, so if unforeseen failures or consequences occur you’re covered.

Maintain the Integration 

Ask anyone in software and engineering circles, you’ll get the same answer: maintenance costs. Not just money either: time too. In fact, maintenance is going to set you back a lot more than the initial setup. Make sure you’ve got a maintenance plan in place, you’ll thank yourself later.

Customize the Integration

Here’s the thing about integration: once you’ve started, that’s not the end. You’re going to start getting requests to make it better. Stuff like new workflows, permissions, data fields, and different insights into existing workflows. Take these inevitable customization requests into account. 

But we’re here to solve the classic integration problem: build vs. buy software. Before that, let’s understand the thought process companies usually have when it comes to an integration project. 

How do Companies Approach an Integration Project?

Companies choose to integrate the applications they use on a daily basis to overcome certain pain points. For instance, when teams using these applications exchange data manually it leads to inaccuracies, delays, missed deadlines, and poor business outcomes. Moreover, for a smoother collaboration with other companies using different applications altogether, they start feeling the need for integration. With such an integration, they expect automatic, real-time data exchange based on their requirements. 

And the thing with integration requirements is that they vary in complexity and are volatile. They can range from simple data mapping between entities to creating complex multi-level dependencies between the same entities. 

So, they usually start looking for automation solutions to see if their integration requirements can be fulfilled. This approach works for basic one-on-one unidirectional mappings but might be a hindrance for complex, ever-evolving requirements. 

They might hit a limit in their decision-making process, losing hope of finding a solution that can accommodate advanced integration use cases. The only feasible option they now consider is to build the integration themselves. 

But, we are here to present our side of the story for this dilemma. 

This blog is for companies who are faced with a similar situation and are contemplating between: 

• Building the integration in-house: Building a custom integration application in-house using existing company resources. This usually involves accessing the application’s open APIs and writing code to enable automatic information sharing between them. 
• Buying a COTS (Commercial-off-the-shelf) integration solution: Purchasing one of the commercially available software applications that provide integration-as-a-service. And here, we mean a solution that offers the kind of automation and customization they desire. 

Weigh the Options: Building Vs. Buying an Integration Solution

To solve the build vs. buy software issue, you need to take into account a range of key factors. 

Let’s deconstruct the two approaches and analyze their key advantages and potential drawbacks. 

Why do Companies Choose to Build a Custom Integration Solution? 

Usually, MSPs (Managed Service Providers) or MSSPs (Managed Security Service Providers) opt for building a custom integration solution in-house. They do so because of various reasons: availability of resources, security considerations, etc. 

There are some scenarios where building your own integration might work:

• You need bespoke integrations. 
• You have a team of engineers, developers, system architects, and product managers ready at your fingertips to develop and maintain the integration. More so, the team should be entirely dedicated to the integration project because of its demanding nature (as we saw). 
• You have an integration request critical to your business process, so you choose to build in-house. Or maybe the integration is basic and easy to implement, connecting you to a single customer application. In such cases, the code will be less complex to develop and maintain. 
• You have stringent security requirements. 
• You want complete ownership of your integration – the code, support, maintenance, etc. 

However, it’s necessary to take note of the pitfalls of building an integration. 

Drawbacks of Building a Custom Integration Solution

You may encounter the following issues:

• Scaling in-house solutions can be hard. Be it adding a new application to your technology stack or wanting to collaborate with a completely new customer. You might well end up developing the same solution over and over again. This ultimately hinders the agility of your integration. 
• Business environments are dynamic. The flexible nature of business means things change, and your integration needs to change with them. This adds complexity to in-house integrations. Your dev team has to take into account these changes in workflows, as well as other customizations. This takes up valuable time and can be frustrating for everyone.
• Let’s be honest: your dev team has other work to do. Depending on the severity of your and other issues, you might not be at the top of their list, which is just how things are in a fast-paced environment. Your requests are going to have to compete with other projects, and that causes delays. 
• Maintenance costs on an in-house integration solution are high. When you start wanting upgrades (trust us, you will – for many reasons like security, etc.), you have to modify existing apps that were developed for the original system, or in some cases replace them altogether. This also leads to retesting the configuration, which needs to be factored into the cost of ownership.
• It isn’t just the original app that needs to stay up to date. The documentation has to be changed too. That adds time. More than that, your original dev and maintenance staff might leave, and with them valuable and unique knowledge about the technology stack.  This can create a whirlwind of issues means you’re spending more time, money, and effort just to make an already difficult-to-maintain system function properly. 

When integration, especially one across company borders, becomes an essential part of optimizing your workflows and systems, you must face the decision to build the integration application in-house or buy an integration software available commercially.

So you’re still deciding, right? The initial costs of building your own enterprise integration software are less than the costs of using a third-party solution. And your development staff are on standby and ready to roll out your in-house integration? 

Hold on just a minute. Building this type of integration is a massive job, and initial costs can seem cheaper, but as we’ve already seen, maintenance is what costs more time and money in the long run. And you do have to think about the long run: a successful business is a marathon, not a sprint. 

A lot of these difficulties can be avoided by using the correct commercial integration software for your project. While the acquisition costs are higher, they start to even out when you take into account customization and maintenance.  

We’re going to understand the specifics of the above in the coming sections and also consider a time and cost-saving analysis.

Benefits of Buying a Third-Party Integration Solution

Some key advantages of buying commercially available integration solutions:

• They are agile and scalable. It’s easy to add just another application or customer to your integration.
• They leave your developers the time and space to work on meaningful tasks rather than spending time and effort on unnecessary integration overheads and maintenance.
• They expedite your integration since they already have the necessary arsenal to set you up. 
• They can significantly reduce difficulties and delays caused by system and process changes. 
• They allow your teams to define what information gets sent out externally and how incoming messages are processed internally. Changes in your internal company processes will not affect your cross-company integration efforts.
• They can help you significantly reduce costs. They also have multiple pricing plans that offer support at all phases of your integration project. 
• They have teams responsible for maintaining the software documentation and providing needed training. They even work with you to troubleshoot specific issues and provide you with the required support along the way. 
• They are built with changes to underlying systems in mind and can operate independently of those changes.
• They help you maintain integration transparency, where your focus is on optimizing your business, not getting distracted by potentially messy in-house integration projects.  Acquiring one of the best-in-class integration software packages allows you to do just that.

Challenges of Buying a Third-Party Integration Solution

As we saw, buying software is a must to fulfill modern integration requirements. 

But there are some challenges you must address: 

• Often commercial integration software has a range of specific integration templates. So if you have an advanced use case with detailed data mappings and dependencies, you might not be able to fully leverage the solution and be constrained by the UI it provides. 
• With so many options available in the market today, it’s difficult to choose the right one.
  

Thankfully, you’ve come to the right place! We’ll address both these challenges right here, right now. 

Factors To Consider When Buying an Integration Solution

When it comes to a cross-company integration solution, the following features become the most prominent ones to take into consideration:

Cost

Cost is the primary reason we’ve started the build-vs-buy debate in the first place. Factor in the systems you want to integrate, how many such systems, the pricing models of the solution you want to buy, and last but not least, one that shouldn’t burn a hole in your pocket.

Security 

How do you ensure the information you share with other companies or teams is not privy to being exposed? How do ensure the data exchanged is encrypted and free from cyber-attacks? 

Having a solution that is inherently secure by design helps solve these issues. 

Reliability

Systems go down – that’s a fact. You can imagine that your partner is upgrading their Jira.  How do you ensure that all the changes are synced in the same order as they happened? Having a solution support an integrated retry mechanism is important. 

Scalability

Adding a new integration partner or buying a new application that needs to be integrated is necessary for evolving business environments. A solution that can scale with minimal effort should be your top choice. 

Customizability

You often need to make customizations to accommodate changing integration requirements. In such a scenario, pre-defined integration templates don’t always work. 

For instance, say you have an incident to issue mapping where you have 150 projects on the Jira end, and new projects are added on the fly on the Jira side.  How do you implement an efficient dispatching capability that is easy to maintain?

A tool like Exalate provides you with an AI-powered scripting engine, which you can use to generate scripts and establish granular control over your integrations.

Decentralization

Integrations evolve, just like everything else. The question is, how do you deal with changing workflows in your specific use case when it evolves? Decentralized integration ensures that you get independent and granular control over your side of the integration. This can happen even without consulting the other side. 

Exalate: A Fully Customizable Integration Solution

Exalate meets all the above criteria and solves the most complex cross-company integration use cases, flexibly and adaptively. It is perfect for MSPs wanting to connect with their customers. 

It allows you to focus on optimizing processes within your company while seamlessly integrating with your external partners exactly where and when you need to integrate. It offers integrations between applications like Jira, Salesforce, ServiceNow, Zendesk, GitHub, etc. 

Exalate allows you to use the AI Assist feature available in the Script Mode to set up advanced integrations. This feature is integrated right into both your incoming and outgoing sync rules tabs as a chat window. The scripts are crafted based on your input, existing configurations, and Exalate’s scripting API.

Decentralized integration is an important feature, and currently, Exalate is the only integration software providing this functionality. You can learn how a distributed architecture helps scale your integration and makes it more secure in this whitepaper.

It has a Groovy-based Script mode along with a drag-and-drop visual interface to facilitate both business and technical users. It also provides a single-tenant architecture for utmost security. 

Let’s look at the time and cost savings with Exalate. 

A Time and Cost-Saving Analysis of Building a Custom Integration Vs. Using Exalate as a Third-party Integration Solution

Assuming a conservative estimate of 10% time savings for each employee working with integrated systems, and an average salary of $60,000 per employee, the potential cost savings for a team of 20 people could be calculated as follows:

Exalate can help reduce licensing fees for tools that are no longer needed due to integration. 

Assuming an average licensing fee of $50 per month per user, and a reduction of 10 licenses across different tools, the potential cost savings could be calculated as follows:

Therefore, if the cost of purchasing an Exalate license is $3,100 per year, the ROI could be calculated as follows:

This means that for every $1 spent on Exalate, your company could potentially receive a return of $41.18 in cost savings and increased efficiency.

The Final Verdict: Build or Buy an Integration Solution? 

We’re almost at the end of our dilemma. I hope this blog has steered you in the right direction. If not, read on. 

Modern integration requirements are evolving and demanding. So we ask a few questions and choose the correct answer: Build or Buy software?

Recommended Reading:

• The Comprehensive Guide to iPaaS (Integration Platform as a Service)
• B2B Integration: The Comprehensive Guide
• The Journey of Software Integration: How Organizations Make the Leap from Copying Data to Cross-Company Integration
• MSP Integration: Why It Matters for Your Business
• How Integration Service Providers Can Help Simplify Data Integration