Third Party Integrations
Podcast: Play in new window | Download (39.9MB) | Embed
Subscribe: Apple Podcasts | Spotify | Email | RSS | More
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.
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 dig into problems for you (and/or point you to documentation that you HAVEN’T found yet). You should evaluate whether or not you can quickly get ahold of a human being at the expected level of expenditure for your application. While it isn’t reasonable to expect to get support from a real, live human being for $5 a month, it is reasonable to expect to do so when you are paying hundreds or thousands of dollars a month.
You should also look into their support guarantees. How long is the typical turnaround for getting a response from support. While support can’t usually guarantee a solution to a problem in a certain amount of time, they can and should guarantee a response. This response will let you determine what to do if a problem occurs. Don’t rely on development’s ability to “figure stuff out” when a problem occurs. While you might be able to do so, your response may not be optimal.
How good are their development processes?
Once you’ve evaluated their support processes, you need to get an overall feel for how well their organization can respond to issues, feature requests, and questions by evaluating their support process. Bear in mind that if your users have a problem with their integration, the expected response time of a fix is whichever is worse between organizations. Figure out if that will be acceptable by figuring out how quickly they solve issues.
While this is something that can only be really learned through experience, you can often look at user forums (if any are available) to determine how quickly the company can solve simple issues. You should also look at how frequently they release software updates, as well as their ability to release quick patches for rising issues, when determining the quality of their organization. NOTHING ELSE matters – you are outsourcing because you are more worried about results than implementation. Act like it.
Is their programming model familiar?
When integrating with a third party service, it can be tempting to choose an implementation that has the best features or the lowest price. While that is often a consideration, it isn’t the only one. In particular, if your development team can’t reason about the software, those issues are fairly minor. You need to look at how to integrate with their system and see whether it matches the way you currently do things.
You should also look for things like adherence to web standards. You don’t want to integrate with a software package whose REST implementation uses POSTS where GETs are more appropriate. If it doesn’t confuse you, it’ll confuse the next developer. Similarly, you may find that their API will be difficult to hammer into the way that you work with data. For instance, if they have an old-school SOAP interface when you have already moved on to GraphQL, you’re going to have a bad time.
How do they account for stability issues?
No software is perfect. Whether it is hosted on the cloud or on-premise, something will eventually go wrong, causing the software to stop working for a while. While downtime may be acceptable, lost functionality (or worse, data) is unacceptable these days. If you plan to integrate with other software and they use a webhook to send data back to you, how often do they retry (and over what time period)? If a webhook fails, do you have a means of getting the data some other way?
Basically, when you integrate with a third party, you are introducing another source of truth to your app. Because of this, you need to have a way to keep your data updated so that your primary system can be trusted. If an integration partner makes it impossible or difficult to recover from an outage, they are best avoided.
While you can mitigate many of these issues with infrastructure on your side, if a vendor doesn’t also take these issues into account, then your implementation will have to be considerably more robust in order to achieve a baseline of stability.
What is the testing landscape?
In addition to regular development use, your QA team will likely also be required to do at least some testing with the platform. So you need to consider how well it works for them. In particular, you need things like segregated QA environments, the ability to trigger error codes with certain requests, and the ability to look things up in a dashboard (without API calls) to determine what happened.
The “perfect” integration partner for a development team can be quite abysmal for the QA team. You might be tempted to let this slide, but if you do so, over time this integration point will become a headache. Remember that a big part of QA’s job is testing for regressions. When you have two disparate pieces of software changing separately, the opportunity for regressions is enormous and you need to make it as easy as possible for your QA team to do regression testing in an automated fashion.
What are the restrictions on usage?
You should also carefully consider what kind of limits are placed on your integration with another software package. This can vary a lot depending on why you need the integration, but a great example of this is the case of an email service provider. Email providers will want to limit the volume of email you send, as well as the CONTENT of the emails.
There may also be other legal restrictions regarding how you use data that you get from an external service. This is especially true of financial and personally identifiable data. You should ALWAYS get legal involved in these discussions.
Rate limiting is another issue here. You should determine whether the integration point can deal with the volume of data you are sending. Many integration partners will rate limit to make sure that one client doesn’t disrupt things for everyone else. This is actually a good practice, but is not any fun to be on the wrong side of.
You should also determine what level of monitoring, logging, etc. is available from integration partner, without the requirement of writing code. While it’s great if they have an API for this stuff, you won’t be using the API initially.
This means that you should start out with a dashboard (you’ll likely need this for showcasing things to management as well as QA/Debugging tasks anyway). It should be as simple as possible to determine whether your requests are going through their system or not, without writing code.
You should also pay attention to how quickly the dashboard updates. While a dashboard that updates daily might work in some circumstances, it can be pretty annoying for debugging a problem that just occurred in dev, and can be absolutely awful if a problem occurred in production. You should also pay attention to dashboards that show application stability and availability, as you WILL be wanting those to be of quality when the inevitable outage happens.
Tricks of the Trade
When evaluating software to use at your company you want to be very picky in the process. However, remember that it was developers like you who wrote it and they may have close attachments to their code. Be honest with your boss but if you are talking about it publicly or in front of the people from that company remember that you don’t always write the best code all the time.
Join Us On Patreon
Level Up Financial Planning
Donate to Beej’s Mission Fund
Memo: Put “BJ Burns” in Memo