If you’ve begun the discovery of how to tackle your integration backlog, you’ve likely learned that the research and API knowledge required is extensive. The build will occupy your most technical engineers and the whole project will detract from your core product roadmap and distract from your unique subject matter expertise of your product’s domain. It’s for all these reasons that teams delay addressing the integration requests from customers.
Some iPaaS vendors have tried to box this need as simply a connectivity problem, and to address that, they believe a purpose-built open interface (also known as API) to third-party applications is all that is needed for your product and engineering teams to launch integrations. These vendors offer libraries of APIs to third-party systems without addressing the questions of “who is using these APIs?” and “how do they add value to the business?”.
There is certainly some truth to the connectivity problem and APIs are helping with this but, as often happens in technology, it’s easier to focus on cures for specific symptoms instead of looking at the “big picture” and identifying the root cause of the problems you and your team are trying to solve.
What is API connectivity?
API-led connectivity is an architectural approach that serves as a guideline to implement APIs with specific sets of characteristics.
At the core of this approach is the notion of the XPS layers: eXperience, Process, and System.
As opposed to a traditional methodology, the reason why this is called an architectural approach is due to the flexibility of the criteria and characteristics used to allocate APIs in each layer. Ironically, this flexibility (which often leads to uncertainty and ambiguity) as well as the underlying assumption that everything has to be an API (ergo the name API-led Connectivity) are the source for the most common pitfalls of this approach.
How do XPS layers work?
While it varies depending on each organization, based on some generally accepted guidelines, the criteria for each layer is usually as follows:
- eXperience: APIs tailored specifically for the “system of engagement” (e.g. web app, mobile app, etc.)
- Process: APIs focused on orchestration and generation of “value-added” or “data aggregation” services (e.g. Customer 360 API)
- System: APIs focused to mirror the low-level “CRUD-like” capabilities of the underlying system. The main focus of this layer is to standardize access (through REST APIs) to every underlying technology stack
The downside of API-led
Over-engineering is a common complaint from seasoned architects who understand that “architecture for the sake of architecture” only goes so far and that a pragmatic “simple is better” approach is often more effective, valuable, and efficient. In addition to this, some but not all, of the most common drawbacks are:
- APIs are a solution to a technical problem, not a solution to a business problem. The business problem is how to automate the processes and experiences that run the business end-to-end
- Until someone does come to consume an API, it does nothing, and therefore APIs are only a half step. They always require someone to develop a business process or application that consumes them to be useful
- A disregard for common (and sometimes cost-prohibitive) network latency introduced by API interactions between the 3 layers
- The lack of clear boundaries/scope for each API (e.g. do I need a System API for Salesforce? what if I already have a SOAP endpoint?)
- Chatty interactions between APIs depending on the level of granularity and exacerbated by the common distribution of the 3 layers of APIs
API-led can certainly provide several benefits, mainly within the space of application modernization (e.g. when trying to modernize existing applications that don’t necessarily expose any sort of API). However, APIs alone are not implicitly valuable, thus, in order to drive value, your customers need the ability to automate processes end-to-end and not just expose an API and leave the responsibility of driving value from the API to the consumer.
The role of APIs in enterprise automation
Automation is one of those words that in the context of business and technology can mean different things to different people. For some, automation is synonymous with integration. For others, they are completely unrelated. But for most, there is a sense of correlation that can’t be clearly explained due to our prior technological biases. In the same way, the industry came to realize that “APIs + Integration” were better together; at Workato we’ve taken that concept to the next level by adding automation into the mix.
Workato, the leader in Enterprise Automation, offers an Embedded Platform that accelerates product innovation and adoption by offering integrations at the speed and depth your customers demand.
Want to learn more?
Schedule a demo with one of our automation experts to better understand how the Workato Embedded Platform can benefit your product.
