Integration platform-as-a-service provider Cloud Elements yesterday announced the availability of Conductor, a no-code solution that enables developers and non-developers alike to create complex API integrations in a point-and-click way.
The Conductor tool is part of the Cloud Elements 3.0 platform that, according to the company announcement, “starts by unifying APIs with enhanced capabilities for authentication, discovery, search, error handling and API maintenance. These ‘Elements’ can then be combined into workflows (aka Formulas) that automate business processes across applications. Elements and Formulas can be easily modified, shared and re-used, significantly improving developer productivity. Elements also shield developers from underlying API changes, significantly reducing maintenance costs.”
Ross Garrett, Cloud Elements CEO, told SD Times that said many vendors in the integration space began when point-to-point solutions ruled, because when there were perhaps five or six or 10 things to deal with, that pattern approach was fine. But that is not the world we live in today, and virtual data resources are the core construct behind the one-to-many approach Cloud Elements takes to integration.
“It’s a fresh approach, turning the program on its head. That’s how we approach that particular problem statement,” he said. “How do you create an integration pattern for scale in 2019 and going forward?”
Ross said that “for most people thinking about the concept of application integration, they think about it within the context of the four walls of their business… how do I make the applications I use inside my company work together? There are lots of vendors helping to solve that problem. But integration actually expands beyond the four walls of your business. There is a whole ecosystem of applications that sit amongst your customers and partners, and is there a way that we could provide a more seamless, self-service integration experience for those use cases too.”
In the 3.0 platform release, Cloud Elements introduced the concept of virtual data resources, designed to help organizations unify the data they care about and create a more seamless, one-to-many experience, and to help developers that are integrating multiple products.
Using the example of expense and travel management software integrating with a CRM or and ERP system, Garrett explained companies have predefined notions of what an expense report should look like, with a predefined data structure. Virtual data resources enable the APIs involved to look and feel the same, so the company doesn’t have to figure out the nuances and differences of the various APIs. “You can seamlessly map and transform data between those products,” he said.
The thinking behind virtual data resources is to standardize a common language for data sharing. “We’ve seen things like the Open Data Initiative and agreements between Adobe, MIcrosoft and SAP, to sort of start to talk about using a common language for the sharing of data that should be standard but is often times not,” Garrett said. “The concept of a customer, or a contact, or partner, or an invoice, or whatever… there should be a standard for those data objects, those resources. We’re working with folks like the Open Data Initiative, and we’re building our own stack of predefined data objects that hopefully will become the de facto way you think about these types of resources. Kind of like schema.org for API, is the way I like to think about it. Standard ways of representing common things. There’s no reason why we shouldn’t think like that. API providers are representing very similar things but in very different ways. We’re trying to unify that experience for users.”
