Our Workflows With Third-party Applications
Integration Via Interfaces
Because third-party applications are an important part of the service that we offer, it’s necessary to expound on how we work with them.
The nature of integrating third-party technologies is that we are dependent on changes that do not create incompatibilities with previous versions. In some cases, data we integrate is delivered through a standard – RSS, for instance. However, for the most part, we integrate external data via interfaces (APIs, or Application Programming Interfaces) that the third-party makes available.
Continuously Resolving Approach Drawbacks
Challenges – Resolved
Suppliers change their APIs. Sometimes this is to provide the availability of new features, sometimes it’s because of changes to data policies. Regardless of the reason, we make sure these don’t hinder our users and clients.
Suppliers are free to choose the technologies that they develop their applications on. The problem is when these technologies are not aligned with our own. We understand that the audience for our products is wide-ranging and has a varied selection of devices. Our code is built around adapting to this variation to support as many potential viewers as possible.
The nature of the technology we use and the utility of the products we create are such that there will always be new third-party applications with which we want to integrate.
Our Product Managers are constantly on the lookout for new apps, technical advances, and trends. It is in building a business case for such new integrations that we need to be very clear about the nature of the ongoing support of integration. Only then can we decide whether it will be useful for our clients and their viewers, and be cost-effective.