Do you really need to use an integration service to sync your SaaS data?

Laptop

Many popular SaaS applications include a handful of vendor built integration options. Vendors want to make it easy for new users to become embedded in their applications. They also want to embed their apps into your enterprise, making it less likely that you will consider moving onto other options.

 

If you can get an integration as part of your monthly fee, why would you look to Recursyv Seamless?

 

Why should you consider vendor integrations?

  • Vendor integrations are often built into the existing monthly charge. They’re a value-add option for the vendor to make signing up more attractive.
  • They’re often ready to use “out of the box”. Capture a few details and you could be ready to go.
  • They will be supported by the vendor over time. If the vendor changes their platform, they’re likely to evolve the integration in-line with platform changes.

 

Why should you consider an integration specialist?

Vendor integrations are likely to be limited in their functional scope

They are likely to support standard fields and sync with pre-determined fields in the other system. This may be great for getting started, but it doesn’t allow much flexibility. Most of our integrations have required some additional configuration before they meet the overall business requirement. These changes run along an entire spectrum of complexity. They could be straightforward as adding a single extra field. They could be as complex as syncing custom tables, syncing subsets of data based on custom filtering, etc.

Vendor integrations are likely to limit flexibility over time

As your business evolves, you’ll want to ensure that the systems supporting your business evolve with it. This might mean additional data fields, additional data sources (or endpoints) or even simply new options for option sets. Vendor integrations will not be setup to support your constantly evolving business requirement.

Vendor integrations will often be limited to point-to-point integrations with other popular applications

Vendors will provide tools to sync their system with another system, drawn from a small selection of popular systems. It is unlikely that you will be able to connect more than one other system. You may be limited to only the most popular SaaS apps. Single point-to-point integrations may help get over the initial hurdle of keeping two systems broadly in sync, but there is no room for growth as you need to sync with more systems (billing, support, back-end platforms, etc.)

Vendors may not be quick to support changing endpoints

Imagine you’re using Vendor A’s app and their integration offering to Vendor B’s app. When Vendor B makes changes to their API, it is unlikely to be Vendor A’s immediate priority will be to update their integration. You may find yourself waiting an unpredictable amount of time before Vendor A gets a chance to update their integration. If not enough customers are using the integration, Vendor A may decide it is not worth the investment to update the integration. An integration vendor will be focused on keeping their endpoint libraries up-to-date and are likely to have the changes prepared in advance of the API change.

Vendor integrations typically include limited monitoring and recovery features

Unless you notice missing data, you may never know that your integration is not working properly. By the time you do, it’s often too late. A specialist solution will typically include various monitoring options. These should be able to confirm that the integration is running and to report on integration errors. Additionally, an integration provider will have options for recovering and redeploying integrations quickly.

 

Specialists live and breathe their area of focus. As an integration specialist, we’re regularly encountering unusual integration requirements and using those to constantly evolve our Seamless feature set. Like typical SaaS apps, as the Seamless service improves, those improvements are offered to all users.

Within Recursyv, our primary focus is about getting systems syncing quickly, easily and flexibly. Once integrations move from our engineering and project teams to our operations team, we’re solely focused on ensuring that those integrations continue to run, day-in and day-out.

We proactively monitor integrations for technical and data issues and address them as soon as they’re raised. Often our alerting will flag up SaaS app availability problems before they’re noticed by users.

 

 

How to choose?

In short, it is all about what you need an integration to do for you. There is, of course, a place for using vendor provided integration tools. They will often meet basic requirements where there is limited need for flexibility and control. Specialist integration providers will introduce flexibility, additional data endpoints and control features that vendor solutions are unlikely to offer.

When considering your own approach, there are some questions you should consider

  • What are the different apps you need to sync with? Does the vendor you’re considering offer integration endpoints for those apps?
  • What level of flexibility / customisation do you need when matching data items across different systems? Do you have custom fields, tables, option set values, etc.? Are these likely to change over time?
  • How often do you need data to refresh?
  • Are you likely to want to introduce additional data endpoints over time?

 

Tomorrow’s IT operations are as important as today’s software delivery

When we set out to build Seamless, one of the things we focused on, quite obsessively, was that we should reduce risk in a software delivery project. Admittedly, this is a reflection of the backgrounds of our founders: delivery of software. It also vastly undermines the value of delivering Seamless as a managed service. Perhaps we’ve done ourselves a disservice?

