How do you know which applications you should build integrations into and which ones you should use an integration platform?
It’s easy for an integration platform to provide the answer of always, but that may not be the best answer for your specific situation. Some applications require an afternoon pizza with your team, while others require pizza teams of experts from a global service integrator. However, there are thousands of applications in between where you’re not sure what it takes to be successful. Here are 8 questions that you can use to see when it is ideal for your organization to leverage an integration platform.
1. Who will maintain it?
Building an integration can feel like this.
But maintaining an integration can feel like this.
It means waking up on the weekends to clear the trail for others, and more importantly making sure they use it as you intended. Integrations are a not transactional agreement, they are long-term, attached to the hip, type of relationships between your application and someone else’s. This can be hard for development teams in the long run because expectations move from accomplishment to...unbroken. Integrations are expected to work, regardless of what’s happening between the different applications.
2. Do you want the expertise?
Put another way, how much time do you want your team in someone else’s application? There is a fine balance between learning the nuances and tribal knowledge of your own product and finding the hidden gems of value in an application that you don’t control. Some organizations want this expertise because it enhances their own value proposition and deepens relationships. Whereas others can’t afford the high cost of discovery time in an application outside of their control.
3. What is the endpoint environment?
SOAP, REST, SDK, WSDL, OData? Payloads in XML or JSON? Maybe you get to play with some new hotness like GraphQL or gRPC? Better yet, is it On-Prem? Knowing the delta between your destination environment and your team’s skills can help guide which applications should be on your integration roadmap first.
My hope is that in the future there will be API payloads in emoji, if not solely for the benefit of error codes. Not only would they be understood internationally, but also make testing more enjoyable.
4. Do you need a connection or an integration?
This might seem like a trick question so I want to explain the difference. A connection is simply moving data from one place to another. But if you need an enterprise-grade integration there are few added bonuses that are worth your consideration.
- Authentication: OAuth or basic creds? This is often the hardest aspect of integration.
- Eventing: A majority of applications still use polling, so you might have to build a polling framework depending on what your definition of real-time is.
- Bulk: If you’re feeding data-hungry applications like analytics or machine learning the question of how much and how many become a higher priority.
- Custom Objects: This is precisely how a vanilla SalesForce implementation becomes a custom integration.
- Other things to look for are differences in Error Codes, Search, and Pagination.
To dig deeper into the features that make up a true integration, check out the Anatomy of an Element here.
5. How flexible is your orchestration?
You can often think about it serving your data in two ways. A prix fixe menu or recipe, stating how your users can use the data. Or family style, in which everyone chooses how to eat even as your dinner party scales.
6. What is your time to market?
Think of your product roadmap of having all the things that will make you all the money. It will likely be composed of features for your product and integrations or time spent on someone else’s application. But if you can do both at the same time, you can build your own features faster.
7. How many are you doing?
Many of our customers begin with CRM or Marketing Automation because there is a similar flavor across them. A /Contact is a /Contact, a /Lead is a /Lead and so forth with slight variations. But does that hold true if you now want to integrate into financial and accounting systems? And what is the difference between those and e-commerce platforms? The question becomes not how many integrations you want to have, but how many different use cases you can support. Every time your use case changes so does your integration strategy.
8. How is it sold?
This final question gets to the crux of the return on the investment. We typically see our customers fall into 3 different categories for taking their integrations to market.
Our recent State of API Integration Report showed a majority of organizations agree that at least a quarter of their user base would upgrade or renew if they have integrations. For larger organizations that could mean entire lines of business could be affected by your integration strategy.
To bring it all together, here is a quick mental checklist to help determine the ROI of integrating APIs.
These 8 questions should guide your team in approaching integrations of any size and complexity, with more confidence and clearer expectations. Continue to educate yourself on determining if you should build vs buy integrations with a recent blog post here.
To help shape the future of the integration landscape and make your mark on the industry's leading annual report, fill out the 2019 State of API Integration survey. As a thank you for filling out the survey, you'll receive early access to the report next year.
*This blog is a modification of a talk I gave at API World, Build vs. Buy and ROI of APIs