Third party integrations and the importance of tech discovery
Integrating with third party services and tools is a common practice in product development. It allows organisations to leverage the functionality and resources of external platforms to enhance their own products and services.
But this can come at a cost: it introduces risk, adding yet another layer of complexity and dependence to your system(s).
This is a prime example of where technical discovery comes into its own.
What is technical discovery?
Technical discovery is the process of understanding the engineering and logistical nuances of a problem space or desired capability, with the ultimate aim of de-risking a way forward. For third party integrations, this typically involves understanding the capabilities and limitations of one or more services, as well as the technical requirements and dependencies needed to build out an integration.
This is important because it allows you to identify potential risks and issues upfront, and to plan and prepare for them. Without technical discovery, you may be unprepared for the challenges that arise during integration, and you may be unable to mitigate or address them effectively.
It also allows you to make informed decisions about whether to proceed with the integration and to get a feel for the level of complexity and effort needed to successfully integrate with the third party service.
And it doesn't need to be all about engineers here - the whole team can participate in technical discovery.
Five steps of third party integration technical discovery
- Identify and evaluate 🔍
- Plan your integration đź“‹
- Test in isolation 🔬
- Build in iterations 🛠️
- Monitor and maintain đź‘€
Identify and evaluate
As ever, the starting point here is to define the outcome that you're looking to achieve by integrating with a third party. What needle are you looking to move? What user needs are you looking to meet? The answers to these questions should ground all of the technical discovery activities that you undertake. And don't be afraid to ask yourself whether going with a third party is the best option - it might be that you can achieve your desired outcome with the people and expertise you already have in-house.
Before rolling your sleeves up and tumbling head-first down the integration rabbit hole, product teams should conduct an initial evaluation of the available technologies. This means researching and comparing the features, capabilities, and pricing of different third party technologies to identify the best fit for your product and business needs.
In addition to evaluating the technical capabilities of the technology, teams should also consider other factors such as the vendor’s reputation, support and maintenance services, and the potential impact on your existing product ecosystem.
I'd always advocate looking at a handful of alternatives if possible, and creating a one-pager for each that covers off the usual suspects:
- Name of the org
- Name of the product
- Link to the docs
- One or more support contacts
- Test credentials
- Pricing
- Service level agreement
- High-level capabilities, ideally with high-level architecture diagrams and examples
- Example implementations (so how other products and services utilise the third party product)
- Risks, concerns, assumptions, questions
At this point, you might rule some or all of the options out - this is arguably the main benefit of this step.
Plan your integration
Once you’ve identified the technology that you want to utilise, the next step is to develop an integration plan that outlines the specific steps and resources required to do it. This doesn't have to be all singing and all dancing. Again, a one-pager that covers the key activities, stakeholders, risks, and a high-level view of the anticipated work should cover it.
Test in isolation
Before integrating the new technology into your product it’s essential to test the integration in a controlled environment to ensure that it functions as expected. This allows you to identify and fix any potential issues before they become a problem in production. Testing should include both functional and non-functional testing, such as performance and security testing, to ensure that the integration is robust and secure.
Build in iterations
Once the integration has been successfully tested, you can line up the work to actually build it into your product. It almost goes without saying, but it's of paramount importance that this is done in small slices.
This enables you to gradually introduce the new technology into your product, giving you the opportunity to monitor and assess its impact on other systems and processes, and further de-risk the wider integration as a whole. You'll also be able to make any necessary adjustments or changes to the integration without disrupting the entire product, and it's also a good opportunity to share learnings with the rest of your team, and perhaps even to give feedback to the third party on how the integration has gone so far.
Monitor and maintain
After the integration has been successfully implemented, it’s important to continue monitoring and maintaining it to ensure that it continues to function as expected - the ideal would of course be to bake in monitoring from the start.
In addition, product teams should also monitor the performance and usage of the integration to identify any potential issues or areas for improvement. By proactively monitoring and maintaining the integration, teams can minimise the risk of unexpected problems and ensure that the integration continues to add value to the product.
In summary
Integrating new third party technologies into your product can be a challenging and risky process. However, by engaging in technical discovery, you can surface complexity early, minimise risk, and increase knowledge and confidence, which will hopefully prevent you from aimlessly plodding on down a cul-de-sac and ultimately give you the best possible chance of reaching your desired outcomes.
