During a trip to Prague, I had to call my Uber driver to tell him at which of the dozen train station exits I was waiting for him.
This seemingly unremarkable moment was memorable for me because as I stood there I realized that in order to place the call, I didn’t need to use a local cell phone carrier to place the call, the Uber driver didn’t need to be on a network compatible with my carrier, and the Uber app developers didn’t need to devote significant developer hours to building their own integration between these two (and countless other) telecom systems worldwide. Instead, Uber used Twilio in the background to connect with the Czech Republic’s telecom system and facilitate communication on the Uber platform between myself and my driver.
From a user perspective, this permitted a Brazilian to talk with a Czech seamlessly via a rideshare app, without worrying which country I was in or which carrier I had. From the Uber developer’s perspective, the difficult but necessary feature of speaking with your driver was turned into a single integration that allowed them to connect drivers and passengers anywhere in the world.
Imagine the complexity of integrating with all the world telecom networks without a platform like Twilio. As I got in the car I couldn’t stop thinking about the concept of integrationless and where we already see this model being used to power the next era of software development.
When done right, integrations allow for robust data ecosystems, creating value that complements and often exceeds individual applications. But getting to that ‘perfect state’ can be a long, winding, and expensive path.
For example, in some instances, the planning, architecture and design for just one integration can take anywhere from 3-6 months.
What if instead of spending time and resources on translating proprietary formats, maintaining integrations as partner APIs change, and building a critical mass of integrations in order to create value for your customers, you could instead be hyper-focused on building the next solution for your customers?
What If Software Development Was Integration-less?
Integrations can be difficult and time consuming for many reasons. The most common reasons are poor documentation, overly complicated partner APIs, unique data models, and adding a user interface that allows for seamless interaction between your app and the partner app. To understand this problem, consider that each telecom carrier encodes their emojis differently or that many banks do not have real APIs.
In addition to the problem of individual integration complexity, there is the larger issue that there is rarely just one company that all of your customers use and demand an integration with. It is more likely that you will need to be compatible with a category of apps rather than just one or two. An example of this is Venmo. If Venmo is only compatible with one or two banks, it is far less valuable than if it was compatible with any bank. In fact, it would likely not be valuable at all until it hit a critical mass of compatible banks and the majority of users wouldn’t feel a limitation.
Some industries, like telecom and financial services, have already overcome these challenges. Companies offer industry-specific services that help developers interact with many data sources and companies in their industry via a single, standard interface. These companies act as the connective tissue among different organizations with different data, in different formats, and remove the complexity of building multiple integrations to a category of partners.
For example, Twilio allows applications to interact with almost any telecom system in the world via a single API—allowing you to send a message through an application, without you or the app needing to work individually with each different telecom system or carrier. These integrations still exist of course, but they are built and managed by Twilio, who offers access to their pre-built and optimized telecom infrastructure as a service. Twilio’s single API allows apps to be instantly compatible with any telecom company in the world.
Plaid is another example: it’s used by many applications (like Venmo, Carvana, and Varo) that need to be compatible with different financial institutions, both in the U.S. and globally. Neither the customer nor the application needs to work individually with each bank in order to process a transaction. Instead, Plaid builds and maintains the connections (either via official APIs or custom-built workarounds) and offers this infrastructure as a service to fintech companies. In other words, Plaid’s single API allows apps to be instantly compatible with any bank.
Both of these organizations are delivering what we now define as integrationless services.
An integrationless service is the connecting piece among multiple data sets and services, organizations, and formats. It’s a service that functions as the common ground among companies and data sets, regardless of what data model, programming language, or authentication mechanism is being used.
Serverless - A Parallel Idea To Integrationless
To understand what integrationless can look like, we can look to the “serverless” philosophy, which is already being used at scale. Andy Kimball detailed in a recent article how Cockroach Labs built a forever-free serverless SQL database. He explained, “Serverless means you don’t have to think about servers. Of course there are servers hard at work handling your application’s requests, but that’s our problem, not yours.”
As Kimball goes on to share, they do the behind-the-scenes work like allocating, configuring, and maintaining servers. Then, the client only pays for their application’s request to the database and the storage that data consumes. This allows developers to focus on the code, not maintaining servers.
Amazon Web Services (AWS) promotes this philosophy, featuring the ability to build and run applications without thinking about servers. Stating in their article, Serverless on AWS, “Serverless technologies feature automatic scaling, built-in high availability, and a pay-for-use billing model to increase agility and optimize costs. These technologies also eliminate infrastructure management tasks like capacity provisioning and patching, so you can focus on writing code that serves your customers.”
Image Source: Introduction to AWS Lambda and Serverless Applications, Amazon Web Services
A serverless application doesn’t mean the servers don’t exist: it just means that now there is a service that takes care of the servers (and backend processing) for you.
Mirroring that idea, what if we had services that provide all data integrations for you so you can focus on new features built upon the partner’s data and services?
Integrationless can be thought of as a higher level cloud service. Simply put, you could spend less time on backend integrations and more time on building new value for your users. In fact, this already exists in multiple industries.
Integrationless Is Different Than Standardization
Computer Science has plenty of examples of standardization: programming languages, SQL, and many network protocols. However, pure standardization isn’t enough to be called integrationless.
The figure below illustrates this idea. Standardization (on the right side) is the easy part. Programs like REST, SOAP, or GraphQL can transfer data into any standard format, like MP3, XML, JSON, or GEOJSON. But the hard part is on the opposite side: taking disparate, incompatible data formats that already exist and helping companies, apps, or services actually use the new standards properly. This is where integrationless services can drive the most change.
Image Source: RIP Hard Voice Apps Privileged, Twillio Inc.
In Agtech, an example is the ADAPT framework. Although the framework covers almost all the areas of farmwork, the usage is still very clunky. Each OEM can create extensions of the model, which leads to inconsistent “versions” of the same standard! The framework only uses C#, which forces developers to learn this programming language. Simple, accessible documentation is still lacking, and there are many bureaucratic barriers, like finding the right libraries (DLLs), accepting one usage term per OEM or calling different support teams when needed.
A true integrationless model will be:
- Unique: providing a unique way to use the data or service.
- Multi-source: taking disparate data sources and connecting them back to disparate companies, apps, and/or platforms (like the Uber example: Twilio is so beneficial because it helps Uber’s customers connect to multiple countries’ telecom systems).
- Seamless: Since there will be multiple sources of data or services, the integrationless provider will need to transform the data to and from the unique model.
- Using standardized communication protocols: Integrationless infrastructure will be present in many technically different application stacks (especially if there are many sources of data), so using standards like REST, JSON, or GraphQL is key.
- Constantly and automatically maintained: Any complex system will need maintenance to keep multiple sources coordinating with each other—but relying on manual or inconsistent updates is not a solution.
- Easy to start: It makes no sense to have an integration framework that is difficult to use. Someone should be able to launch the platform and have it running, without understanding the details of how it was created, or needing to learn a separate programming language (AWS Lambda is a great example).
With integrationless solutions, CEOs, CTOs, project managers, and developers can stop wasting precious hours coding, testing, and deploying various integrations depending on an application or company’s programming language, data model, or authentication method. Instead, they can lean on integrationless services to do that back-end work, while they focus on developing and marketing services to their customers.
Integrationless services unleash an industry’s potential to scale its growth, without having to redevelop its tools from scratch.
In Agtech, that potential for growth exists—but the industry needs integrationless solutions to be realized.
Leaf's mission is to help companies build the future of agriculture by providing intuitive, powerful tools so that developers can focus on their core applications and deliver value to their customers.
Leaf's unified API helps Agtech companies become instantly compatible with all major agriculture data sources so they can focus their full effort on building valuable applications for their customers while Leaf’s team manages the complicated and time-consuming challenges of data integration, file translation, standardization, and ongoing integration maintenance.
