Pandium CEO and Co-Founder, Cristina Flaschen spoke with Ricardo Guntur, a Sr. Software engineer at Pandium, a tech ecosystem management and developer-friendly integration platform.
They discussed:
Read the transcript of the discussion below or watch the full recording below.
Cristina: So what are we covering today? First, we're going to define an integration and the difference between a native integration and a third party integration.
Then, we'll talk about integration strategy, build vs buy, what kind of tools you can use during the lifecycle of an integration. Afterwards, we’ll talk about getting started, and also getting ahead of any mistakes that commonly come around with this space.
%2520(1).jpeg)
Cristina: We have a lot of technology partnerships folks at SaaS companies registered for this, and also some people in product and business development. So you guys probably are looking to either retain more customers or sign more customers, and you understand that integrations and ecosystems are a great way to do that.
You also understand that the foundation of a technology partnership is going to be that integration. So that is why I think you should care about it. Rico, what do you think?
Rico: Well, if you're asking an engineer “why should you care about this webinar?” It's to get some tips on how you can write integrations efficiently and not take a year or six months. Also to get some tips on how to get started.
Rico: Well, first, what are integrations? Integrations simply connect either two or more systems together, moving data between them and probably transforming them in different ways. The SaaS product integrations I would say are designed to work with many products and services without you having to move data manually or having to toggle through multiple logins.
Cristina: I think it's really interesting to look at the transition of technology from this idea of being a monolith, trying to be perfect at everything and build all the things to now where solutions are really taking over.
That means that this interoperability is even more important. As you guys focus at your companies on what you guys do really, really well you can bring on partners to help fill some of the gaps.
Rico: Yeah, so this one's interesting. I had a little bit of a debate with my colleagues on what is Native? What we ended up agreeing on is that when there are two parties involved in an integration, and one of them owns the system or the API, that's what we consider native.
Related Content: The Pros and Cons of Offering Users Native vs Third-Party Integrations
This is because you have the ability to communicate with the members who develop that API, and you can request more personalized support.
Cristina: I’ll also say that having a native experience allows your customers to have either you or your partner supporting that integration. So, they don’t have to call a third-party company to try to get support.
Some additional benefits of having what we call native integrations, or integrations that you or your partners built, are around your ability to do tracking and see adoption metrics. If you send your customers to an external third-party, you may miss out on usage patterns.
So it's our feeling and opinion that the best partnership relationships and ecosystems are built with native interoperability versus something like Zapier, which does have its place for the long tail of integrations that you're not going to build in-house.
Rico: I’ve also seen occurrences where I’ve requested a partner to update their API to support a very custom business case and sometimes they pull through and it makes those unique use cases possible.
Cristina: 100%. Yeah, if the customer that wants this functionality has enough sway within an organization, or is a big enough customer, it's usually worth it to make those changes. If you are sending that person somewhere else, you kind of are losing the ability number one to even know that the request took place. Maybe you as an organization don't have a really close direct relationship with that dev shop or that other tool.
Cristina: So, there's three primary paths that you can go down, in our opinion, broad strokes, when it comes to your integration strategy. One is going to be you building integrations in-house. Do everything yourself.
In the middle road, there’s low-code software like workflow management tools or a unified API. Then we've got something that's more developer focused, what we call yes-code, a platform like Pandium and others that are more powered by actual code which can accelerate your delivery of native integrations that allow more customization.
Related Content: How to Track the ROI of SaaS Integrations
There's pros and cons to all of these things, but the way to think about it is based on the complexity of the integrations you're trying to build. How flexible do they have to be? What do they need to do? Is it something that's going to be beyond a simple if-then?
Then you want to think about the priority of the integrations you're looking to build and how it fits into your product roadmap. So if you are an integration platform as a product, you probably want to build all that stuff in house, but for most companies that's not going to be really core to the IP and the product that they're building, even though it may be really important for growth of that product.
Building in house has unlimited flexibility, you could do anything that your developers are able to do. But, that comes at a cost. It takes a really long time, and there's going to be maintenance involved. I think I can speak for myself in saying that I've worked at a lot of places that start down that road. Then, when they want to accelerate delivery, or really use the ecosystem play as a revenue lever, they don't really have all of the support internally to keep those things running.
A lot of engineers, Rico not included, don't want to work on the integration stuff. They want to work on your core product.
The low-code, workflow management tools will be something that looks kind of like Zapier or Tray.io. There's a lot of different ones that can accelerate integration delivery, if those integrations are relatively simple. So if you want a workflow that’s like “if this thing happens, then this other thing happens” those tools can be great.
There are use cases where these tools are definitely appropriate for, but there are going to be some limitations on the ability for you to have flexibility. Almost all of our customers and companies that we work with have a presence on Zapier, because Zapier is going to just have coverage that you're never going to have internally. So, I think it's a great option for those long-tail integrations.
Then if you want to kind of go down the middle road here, you can use a more modern integration platform where you get to have access to the flexibility that you would have if you built in-house, but it does not require you to do all of the infrastructure legwork of hosting all these things.
We'll talk a little bit later about some of the elements that go into this infrastructure, but this kind of tool is great when the integration infrastructure is not core to your business or product itself, and your business needs are slightly more complex than what a no-code platform could potentially offer.
Rico: I used to work for a SaaS company where I was sent out to do a Boomi course, which is an iPaaS tool. I remember that almost every ticket that came in was so custom that none of the workflows were working out for me. So, I ended up having to write code anyway for the custom business logic.
Cristina: That is a pattern that we see when the integration needs of a SaaS organization’s customers are relatively complex. So yeah, using code is a good way to handle a lot of those things.
So I think a lot of companies when they're starting down their integration journey, or even when they're kind of mid-range, these apps and integrations are really seen as a band aid. For example, you have a customer that's been really vocal about wanting an integration, and you just need to get something done.
Or, on the other hand your partnership team might be saying that they really want to bring on a partner, or they want to close a new deal, so we just need to get something up and running.
Integrations oftentimes are not treated like products, but your customers think about these native apps as products though, right? They're looking at these integrations as being something that, whether or not you actually built it, you as a company are recommending something, and they want you to support it.
So we say to treat these apps like you would treat any product. There's a lifecycle for that. So you have development, which is obviously building the app, which leads into design. Implementation is going to be actually onboarding your customers and training your team.
Customer support is super important. They are going to be the ones that are talking to your users, and hopefully, you have a really tight feedback loop there.
Then the most important one, in my opinion, is this modification. So, iterating your way to success. If you have the proper processes and tooling, you can get to a place where the integration is not just one and done, but you're able to then continue to build on the functionality to have something that suits the needs of your customers and the requirements of your partners over time.
We never want to be delaying launches because of edge cases. We'll talk in a minute about the importance of having beta customers and things like that. But, it's our philosophy that you should get your broad strokes, launch, see how people are going to use the app, and get that feedback as quickly as possible.
This is so that you can iterate your way to the solution that your customers want.
Rico: We always start with authentication first, because if you can't authenticate systems you can't do anything. In my experience, we find lots of really weird Auth. Even though we have OAuth 1 and OAuth2, they're not always implemented the right way.
We've seen p12 file uploading as well, those aren't that fun. But how do you get there? The second part of this is you want to think about hosting. Where are you going to host these syncs and runs? Is it going to be on GCP or AWS for example?
And then you want to think about logging and monitoring. Then, most importantly, alerting. For example, what happens if your run fails? What if some of these requests fail? Or if the system you're GETting from or POSTing from is down?
How do you get that information quickly so that you can act on it or report to your users and customers? Last thing here that's also important is the integration UI. If you're writing an integration, there's going to be more than just one user or partner running this integration.
Most of the time, they're going to be using it in different ways. For example, a configuration that you may have is an order sync, where you're syncing orders from an E-commerce platform to somewhere else, maybe you're a fulfillment center.
You also sync customers and tracking information. What if those are configurable? You can turn them on and turn them off. If your users can control them, that frees up time for your customer success managers from having to log into some dashboard and updating it themselves.
So in this case, a customer can log in, if there's a UI, and toggle those things. These can get pretty complicated. They could involve users mapping their own fields, maybe there's custom fields. But, all in all, what this allows is the power to have a more generic integration that is configurable from a front end.
That way an engineer doesn't always have to go in the code and have different kinds of releases for every single user. You can iterate on this far faster.
Cristina: To add, in the logging and monitoring, it's really awesome for an engineer to be able to see that something's wrong. But the next level is for the customer support team to be able to have a place to go when a customer calls.
An engineer like Rico can easily grab that information from a database, but a CS person has to make a ticket and has to wait for it to be prioritized. Three days later, when someone's looking at it, the issue is already resolved.
So thinking about the future of where you want this ecosystem to go, where you have thousands or hundreds of your customers using these things, you can start to design something that's a little more robust than just the data moving from one system to another.
Rico: Yeah, I agree. And, you bring up a great point. If you're building this in house, one of the solutions is to post these events to something like a Datadog and manage that there.
But then, somebody has to learn how to use Datadog, and has to learn how to post those events, and then set up those alerts in Datadog.
With a developer-friendly platform, you can either use that platform's logging solution, or you can still post to your own Datadog or API management, and have your own separate alerting too. So there's a lot of flexibility there.
Cristina: Absolutely. To go back to authentication, if you have access to an environment, before you try to start messing with the auth, see if the credentials work.
I’ve definitely worked at places where there's a whole lot of development that's happening, and then you find out when you go to test it that your credentials are broken, and you thought it was the auth the whole time.
So yeah, first things first, when you get those credentials, go to login, and see if they work. It'll save you a lot of headaches.
Rico: So, for my project managers and engineers that are writing integrations, I always recommend starting with architecting your project and not always diving to the code first. Even though it makes you feel like you might get it done faster.
Have a spec of your flows. For example, are you syncing orders, syncing tracking, or syncing tickets? It can be anything. Make sure you know and segment them differently. I recommend writing your integrations in a modular way. That way, when you do implement your configurations, you can easily toggle them on and off.
And for me, since I'm writing mostly in code, they're almost as simple as having if conditions. For example, “If the user has toggled your ‘sync orders’, run this.”
Have some user stories so that you know that what you're writing is actually the business solution that is needed. I've seen cases where teams will realize they implemented the wrong thing, and they realize they’ve used the wrong endpoint or the wrong mapping.
Read more about why you need integration user stories here.
I always start with having the mapping first. This is important so that you know which endpoints you're going to have to grab. That way you can investigate the API Docs to answer question like “Is it even possible to fetch inventory from products? I'm not sure yet because some of these e-commerce platforms keep those things in different locations, and they may not tie together properly.
Then the second part here is, as Christina mentioned, you should have some users ready to go for beta testing before you even start the integration, I would say.
Reach out to your partnership team, see if there's anyone willing to beta test this this new integration, this new product. When you're done, you're going to want to have someone test it because those are the people that ultimately will have some of the best feedback for you.
That way, you can make some slight smaller changes that better fit that business case.
Cristina: I actually find that a lot of customers, end customers, are really flattered to be a part of that process and to be able to give feedback and change and shape the way that these apps work.
The partnerships and business development folks on the call probably have a bench of customers in mind. But they get excited about being able to use something new.
And as Rico said, they're going to have all the weird data, and they're going to actually know how they want these two systems to work together. Additionally, to mention sandbox access, sometimes there are systems that as a partner, you're not actually able to get a really good developer sandbox environment.
Maybe you can get one, but it doesn't have any data in it, which makes it sort of useless or you can't get one at all.
When partnering with your beta customers, they may be able to provide you with their sandbox environment and then you can do some development work with them that way. Maybe for a discount of some sort on your licenses, or they might be willing to just offer it up.
Rico: Yeah, we always get feedback from beta customers. None of them are saying it's 100% perfect at first so we get great feedback and we iterate on the integrations before full releases.
Rico: With API constraints, you don't generally see this until you are running your integration in production where somebody, for example, has 300,000 products back from six months ago and you find that your integration can't keep up with either the API rate limits or even your platform's rate limits.
Which generally, I think even third-party integration platforms do have a runtime limit. And so, if you get ahead of this and try to look for the rate limits in the documentation, you can try to implement concurrency first instead of discovering it later and trying to implement concurrency over your existing code.
So my recommendation here is to plan ahead of time with certain constraints that you might see.
Rico: I recommend using Postman. In this day and age, I feel like almost everybody uses Postman. And it's not just for engineers. I think it's a great way for project managers to get access to the data models.
For example, what do the orders look like? What did the products look like? Like I say, the API Doc's aren't always the truth, but Postman is the truth. Get those objects, and map them based on the Postman returned requests.
Cristina: Yes, in this fast paced environment of software development these days, API Doc's are not always updated, and sometimes things come back looking a little bit different than what you expect.
Also, to Rico's point about the rate limits and the runtime limits, if you are able to do things like capacity testing, that is awesome. Especially if you can get sample datasets together in your own system, at really high volume.
This is so that prior to launch, you can actually run some of those tests, get ahead of it, see how the partner system performs under really high load.
It's not always necessarily the integration's fault, it could just be that there are inefficiencies in the APIs on either side, which can slow things down. So good to know what those limitations are going on so that you can either express those to the customers, talk to the partner, potentially have them put in a fix and design your app accordingly.
If you enjoyed this discussion, check out our Youtube channel and subscribe for more content on all things APIs, integrations, and technology partnerships. If you're someone who is working on building and scaling SaaS product partnerships, we invite you to apply to be a member of our community and network with other leaders like Cristina and Rico working on this at SaaSecosystemalliance.com.
