When working with our customers at Trust Insights we all get very excited about things like driver analysis (figuring out exactly what’s working and what to do more of) and predictive analytics (beating out your competitors by having a better view of what’s coming in the future).
For better or worse, the prerequisite for doing the cool stuff is having all of your data in order – everything integrated, clean, flowing correctly. If you’re not already there it’s a ton of work, and one of the first steps is integrating as much as possible.
The Cardinal Sin is finding two silos of data and finding out that an integration exists and then celebrating that life is good and your work is done. Integration is not a yes/no checkbox, think of it as the connector between two physical places – it could be a highway, train, plane, or a one way slip and slide that somebody throws you down. If you’ve built an integration you already know this stuff, but for anyone that hasn’t looked behind the curtain, here is why an integration might not be the salvation you seek.
Integrations can be one way or two way. At the low end, just like a slip and slide, one application can grab some data and throw it down the slope so it lands on some server where the other application is awaiting the data and loads in. If a vendor is telling you that their application will FTP a file once a day, that may be all you need to make things work but it barely qualifies as integration. The pitfall here – data is sent from application A to application B and is changed in application B. The new data is never pushed back to application A.
This is why you’ll hear people talk about “the system of record”. In the case above application B is current, but application A can get out of sync after it sends the data to application B, so the data in application A cannot be trusted in the long term.
What’s exposed? Vendors are always talking about their API (Application Programming Interface). These are the lists of instructions that other vendors can use to ask for data from the other application or to send data into the application. Again, it’s not just yes/no, the vendor decides if they want to let data out or in (many vendors realize that if the’re no privacy concerns it’s ok to let data out, but letting the world pump their data of questionable background in is asking for trouble.) Besides the in/out decision it’s also fully granular – the vendor gets to decide what they are going to make available to you – they choose which fields you can access, and if you have permission to write that data, or just read it, right down to every single field. Just because there’s an API that doesn’t mean you automatically get to the data you need.
Plus, there’s more than just the raw data. Let’s say you’re in application A and have a dashboard that says your total pipeline for Q4 is $1,243,967.21. You want this number to go to application B. The problem is – that number is not in the database, it’s calculated by the application based on 63 other numbers that are in the database. An integration may not be able to do all of the things that you can do in the user interface. In this situation either the interface has to do the calculation or you have to grab the same data and add the feature to application A to do the calculation.
And let’s not forget the stress of daily relentless change – as new features are added to products on either side those need to be accounted for in the integration. Any changes to the database on either side can break the integration. Setting up an integration is not a “one and done.” Plan for maintenance.
Part of that maintenance is monitoring usage. If the data is never getting used, shut it down and put the resources someplace where they can have an impact.
Now you know the questions to ask a vendor when they tell you they have an integration. Good luck!
As an aside, I have to mention services like Zapier here – drag and drop integrations that are down and dirty can solve some problems for you with very little work. Your company may wave compliance flags here, but if you’re a pirate only interested in getting things done and results, it’s worth checking.
Note: This post was inspired by my interview with Scott Brinker at INBOUND where he talked about the highest standard of integration being one that can do everything the user interface does. If you are into podcasts you can listen to that interview here.
Newsletter
Podcast
