Many of the stumbling blocks faced during integration projects - in this case integrating local streaming clients onto set top boxes and digital media players - are not technology issues, but people issues. Habits, clarity, and interpretation can become enemies or friends on the journey. And once we accept this and prepare accordingly, integration projects can be executed mistake-free.
Engineers have bad habits (I can say that, I am one!) and will spend weeks on optimizing fragments to save minutes, it’s a behavioral thing. If there is a gap - engineers will fill the gap and invent a solution to solve the problem. At ActiveVideo we treat integrations as a Lego building exercise, where the Lego blocks are simple sets of atomic functionality, and we bring the blocks to the table to be assembled according to a clear set of instructions. If we take people’s habits, their ability to make mistakes, and lack of domain knowledge off the table we can mitigate many common client integration problems.
When there is a lack of clarity within the integration process, people tend to construct a technological edifice that they become invested in. At some point, that all needs to be unraveled in order to move forward.
When integration points are open to misinterpretation, mistakes happen. We take a simple ‘design by contract (DBC)’ approach which treats the API as a contract, we define the pre-conditions (things that need to be in place before integration happens), invariants (things that must not change as a result of the integration) and post-conditions (things that happen as a result of the integration) that bound the integration. Formal thinking takes uncertainty off the table as functionality can’t be misinterpreted.
The way the client itself is developed has an impact on integration. Integrations often require the full API to be stubbed before a single block of functionality can be integrated and tested. If the client has minimal symbolic link dependencies and uses a capability/registration framework to attach functional blocks, then integration can be iterative. Each step can be planned, tested, and measured independently. This also simplifies compatibility management, allowing us to achieve binary backwards compatibility over multiple versions.
Provide your integration partner with the tools they need to integrate your client, documentation to help guide them through reference code, and any test tools and assets they may need to confirm what they’ve done. A failed integration results in continual support. If there is clarity throughout, the integration goes well, and you shouldn’t hear from them! In a perfect world, even if there is a rich set of support systems in place, e.g. Jira or a similar platform that they can report issues through, the integration partners shouldn’t have to get in touch - they will have what they need to move forward and perform integration at scale
The goal is to make integration as simple as possible - just like Lego building - so it’s wise to invest the time and prepare well to reduce the support burden long term. This is the approach we’ve adopted when developing our own client for AppCloud, ActiveVideo’s virtualized video app platform. Get in touch to learn more
