Ever since Web 2.0's value as a buzzword started to degrade, and cloud technologies emerged from the primordial sea of basic web services, technology leaders have been competing to come up with new *aaS acronyms. We started out with the IaaS, PaaS and SaaS trinity, and everything after that has essentially been different combinations of infrastructure, platform and software, respectively.
Here at Youredi we specialize in iPaaS, which stands for Integration Platform as a Service.
At a high level, we provide a platform that enables it's users to create integrations. The platform consists of a software suite (that we built), which is a platform for storing data and running different kinds of integration related functions. On a deeper level, our platform runs on infrastructure, and platforms, provided by Microsoft Azure. So when you really drill into it, it's the perfect combination of IaaS, PaaS and SaaS.
Gartner defines iPaaS as:
"A suite of cloud services enabling development, execution and governance of integration flows connecting any combination of on premises and cloud-based processes, services, applications and data within individual or across multiple organizations."
Like many of these acronyms, iPaaS can be a loosely defined term. Therefore, after reading a recent blog written by Liaison that claims an iPaaS is a bridge to nowhere, I was rather confused. The blog post seems to put iPaaS into a small box which limits it definition strictly, and at the same they are pushing out yet another acronym, dPaaS: Data Platform as a Service.
An example provided of dPaaS is their new product Liaison ALLOY Platform which is described as:
"A new approach to integration called Data Platform as a Service (dPaaS). dPaaS is a cloud integration and data management model named for its ability to provide PaaS functionality at the point of data analysis—without encumbering users with the particulars of the underlying data capture, integration, or management mechanics."
After processing this, I realized that the minds over at Liaison actually think much like ours. In the last year we have built an addition to our iPaaS product in the form of real-time analytics. When building both an iPaaS system and actual integrations for our customers, we realized a simple but important fact: integrations are all about the data. There are no business software solutions without data, and there are no integration solutions without data. And since we already have the data flowing through our system, why not provide our customers with some insight into the data?
So we built the Analytics product, which provides business process analysis, and baked it right into our iPaaS product so that it's easy to include in existing integrations without having to change products or refactor working solutions. At the same time, Youredi Analytics can be used as a stand-alone product and any system with integration capabilities can use it to analyze business data without even using our integration platform. Flexibility at its finest.
Technologies evolve but rarely perish. The same goes for iPaaS. It grows around it's own context and adapts to different requirements.
Integrations are not a new concept. We used to refer to them as interfaces and services that other software products used. The issue before integration platforms arrived was that, as a software developer, you had to do everything yourself when building an integration. You had to build the interface technologies, logging systems and the error handling and ended up spending a lot of time on everything except the actual integration logic. For these parts you often copy-pasted stuff from previous projects, changed them a bit, and after a while, you were in a situation where you had multiple integrations with various implementations, that managed errors differently, logged to separate locations and were poorly documented.
This is why integration platforms were built. To provide the boring stuff so you don't have to, and so that you can concentrate on the actual beef. Because really, that's what it's all about - building logic between systems and documenting that often complex logic. Surely there are cases when the two systems being integrated actually speak the same language and maybe even the same dialect. This is nice because you can just use a ready-made integration solution. However, a majority of B2B integrations being built don't have that luxury.
In the early days, the vision of Youredi was to be the integration platform of everyone. Anyone could register and simply start building integrations. Our hope was that building integrations between simple systems might actually be that easy. But with B2B integrations there's a lot of things to take into consideration. Even if the systems use the same standard or specification, there are often differences in how these standards are interpreted, customized and implemented. And even more often systems don't follow any standards or have built their own ones. And it's understandable, that when you concentrate in building a software product for humans, you often don't have the same will or the resources to make it compatible with other software systems.
That's when you need integration specialists to do the job. That's who we are building a better product for. These skill sets are indeed scarce and that's why these people must have the best tools available that allow them to produce scalable, repeatable, well-documented and stable integration solutions as efficiently as possible.