You can get the whole conversation and transcript over at the Google Cloud Platform Podcast site here
. But we wanted to share some of what we talked about.
First, we explained what Pandium is - the only integration platform designed specifically for building and entering in-app marketplaces. Traditional integration platforms, in contrast, were built for enterprise workflow automation.
When Pandium was designed, we were aware (from personal experience) that using traditional integration platforms to power in-app marketplaces created a lot of problems.
Even though traditional platforms have pre-built connectors amongst software, they require a significant investment of additional engineering to make them suitable for powering in-app marketplaces.
Issues around scaling and authenticating end users and technology partners, and having an in-marketplace, pose new challenges that do not exist if one enterprise is using the platform to automate their internal systems and workflow.
No code and low code tools are currently trending, with many fans of digital transformation looking to expand no code tools' footprint within organizations.
Here at Pandium, we believe low code and no code tools have their place, and can improve business efficiency and make both business users and developers' lives easier.
However, when no code tools are used for the wrong use case, you can end up with the worst of all worlds: rigid and limited tools that do not allow business users to accomplish their goals, and require in-house developers to come in and code around specialized systems. In those cases, you end up spending more engineering resources for a worse result.
Some of the factors that affect whether a tool should require coding: is the user a developer, and can they accomplish the task faster by coding? Does the user need the flexibility to change the functionality? Does the user need to customize the functionality or output? And is the no code tool capable of meeting the business objective?
On the GCP Podcast, we explained that traditional integration platforms that are billed as no code, when used for in-app marketplaces, do not give companies enough flexibility and customization, and can't meet business objectives without in-house coding.
We built Pandium so that engineers could code, and business users could accomplish their tasks without code. A customer support person on Pandium can use our Admin Dashboard without code, for example, to see any errors or logs for their company's integrations. And a marketer can create and update the integration tiles in their marketplace without code.
However, we did not make the integration configurations themselves no code. When integrations are turned into visualized blocks of code by a platform, a company loses the flexibility and control over the configurations and they also lose the ability to update the integration due to product or API changes.
In practice, this means companies end up having to code around integration platforms that are supposedly no code. Instead of taking this approach, we decided to productize the elements of the engineering work that did not require the flexibility and control that only coding can provide.
Pandium handles authentication, hosting, and the technical infrastructure for product integrations. It also provides a white labeled in-app marketplace. These are all elements that can be standardized and productized. But it leaves a space for our customers' engineers to write and update the specific integration configurations they need the moment they need to.
In the end, while Pandium requires engineering for the integration's configurations, this yes code approach requires less engineering resources, allows developers to write in the language they already code in (without learning an esoteric system), and gives companies ultimate flexibility and control over the configurations they offer their customers. Which, in turn, leads to happier customers.
If you want to hear more, check out the full discussion over at the Google Cloud Platform Podcast page