You've all seen the blog posts: "You can connect Salesforce to Slack in just 15 minutes!"
Almost every iPaaS vendor has a post with a similar catchy title – even embedded iPaaS platforms designed specifically to help software companies provide in-app integrations. Don't get me wrong – I have no doubt that you can connect one common SaaS app to another in just 15 minutes using any iPaaS – it'd be a pretty crummy platform if you couldn't.
But if you're a B2B software company needing to provide integrations between your app and the other apps your customers use, now what?
Can you move data in and out of your own app? Can you connect to the niche apps in your industry, and handle their atypical API implementations? Can you readily monitor the health of your customers' integrations, and debug problems as they arise? Can your own customers deploy integrations for themselves?
For B2B software companies, those X to Y in N minutes blog posts just don't represent the real world. In the real world, you're rarely connecting two common SaaS apps. And while the blog posts end once the integration has been built, in the real world, that's just the beginning. Real-world integrations need to be configured and deployed to numerous customers who are on different versions of your software, maintained and supported for years, and presented as a first-class part of your product experience.
Today I want to talk about integrations that B2B software companies need to build. Real ones. I'll cover how Prismatic goes beyond the simple blog post scenarios and handles the hard stuff: giving you the flexibility to handle whatever unique problems your industry throws at you, the power to handle configuration differences between customers, and out-of-the-box tooling for the things you shouldn't have to build yourself (stuff like authentication, logging, monitoring and alerting).
We equip your team with the tools you need to build actual integrations.
Don't get cornered by unrealistic no-code/low-code systems
Here's the first way the real world is different from those blog posts: You're not usually connecting Salesforce to Slack, or anything near that straightforward.
Your customers use a wide range of software, much of it specific to their industry, and that means that you need to integrate with systems that most people don't even know exist. I've worked with companies that produced some run-of-the-mill CRM integrations, but also had some pretty wild integrations to things like garage door openers and security systems.
The last thing you want is to be restricted by the limitations of your iPaaS vendor, and left unable to connect to an obscure API.
A platform that solves 90% of your integration problem is 100% useless if it can't solve the last 10%.
Some of your integrations will be to common SaaS providers like AWS, Quickbooks or SendGrid, and we have many built-in components that connect to these common services. In the real world, though, many integrations require you to connect your app to bespoke, industry-specific apps and services that no iPaaS vendor has a built-in connector for. You need some mechanism to connect to those systems.
To address this need, some iPaaS platforms offer a generic HTTP component that lets you connect to HTTP-based third-party apps. While a generic HTTP component solves some problems, it often falls short when you're dealing with atypical API implementations. I've seen some pretty silly third-party APIs that glued on external access as an afterthought, and due to their idiosyncrasies it'd be impossible to connect to them with a vanilla HTTP component. Many APIs don't follow normal, industry-standard authentication patterns, and some just plain don't use HTTP. I've worked with some that layer gRPC on top of HTTP, and the garage door opener integration I mentioned used a completely different protocol (XMPP in that case).
At Prismatic, we take a "realistic low-code" approach. We recognize that as a software company, you have a dev team you can involve in integrations when needed, and we make sure they have the tooling necessary to extend the platform so you can handle all types of integrations with ease. In Prismatic, your devs can leverage our custom component library to implement the unique logic needed to connect to third-party systems. Custom components are as extensible as NodeJS (so, pretty darn extensible), so handling atypical APIs can be a simple an npm install @grpc/grpc-js or npm install @xmpp/client. Plus, you can tackle any other problem NodeJS has a solution for in a custom component – generate a PDF, convert an audio file with a proprietary codec, leverage ArcGIS for mapping... you name it, and your devs can implement a solution within a custom component.
The code behind your custom components can live alongside the rest of your code base in whatever source control system your devs already use, and your devs can write unit tests and compile and test your components locally, like they would with any other NodeJS project. With custom components, you are never left cornered – you can take on whatever complex problems your customers' integration needs throw at you.
Handle customer-specific configuration and versioning
Here's the next way the real world is different from those blog posts: The blog posts usually ignore the fact that integrations aren't a "one size fits all" affair.
Your customers have unique needs, so your integrations need to be configurable to account for customers' differences.
Prismatic was built on the premise that integrations should be built once and deployed often. Developers familiar with building integrations for their app know how important it is to be configuration-driven – the same code should be able to behave differently depending on how it is configured. Configuration differences between customers might be simple – for example two customers might have different credentials to a third-party API, or different endpoints to fetch data from – or the differences might be complex. Customers might want their data mapped in unique ways as it moves from an outside service into your app, or they might want recurring reports to be generated using unique, customer-specific templates.
You can build configuration-driven integrations in Prismatic using config variables. Config variables should feel familiar to your dev team (who use things like environment variables on a daily basis), and they're a powerful tool that let your customers simply choose a few configuration options and hit an "enable" button to deploy an integration for themselves.
Developers love configuration-driven deployments (especially if they can hand deployment tasks off to other people in the organization). Once the configuration experience has been set up by an integration builder, your devs can leave configuration and deployment to your customer-facing teams or to your customers themselves – a non-developer can flip a few toggles, select some options from some drop-downs, enter some credentials, and deploy their integration without devs holding their hands.
Additionally, Prismatic integrations are versioned and you can deploy specific versions to each of your customers as needed. Some embedded iPaaS platforms don't account for versioning, and once you hit "save" every single one of your customers receives updated integration code. That's definitely not what you want – especially if your customers are using different versions of your app.
The tooling your devs shouldn't build
There's one more huge thing those blog posts overlook: Building an integration is only part of the overall integration challenge. There's also a host of "boilerplate" things needed to support every integration – things you shouldn't have to build.
Writing a script that connects Thing X to Thing Y is easy (for some value of "easy"). Making sure the script stays running, and debugging it when it stops running, is harder. I've worked with several companies whose "monitoring" solution is receiving a customer support ticket that an integration is down.
It's critical that your team is alerted when integrations fail, and that your support and dev teams can quickly diagnose what happened (and when). When something goes wrong, you should be able to assess within minutes if the problem lies with your system or in the third party with whom you're integrating.
Being able to diagnose problems is important, but it shouldn't be your devs' job to build logging, monitoring and alerting systems. Having your dev team reinvent solutions to those problems doesn't add value to your product keeps them from focusing on core product development.
Prismatic comes with logging, monitoring and alerting baked in. Your team can configure who gets notified and under what conditions. You can configure texts or email alerts, or you can send notifications via webhook to systems that devs like to use (like Slack or PagerDuty).
Prismatic has an internal logging system, and you can also configure the platform to stream logs to logging and metric services that your devs already know and love, like New Relic or DataDog, so you can have all of your logs (from your app and from your integrations) in one place.
Leaning on Prismatic's built-in tooling takes a (rather sizable) chunk of work off of your devs so they can stay focused on the core problems your company is solving.
Finally, Prismatic provides an integration marketplace that you can embed in your app, so your devs don't have to build one. You likely want your customers to be able to enable integrations for themselves. With just a few lines of code and a familiar-feeling NPM package, your dev team can embed a native integration marketplace within your app. Upkeep of an embedded integration marketplace is pretty minimal (it's an iframe that you inject into your app), and it's another piece of the integration ecosystem that your devs simply don't need to spend time worrying about.
Let's chat!
As a B2B software company, you need an embedded iPaaS that gives you the flexibility to handle real integrations. And you need a system that gives you the tools to solve the whole integration problem – not just building integrations but also configuring and deploying them to customers, supporting them in production, and making them a first-class part of your product experience.
We'd love to talk about how Prismatic can support the integrations that you need to build, no matter how real-world and messy they may be. Please reach out – we'd love to chat!
You've all seen the blog posts: "You can connect Salesforce to Slack in just 15 minutes!"
Almost every iPaaS vendor has a post with a similar catchy title – even embedded iPaaS platforms designed specifically to help software companies provide in-app integrations. Don't get me wrong – I have no doubt that you can connect one common SaaS app to another in just 15 minutes using any iPaaS – it'd be a pretty crummy platform if you couldn't.
But if you're a B2B software company needing to provide integrations between your app and the other apps your customers use, now what?
Can you move data in and out of your own app? Can you connect to the niche apps in your industry, and handle their atypical API implementations? Can you readily monitor the health of your customers' integrations, and debug problems as they arise? Can your own customers deploy integrations for themselves?
For B2B software companies, those X to Y in N minutes blog posts just don't represent the real world. In the real world, you're rarely connecting two common SaaS apps. And while the blog posts end once the integration has been built, in the real world, that's just the beginning. Real-world integrations need to be configured and deployed to numerous customers who are on different versions of your software, maintained and supported for years, and presented as a first-class part of your product experience.
Today I want to talk about integrations that B2B software companies need to build. Real ones. I'll cover how Prismatic goes beyond the simple blog post scenarios and handles the hard stuff: giving you the flexibility to handle whatever unique problems your industry throws at you, the power to handle configuration differences between customers, and out-of-the-box tooling for the things you shouldn't have to build yourself (stuff like authentication, logging, monitoring and alerting).
We equip your team with the tools you need to build actual integrations.
Don't get cornered by unrealistic no-code/low-code systems
Here's the first way the real world is different from those blog posts: You're not usually connecting Salesforce to Slack, or anything near that straightforward.
Your customers use a wide range of software, much of it specific to their industry, and that means that you need to integrate with systems that most people don't even know exist. I've worked with companies that produced some run-of-the-mill CRM integrations, but also had some pretty wild integrations to things like garage door openers and security systems.
The last thing you want is to be restricted by the limitations of your iPaaS vendor, and left unable to connect to an obscure API.
A platform that solves 90% of your integration problem is 100% useless if it can't solve the last 10%.
Some of your integrations will be to common SaaS providers like AWS, Quickbooks or SendGrid, and we have many built-in components that connect to these common services. In the real world, though, many integrations require you to connect your app to bespoke, industry-specific apps and services that no iPaaS vendor has a built-in connector for. You need some mechanism to connect to those systems.
To address this need, some iPaaS platforms offer a generic HTTP component that lets you connect to HTTP-based third-party apps. While a generic HTTP component solves some problems, it often falls short when you're dealing with atypical API implementations. I've seen some pretty silly third-party APIs that glued on external access as an afterthought, and due to their idiosyncrasies it'd be impossible to connect to them with a vanilla HTTP component. Many APIs don't follow normal, industry-standard authentication patterns, and some just plain don't use HTTP. I've worked with some that layer gRPC on top of HTTP, and the garage door opener integration I mentioned used a completely different protocol (XMPP in that case).
At Prismatic, we take a "realistic low-code" approach. We recognize that as a software company, you have a dev team you can involve in integrations when needed, and we make sure they have the tooling necessary to extend the platform so you can handle all types of integrations with ease. In Prismatic, your devs can leverage our custom component library to implement the unique logic needed to connect to third-party systems. Custom components are as extensible as NodeJS (so, pretty darn extensible), so handling atypical APIs can be a simple an npm install @grpc/grpc-js or npm install @xmpp/client. Plus, you can tackle any other problem NodeJS has a solution for in a custom component – generate a PDF, convert an audio file with a proprietary codec, leverage ArcGIS for mapping... you name it, and your devs can implement a solution within a custom component.
The code behind your custom components can live alongside the rest of your code base in whatever source control system your devs already use, and your devs can write unit tests and compile and test your components locally, like they would with any other NodeJS project. With custom components, you are never left cornered – you can take on whatever complex problems your customers' integration needs throw at you.
Handle customer-specific configuration and versioning
Here's the next way the real world is different from those blog posts: The blog posts usually ignore the fact that integrations aren't a "one size fits all" affair.
Your customers have unique needs, so your integrations need to be configurable to account for customers' differences.
Prismatic was built on the premise that integrations should be built once and deployed often. Developers familiar with building integrations for their app know how important it is to be configuration-driven – the same code should be able to behave differently depending on how it is configured. Configuration differences between customers might be simple – for example two customers might have different credentials to a third-party API, or different endpoints to fetch data from – or the differences might be complex. Customers might want their data mapped in unique ways as it moves from an outside service into your app, or they might want recurring reports to be generated using unique, customer-specific templates.
You can build configuration-driven integrations in Prismatic using config variables. Config variables should feel familiar to your dev team (who use things like environment variables on a daily basis), and they're a powerful tool that let your customers simply choose a few configuration options and hit an "enable" button to deploy an integration for themselves.
Developers love configuration-driven deployments (especially if they can hand deployment tasks off to other people in the organization). Once the configuration experience has been set up by an integration builder, your devs can leave configuration and deployment to your customer-facing teams or to your customers themselves – a non-developer can flip a few toggles, select some options from some drop-downs, enter some credentials, and deploy their integration without devs holding their hands.
Additionally, Prismatic integrations are versioned and you can deploy specific versions to each of your customers as needed. Some embedded iPaaS platforms don't account for versioning, and once you hit "save" every single one of your customers receives updated integration code. That's definitely not what you want – especially if your customers are using different versions of your app.
The tooling your devs shouldn't build
There's one more huge thing those blog posts overlook: Building an integration is only part of the overall integration challenge. There's also a host of "boilerplate" things needed to support every integration – things you shouldn't have to build.
Writing a script that connects Thing X to Thing Y is easy (for some value of "easy"). Making sure the script stays running, and debugging it when it stops running, is harder. I've worked with several companies whose "monitoring" solution is receiving a customer support ticket that an integration is down.
It's critical that your team is alerted when integrations fail, and that your support and dev teams can quickly diagnose what happened (and when). When something goes wrong, you should be able to assess within minutes if the problem lies with your system or in the third party with whom you're integrating.
Being able to diagnose problems is important, but it shouldn't be your devs' job to build logging, monitoring and alerting systems. Having your dev team reinvent solutions to those problems doesn't add value to your product keeps them from focusing on core product development.
Prismatic comes with logging, monitoring and alerting baked in. Your team can configure who gets notified and under what conditions. You can configure texts or email alerts, or you can send notifications via webhook to systems that devs like to use (like Slack or PagerDuty).
Prismatic has an internal logging system, and you can also configure the platform to stream logs to logging and metric services that your devs already know and love, like New Relic or DataDog, so you can have all of your logs (from your app and from your integrations) in one place.
Leaning on Prismatic's built-in tooling takes a (rather sizable) chunk of work off of your devs so they can stay focused on the core problems your company is solving.
Finally, Prismatic provides an integration marketplace that you can embed in your app, so your devs don't have to build one. You likely want your customers to be able to enable integrations for themselves. With just a few lines of code and a familiar-feeling NPM package, your dev team can embed a native integration marketplace within your app. Upkeep of an embedded integration marketplace is pretty minimal (it's an iframe that you inject into your app), and it's another piece of the integration ecosystem that your devs simply don't need to spend time worrying about.
Let's chat!
As a B2B software company, you need an embedded iPaaS that gives you the flexibility to handle real integrations. And you need a system that gives you the tools to solve the whole integration problem – not just building integrations but also configuring and deploying them to customers, supporting them in production, and making them a first-class part of your product experience.
We'd love to talk about how Prismatic can support the integrations that you need to build, no matter how real-world and messy they may be. Please reach out – we'd love to chat!
