As web apps abound, they’re becoming more and more interconnected with one another. Thanks to open and documented APIs, developers can integrate functionality from other apps into their own software, making the apps more useful and preventing data from being stuck in silos. In general, of course, this is a very good thing, but it nonetheless introduces dependencies between these apps. Why is that important? Because as more and more apps come to rely on one another to provide critical services in our day-to-day work lives, the greater the consequences to both our data and our productivity become if and when these apps fail.
Take, for example, online file storage service Dropbox. It has an open API, good documentation and works across some of the leading mobile platforms, including iPhone, Android and Blackberry. Among developers, it’s an increasingly popular choice for cloud storage functionality in other apps. Examples of this include AirDropper, an app that lets users request files by email to be uploaded to a Dropbox account, and PlainText, an iOS text editor with Dropbox sync.
But Dropbox recently went down, causing much consternation among its users, particularly because it took a whole ecosystem of apps that rely on it down when it failed. A situation like that is little more than an inconvenience if the outage lasts only an hour or two, but what happens if the problem takes longer to fix? And for that matter, what would happen to Dropbox-reliant apps if the company went completely out of business?
There’s absolutely no reason to think Dropbox is in danger of disappearing; it’s a successful app with several million users. I could probably have made an example of some other apps that also commonly get integrated: Freshbooks (a popular choice of integration for providing invoicing functionality), Basecamp (for providing project management integration) or Remember the Milk (for tasks/to-do list management features) all face the same risks as Dropbox in terms of interconnectivity. And it’s not just the smaller startups in danger of suffering from outages. Even the mighty Google, a company whose apps are, unsurprisingly, extremely popular choices for integration with other apps, suffers from occasional outages that take out not just Google’s own tools, but all other apps that rely on them (many of which are listed in the Google Apps Marketplace).
Users don’t have much choice over how apps are integrated with Dropbox, Basecamp or any other software. The task of mitigating the risks, then, falls to developers, and here are a few key points they should keep in mind when developing, implementing and integrating their apps:
Consider the user. Just because a particular app is a popular choice for integration doesn’t mean that it’s currently the best choice for your specific base of users. A popular app like Dropbox might be suitable for those who need it to store casual, non-confidential data. But it’s not suitable if your if your users will be storing more sensitive information (financial records, for instance) or have a need for their data to be always [BE] available.
Examine an app’s risks early on. Look back over recent history and see how well the app has performed: Have there been any major outages? It’s also worth reviewing the app’s business model, revenue streams and how well-funded it is: Is it likely to still be around in a few months’ time? Integrating with a brand-new app from an unknown vendor is risky, but even apps from extremely well-funded companies can fail. Google, for instance, recently decided to kill off its high profile “email killer,” Wave. Any companies that had invested time and money in building integrations with Wave are probably regretting it now.
Use multiple, redundant services for any utility functionality. Using third parties to provide required functionality (file storage, for example) is always risky. Minimize that risk by having multiple redundant services providing that functionality, ready to swap in should one fail. It’s worth investigating whether there’s a less risky means to achieve the same goal. For example, could you use Amazon S3 instead of, or in addition to, Dropbox? And where possible, try to use vendors that provide an uptime guarantee in their service level agreement, such as Amazon.
Offer choice. When integrating with a third-party service that provides fairly complex functionality (say, deciding to integrate software with an invoicing or CRM app), choice matters. In providing users with more choice over the apps you integrate with, you’re not only making your app more attractive to existing users of those apps, you’re also reducing the risk of dependency on any one service. Outright, for example, is a bookkeeping app that integrates with a wide variety of other products from companies like eBay, PayPal, FileLater and Shoeboxed.
In an interconnected world, it’s too easy to become overly reliant on a small handful of service providers, and that presents a risk for the whole web app ecosystem. I’m not suggesting that integration between web apps is bad or undesirable — far from it — but, as an industry, we need to mitigate that risk by making sure that we don’t become over-reliant on certain services. By taking steps to reduce that risk, we not only prevent inconvenience for our users, we also help to keep their data secure.
