“Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should,” says Dr. Ian Malcolm in the movie Jurassic Park.
Although we’re not cloning dinosaurs, a similar caution could be applied to software integrations.
Nowadays, we live in such an interconnected world that everything from our household appliances to our business software has the ability to speak to one another, and it’s easier than ever for users to integrate these tools with many web apps providing pre-configured integrations and open APIs.
But, before you think about what information can be passed between systems, you need to think about your integration’s objectives, maintenance and implications on other tools or stakeholders.
Here are four best practices to keep in mind when implementing tech stack integrations:
1. Keep User Needs in Mind
Every integration should start with a well-designed user story and conditions for satisfaction. A user story explains in one or two sentences how and why a feature will provide value to a customer. It also ensures that the integrator understands the real-world use case of the integration. For example, “As a sales user, I want the customer fields in Salesforce to be updated from HubSpot in real-time so that I can rely on both tools to have accurate customer information.”
In the case of integrations, providing your integrator with a user story rather than pre-established, exacting criteria allows them to build a user-focused solution using knowledge gleaned throughout the creation process.
Regardless of what tools you’re connecting, the integration itself is never the end goal — the practical application of that integration for the user is.
2. Designate a Responsible Party
Although it may seem like an integration is static upon its creation, it’s only a matter of time before an endpoint changes, a security key is updated or the integration just stops working for any number of reasons. Compound that with multiple administrators making updates and you set yourself up to have issues popping up left and right with no clarity about who’s responsible for resolving them.
Inevitably, integrations will require maintenance, and when they do, you want an individual who is already familiar with inputs, outputs and potential pitfalls and who knows their role as the responsible party for the integration to be prepared to step up — even if multiple people are able to make updates.
To help manage this at New Breed, we created an accountability matrix that documents who’s responsible for overseeing each tool in our tech stack and their various integrations. When there’s a lack of clarity over who is responsible for making changes, you can expect what always happens in these situations: deprioritized resolutions and too many, or too few, cooks in the kitchen.
3. Create Comprehensive Documentation
Thorough documentation of your integration from the get-go will pay dividends over its lifetime. Whether it’s time spent explaining its intricacies, deciphering ambiguous error codes or decoding jargon, good documentation is critical in reducing the time and effort spent in maintenance down the road.
Documenting from a development perspective as well as an end-user troubleshooting perspective are both equally important. While questions like “What does this error code mean?” and “Why hasn’t my data formatted the way I expect it to?” may have different reader groups, they both provide necessary context to people who will work with the integration.
One way we document integrations at New Breed is through the use of flow diagram tools that map out the flow of information from tool to tool, the various “source of truths” for data fields and object dependencies.
Another common form of documentation is knowledge bases full of written resources that can provide users with guidance about troubleshooting and utilizing features.
4. Think About Integrations When You Build Out Your Tech Stack
When you’re evaluating new tools for your tech stack, consider the integration options available and how you intend for your systems to speak to one another.
Are there pre-built, native integrations you can use? Do you need a developer to build a custom integration? Do you need to use middleware to connect that platform to your other software?
Platforms with native integrations to each other are easier to maintain than those that don’t.
Consider too what type of automated testing and error logging is already provided. Will you be notified if an integration breaks? How will this integration perform once your company doubles in size?
The Takeaway
There are a plethora of integrations available to you, but do you need them all?
Too many integrations or overly complex integrations can be hard to manage, especially with a large tech stack featuring multiple platforms.
Some integrations don’t offer a lot of value, and if you just set them up because they were available, they might not be worth maintaining. It’s important to be intentional about why you’re connecting different tools in your tech stack, and ensure building that integration delivers value to the end-user.
