One thing that always strikes us about rolling out integrations is the difference between the time taken to prepare the integration and the time taken to deploy the integration. Our engineering team may estimate a few days to build the integration but the overall effort required often stretches beyond that estimate.
For many of our rollouts, we start with a template. For a purely templated integration, we can prepare the underlying sync setup in an hour or two. Underpinning the template is the fact that we’ve done many integrations with both systems, we have feature-rich system connectors in our library and a great working knowledge of how the systems work.
So… why does the project need consulting time to get from our Project Engineers to syncing data?
There are some things that we need before we even get started. This usually means arranging connectivity details, user/api accounts, possibly creating some cross-reference fields, etc. It should also not be overlooked that Dan really works better with a good cup of coffee. If we’re deploying into a client’s Azure environment, we need it to be setup according the specification provided.
We provide the specs for all of these as part of our project initiation, but it often takes a few project calls to confirm that prereqs have been delivered so that we can begin work in earnest.
Taking advantage of the templates
If you’ve read some of the explanatory content on the website, you’ll know we love banging on about our templates. For sure, they help us make a massive leap on Day 1 of setting up an integration. They’re still only a starting point. Most systems have had some changes made since they were deployed. At the very least, option sets are likely to have been changed to meet business requirements. More commonly a few extra fields have been added to one system and need to be reflected in the other.
Often there are differences between the systems that require some flexible thinking to solve data problems. Some applications provide users with complete flexibility to make any sort of change, setup any sort of data entity, etc. On the other hand, other apps have limited customisation options, perhaps just a putting new fields on a form. As part of the integration design we need to come up with an approach to keep these different data structures in sync between the two systems.
Seamless makes changes to data and we want to be completely confident that the changes we’re making are as expected. When we transition from our workbench to a target environment, invariably we find things that are different. A round of testing will pick these up and allow us to make the necessary changes to ensure data integrity.
Additionally, a test cycle often results in evolution of the sync requirements. Users see data in situ and that sparks ideas which require changes to the sync spec.
The gold standard is an organisation who is running a complete set of test environments that are a mirror of their production environments. All we’d need is a different set of credentials for each environment and everything else would be like-for-like. It would also be great if everyone’s favourite sports team could win every match they play and that the ending of Game of Thrones was universally acclaimed.
Test environments might be behind production because of that hot fix that was quickly applied. Or we’re in the midst of a broader change project and test environments are ahead of production. Perhaps the environments are functionally similar but the test environment data doesn’t reflect a real-world data set. If the systems are not SaaS apps, it may be that connectivity for the systems is totally different.
Ultimately there needs to be confidence that testing results in the test environment are a meaningful representation of what will occur in the production environment.