Buy vs. Build: Integration Software

Companies are increasingly deciding to buy software rather than build it in-house. There was a time not too long ago when companies would attempt to build their own CRM (I know a little bit about that :)), today, it sounds ridiculous to even attempt building your own CRM.

In fact, the Department of Veterans Affairs recently announced their decision to finally buy software after two decades of trying to build it themselves.

As an organization’s proclivity towards build vs. buy has changed when it comes to business applications, it needs to change when it comes to integration software.

The definitive guide on what to look for in an integration platform

As the CEO of an integration company, my view and feelings about this topic are crystal clear, but after talking to prospects and customers, I realize that they often think about building (coding) their own integrations because:

1. Integrations need to be custom.
2. They feel their needs are simple, and that they can accomplish their objectives with point-to-point integrations. This is however a common fallacy as that gets out of control and many companies find themselves with a Frankenstein’s monster of brittle unmaintainable code across many integrations and multiple points of failure.

As SaaS makes software easier and easier to buy, many companies end up with hundreds of cloud applications bought by various teams that all don’t talk to each other (not to the mention the internal tools that the IT teams are still building). Integration is a huge problem today and getting worse. Let’s talk about how companies tackle this.

Our team interviewed over two hundred prospects and customers and this is what we learned about how businesses think about connecting their applications, data, microservices, APIs, and processes that run the company.

There are 3 main options that companies consider when thinking about integration

1. Use the native integration provided by the SaaS apps that you use
2. Build point to point integrations
3. Buy an integration platform

Option 1: Use the integrations available in the app that you want to connect

Native integration in SaaS apps is pretty common. These will provide you with some simple point-to-point connections between applications without much flexibility. For example, Marketo has the ability to synchronize with Salesforce. If your processes are simple and few in number, this is definitely the way to go. Many of these native integrations will work between the most popular apps and can solve small problems easily.

If you or someone on your team is more technical, you can even write small scripts to connect APIs fairly easily. This method is rigid and brittle, but it’s free and setting up one can be relatively quick if the APIs are well developed, you’re technical, and changing the way the connection works is not something you foresee doing in the near future.

The problem with this approach is that you must customize one or both of the SaaS apps to handle different data formats, types etc.This is how everyone starts. But as you grow (either in size of company or number of applications), this method becomes too brittle, too complex, too scattered, and too complicated to manage. The customizations that occur for one app aren’t usable by others so it is just a pile-on of customization after customization.

Option 2: Build Your Own Integrations by Writing Code

Many companies find themselves building integrations. There are a lot of open-source libraries on github that make this problem look small and show how fast things can be done. They start with a library of code that sits on some server and connects to these various systems and over time it grows into a Frankenstein’s monster of bandaids on top of bandaids. Before you know it, you have a mass of unmanaged integrations in different places, built by different people and any change even to a single field starts being a week to month long project

Roughly 45% of Azuqua customers first tried to write their own integrations.

Some of the popular reasons organizations choose to build are:

• Buying is perceived as more expensive than building (often due to sunk costs).
• Development resources are readily available to be put on the project.
• Internal policy of the company requires building before buying.

In Practice, the IT team jumps into action mapping out all the various use cases and coding as fast as possible. Usual development hiccups occur along the way, but nothing too major and the project is actually completed and usable within a few months (keep in mind, this is the BEST case scenario. Development time increases with the complexity of your requirements) and it is almost always waterfall.

Then after a little while, reality sets in:

• Project specs from the business side change rapidly throughout development.
• The number of developers increases as it becomes clear more hours than initially thought are required to maintain the project and the bill to the business increases.
• One or two developers initially on the team end up leaving or get re-assigned to something more critical, therefore leaving their code to be deciphered by others which makes development take even longer.
• Suddenly, one of the apps you’ve integrated with goes through an update and the integration breaks.
• Stakeholders continually require troubleshooting and request new capabilities.
• Scaling the solution to handle real-time data flow is always unexpectedly hard and borderline impossible, because it was never built for that

The question here is not about team capabilities and confidence i.e. “could you”, but about “should you” bear the costs of developing, maintaining, and supporting custom integration solutions .

Option 3: Buying an Integration Platform

With all these cloud apps running rampant, it’s time to realize that the same principles for buying SaaS applications apply to integration platforms. Just as you’ve moved away from monolithic, IT-owned software to smaller, fit-for-purpose apps, integration needs to keep up.

You need an integration platform that is fast and easy to use, completely customizable to your unique needs, seamlessly scalable, and empowers business teams to focus on what moves the dial rather than being blocked by technical insufficiencies.

When companies buy the right platform instead of building, they reap these benefits:

• Business teams don’t have to go IT every time they need to pipe data from Marketo to Salesforce to Zendesk, but IT can still govern security and access. This is critical because I’ve yet to see an inhouse solution that has a UI that’s usable by many people.
• You don’t have to worry about all those hidden maintenance and support issues with which they have expert experience.
• Developer resources are spent working on critical projects that help you compete in your market. These resources shouldn’t be spent building piping between applications.
• APIs are constantly evolving and changing. An integration platform will deal with changes in the background so you don’t have to waste time dealing with them.
• Developing new enterprise apps is much faster through an integration platform because most new apps rely on the data that’s stored within existing systems and workflow processes that team members are already doing.

Make Sure Buying Works for Your Needs

Buying has its own share of pitfalls that you need to watch out for. Maybe your business processes are complicated and need a customized touch. Or, you need to connect niche applications and services. It could even be that you want everyone to be able to use the platform, not just the IT team.

Not all integration platforms are created equal so without proper research, you may end up with a platform that does not fulfill your needs and you’ll have to go through the whole process again. However, if you do make the correct decision for your needs, your business will operate faster and more efficiently than ever before.

If you would like to learn more about how to select the right integration platform, download our “What to Look for in an Integration Platform” guide.