Third Party Integrations

So, your boss asked you to evaluate third party software for performing certain tasks within your platform (we’ll use email providers as a thought experiment on this one, since everybody and their mother has to evaluate those at some point). While many developers will see the feature set offered by a particular party integration and think “hey, I can write that in a weekend”, you need to understand that you actually can’t. When a company sells software as a service (SAAS), software is not the only (or even the primary) thing that they are providing. While the software implementation is important, many other issues come into play, such as system stability, ease of integration, licensing, cost, and restrictions around usage. In the more specific case of something like email providers, issues like compliance with legal regulation, rate limiting, monitoring, and content restrictions may also apply. In short, this stuff is never really simple and you actually can’t write something acceptable for the enterprise in a weekend. When you decide to integrate your software with a third party, it’s a long term decision. Not only is it hard to switch providers for most functionality, but unless the required functionality isn’t particularly important, it will greatly impact the future development of your application. A great integration can help grow your application, while a bad one can absolutely destroy it. No pressure though… right? Regardless, it can be a lot of pressure to put on a developer. However, all is not lost – while developers are often tasked with evaluating different third party providers for software, the decision is still (usually) left to management. You just have to make sure that they have the information they need to make a decision. Developers are often tasked with evaluating potential software integration partners for a variety of tasks. While the final decision is probably still left up to management, developers still need to be able to make realistic assessments of third parties, while avoiding getting too hung up on technology. There are many things that you need to consider when using a third party service as part of your application and these considerations go far beyond simply determining if the programming side of things will be easy to implement. Episode Breakdown How accessible and usable are their docs? If you google the answer for a question whose answer isn’t immediately obvious, can you find the answer? While their documentation may or may not be complete, most developers will rely on search engines in order to find results. This means that if their documentation is perfect, but is not adequately indexed by google, then it isn’t suitable. One thing you learn in software development over time is that the idea of RTFM doesn’t work at scale. Most developers (including yourself, under stress) will not read the manual, but will instead look for an indexed, easy solution to a problem. If the provider can’t provide one, then they aren’t suitable. Some companies will also hide their documentation and require a login to view it. In general, if the problem that you are trying to solve is fairly straightforward, you want to avoid these, as this is an additional barrier to entry for working with their software. You should also check to make sure that documentation is current. Many integrators have been burned by documentation that is a version or two out of date. If you can’t find documentation on the version that you are expected to use, that is the same as a complete lack of documentation. What is their support like? While documentation helps a lot, you shouldn’t count on it exclusively. Not every problem with any software package is easily known or quickly resolved. You may have to get in touch with a human being who can ...