This article is focused on SaaS and Application developers considering how to best meet their end-user’s integration and automation needs.
Depending on what you read, and what you believe, the first API was released at the turn of the Century. Whether it was public or private, and whether it was actually 2000 or not, doesn’t matter. The point is that it was at least 15 years ago, positively stone age.
So we have all been dealing with how our applications integrate with each other for a little while now.
So much so that it’s now not so much ‘do you integrate?’ but ‘how do you integrate?’
Native Vs Third-Party Integrations
As SaaS CEOs/CTOs/Developers we can now coherently have a debate about the relative merits of Native Integration versus third-party integration. However you look at it the prime difference is how your end-users are interacting with your API. What is the customer experience? Are they achieving results from within your application (Native), outside your application (third-party) or more than likely a combination of both?
If you are a proponent of Native Integration then you already know that the enhanced customer experience comes at an enhanced internal cost. More engineering, more problems and more work outside of core application development. As your customer base grows, their integration needs grow and the workload to maintain satisfaction grows.
The release valve is often to focus on a handful of core Native Integrations and to capture the long-tail with off-platform integration partners. It will fully satisfy a percentage of customers, but what percentage?
Are we wasting development resources?
Need it be so? In truth one SaaS company’s integration needs are pretty similar to the next, to the next and to the next. We are all looking to integrate with each other and we are all building integration solutions for our respective applications. In effect we are all reinventing the wheel, and the car, and the motorways...I want my customer to be satisfied, you want your customer to be satisfied. Our customer is satisfied when they can integrate us together. Why am I building VHS and you building BETA when the customer just wants video?
In the end the key differentiator is the solution that we deliver to our end-users and not the interpretation of application APIs. In this day and age it is the video and not the VHS/BETA argument that is critical. The ultimate end-user’s prime goal is that integration is achieved and our prime goal as SaaS companies is that the end-user is satisfied.
This is where integration can perhaps evolve. Why shouldn’t integration become an infrastructure play where SaaS companies bolt a building block into their business, a building block on which they construct their integration solution? Same principle as hosting, messaging, billing, databases, load balancers……
Integration is all about pipes and connectors. We believe that the pipes and connectors can be standardised and that the SaaS company can build their own solutions on the core components. It turns the conversation from API management to API Orchestration. How do you conduct the data and how do you deliver the solution. Literally how do you orchestrate your API? Make the music by conducting the orchestra, don’t make music by inventing the instruments. The argument is that the IP is in the end-solution for the end-user and not in the fact that it has been coded completely from scratch.
Gone is the need to build the same components that everyone else is building. Gone is the need to build the same common ontology for data mapping that everyone else has built. Gone is the need to constantly monitor and adapt third-party APIs. Instead valuable developer time can be focussed on quickly enabling customer solutions, seamlessly branded natively from within your SaaS platform (AWS/Azure are invisible in the same way) and moreover without the need to disrupt core development processes.
A Fully Integrated Stack
Integration as a part of the Infrastructure Stack? Why not? Once a need becomes so widespread it is crazy to all be building the same solution. Own the solution not the problem. Consider whether API Orchestration is right for your business.
It’s not a new argument per-se. Very few arguments are. Focus on your core competencies and benefit from efficiency. Deliver an enhanced solution to your end-users without over expending effort on non-core tasks.
Lets’ stop reinventing the wheel and instead focus on satisfying stakeholders: satisfy your customer, satisfy your internal team. A rare win / win potential.