Erm – let’s not get ahead of ourselves, have we actually addressed delivery risk?

In the first instance, I’d like trumpet our engineering a little bit. If we need to connect to a relatively modern API (think RESTful or SOAP), we typically have data syncing in under a week. Once we’ve “proved the pipe” (demonstrated that we can move data between source and target), we can shape that as necessary to meet the business requirement. As this is readily demonstrable, the delivery risk is greatly reduced. There is no longer a long period of writing code and hoping for the required outcome.

Getting there is only half the battle

As old hands at “change the business”, we may have fallen into the trap of forgetting about “run the business”. If you’ll forgive the cliche, delivery of a new software solution is the beginning of a journey rather than the end.

A data integration is a living piece of infrastructure that needs to be operated. Even if there are no changes to the business requirement, integrations need to be looked after and cared for.

  • Is the integration able to connect to both source and target?
  • Is the volume of data being moved roughly in line with expectations?
  • Does the integration have enough oomph to ensure that data is sync’ed within the required timeframes?

The Seamless monitoring features, including meaningful alert content, means that keeping tabs on these questions becomes part of the regular operations monitoring regime. Additionally, alerting on exception means that you can assume all is well until told otherwise.

Integration issues are often a symptom of broader problems

One thing we’ve observed is that often issues with the integration are just symptoms of broader problems. Our monitoring is proactive (we go looking for issues) and our reporting is sufficiently detailed that we’re able to help Seamless users spot and trouble-shoot underlying issues, often before they’ve noticed them themselves.

  • Are both the source system and target system accessible? If Seamless is unable to reach systems, is this because of an underlying systems issue that needs to be addressed?
  • Are there data mismatch issues between source and target? Often this is a case of changes to reference data in one system or another.
  • Are data volumes completely outside of the expected data volumes? If so, is this driven by a something in the business (e.g. a sales promotion) or is one of the systems experiencing an underlying issue?

In 2017 we had only one service availability issue. Sure – we’d like it to have been none but, if there’s going to be some downtime, let’s at least handle it elegantly.

In July 2017 there was a short-lived Azure UK connectivity issue. Our alerting meant that we knew it was happening before it was confirmed by Microsoft and we were able to manage expectations across our client base. In turn, this allowed clients to manage expectations within their user community. We also provided the option of redeploying to another Azure geography. Thankfully, the outage was contained to a few non-business hours (for our UK customers) and there was no need to exercise any of these options.

The underlying Seamless service remained live and, as connectivity returned, any data had been “caught out” between source and target was quickly sync’ed by the service.

The only rule of business requirements is that they change

One of our first prospects for Seamless was a company who, as a result of an acquisition, found themselves with two software platforms for managing helpdesk tickets across their considerable IT estate. As part of the merger process, a vendor had written a point-to-point integration which sync’ed relevant tickets back and forth.

Six months down the line, there was a need to change the rules for which tickets would sync between the apps. After months of avoiding the question and 3 days of consulting work (on fees), the vendor quoted tens of thousands of pounds to change the integration. These were well known, well documented apps with mature APIs, updating the integration should’ve been a piece of cake. It became easier to change business rules inside the company than to change the integration and that’s just not how IT should work.

The use of config and straight-forward mapping features within Seamless means that meeting the needs of changing business requirements doesn’t require re-engineering entire integrations every time a field, a data map or an option set changes.

Not every IT organisation is the same

This blog post was, in part, inspired by a conversation with a prospective client. In our initial conversation, the primary concern was about delivery timescales of the integration requirements. As the conversation progressed, it was also discussed that the broader procurement strategy was to use contractors to deliver software with a view to streamlining the size of the in-house IT team. That’s not uncommon, by their very nature, project teams are short-term creatures designed to achieve an outcome (rollout of new software).

In discussing why Seamless may be a better option than using contract developers to build a point-to-point solution, I stressed not only the delivery risk and timing considerations, but that the managed service remains in place after the project team is stood down. This enables the in-house IT team to focus their effort where they can deliver more “bang for buck” whilst the Seamless monitoring ensures that when issues occur, the IT team are quickly informed with meaningful information to trouble-shoot any underlying systems issues.