Topic: Legacy Systems

Discussion with Matt Durham, Head of Strategy at Digibee providing valuable insights into the critical aspects of integration – the complexities of pricing, leveraging the skills of your people, and choosing solutions that positively impact productivity.

In this episode of “Integration. Redesigned.,” our host, Chief Marketing Officer Cait Porte, sits down with Matt Durham, the Head of Strategy, to discuss the Three P’s of integration that organizations need to carefully consider as part of their integration strategy: price, people, and productivity. The conversation dissects common and confusing legacy pricing models that often lead to unexpected costs. It highlights the savings and simplicity that comes from choosing an integration solution that doesn’t require specialized developers, but rather empowers every developer to build, deploy, and manage integrations. The discussion also focuses on the significant advantages and impact cloud-native solutions have on productivity.

Full transcript

CAIT PORTE

Hello, and welcome back to Integration. Redesigned. I’m your host, CAIT PORTE. And in this episode, I am joined once again by Matt, Head of Market Strategy here at Digibee. Welcome, Matt.

MATT DURHAM

Thanks, Cait. 

CAIT PORTE

The more that we’ve talked to market leaders, customers, prospects, the more that we’re learning about the importance of the three P’s, I’ll call them, of integration. Price, people, and productivity. And as a reminder and disclaimer, all data that we’ll reference today comes from publicly available sources, like a company website or analyst research. And the white paper that we’ll reference and discuss today includes all references to any information discussed here. We’re obviously, as I said, not going to talk about the three P’s of marketing, product, price, and promotion as much as I would love to, but the three P’s of integration, if we can even maybe coin that term.

Matt, you recently wrote a white paper on the topic, and I’m very much looking forward to dissecting that today. There’s a ton of really good data in that white paper, and while we won’t have time to get to it today, definitely check out the link below to download the white paper or give the link in the bio and summary of this episode a click.

Let’s start off with pricing. Historically, enterprise software vendors, they’ve made their pricing deceptively challenging to understand, starts off really simple, easy to digest, easy to understand, and then suddenly turns into a guessing game or a chess match. And ultimately, I have, as a buyer, and our buyers have felt really confused with the whole process. I’m sure that you’ll get to this, but also hit with unexpected costs during that implementation phase. That’s a big one. “Oh yeah, you can have this, but it’ll cost you X.” 

Matt, I’d love to hear your view on where your research led you around pricing and what guidance or advice you might give to software buyers.

MATT DURHAM

Sure, Cait, thanks a lot for the introduction and the opportunity to be here. And I think it’s an interesting question because actually on one level, traditional software licensing seems sort of simple, right? You pay a perpetual license, and then maybe you pay, probably you pay annual maintenance on top of that. And that seems simple, “X for the perpetual license” and “Y for the software maintenance.” But the reality is, in order to get to that perpetual license cost, there’s a lot of complexity. And I think that’s worth really teasing out because the reality is that a lot of iPaaS vendors are still pricing based on that, what I would describe as a legacy pricing model. 

So, the most fundamental part of that is always capacity. So, the way that perpetual licenses have long been priced is based on the most utilization that a server will need to execute the job, or the jobs, that that software is doing. And when virtualization came into the market 15 years or so ago, that complicated things for software vendors. And so now what we see in that, it was harder for software vendors to earn as much revenue based on that because it virtualized the environment. There are a lot of vendors still that are active in the iPaaS market that are still pricing based on virtual cores. So, what that means is the prospective buyer has to size their utilization and typically at the maximum amount that they will ever need.

The classic example of that is you’re a retailer, let’s say a very large e-commerce vendor, that has a spike in sales on Black Friday or on special sales events. And that’s when you’re gonna have the most utilization, you have to price to that amount. Even if 99% of the time during the year, you’re only executing at 10% of that, or whatever the figure is. So, that’s already complicated, but let’s accept that at the end of the day, that’s just still it’s one number, vCore, right? Okay, well then on top of that, many of our competitors require their customers to choose the type of edition that they get. Do they want the “A, B or C” edition or the “silver, gold, platinum” or the “Chevy or a Lexus” edition or whatever, however they choose to split the sort of good, better, best, right? 

That’s another choice that has to be made. And those additions come with certain capabilities and of course they vary by vendor. Then on top of that, there are decisions that have to be made about even additional capabilities. So, for multi-product companies, as opposed to a platform vendor like us, you might need to pay more to get that second, third or fourth product. That’s not actually, it’s really not a platform, it’s a bunch of products and on and on and on and on. And so this becomes, and then, sorry, one more thing, and we’ll talk about this a little bit more, I think, is I already mentioned maintenance, which is another cost that has to be incurred. Then there are costs not associated with the software itself. So the implementation fees, right? So, how do you hire either a consulting firm or services people from the software vendor to implement the solution? There’s a lot of costs associated with that. So, there’s costs, on top of costs, on top of costs, on top of costs.

And it is a challenge and it’s not, I would say, the most transparent or customer-forward way to approach licensing. So, the big advice I would suggest for software buyers, whether they’re the actual, the buyer who’s actually going to be using the technology, or whether they’re part of a vendor management organization typically in large companies that have those, is really to push for simplicity. 

And of course, ultimately, the beauty that any SaaS vendor offers, including Digibee, should be, and is in our case, very simple pricing. This is the price, you pay it, this is how we get to it. And it covers all of those considerations.

CAIT PORTE

It’s a really nice summary. And there were a couple of nuggets in there. I want to pull on one around capacity or utilization. It’s a tricky one to answer. I think that one of the things we want to recommend is understanding your capacity or potential future capacity before negotiating on a price. Can you expand on that a little bit?

MATT DURHAM

Yeah, and actually, before I answer your direct question, I want to actually even answer another part of it, which is that, again, remember in traditional license models, the capacity is owned by the buyer. I’m buying the hardware that that software is going to run on. I’m buying the databases, the operating systems. And yet, the software vendor is still charging based on capacity. Basically, how many versions of this am I buying, right? Now, maybe that’s reasonable. Wait, maybe that’s unreasonable. For a long time, I’ve said that the beauty of that model is that the incremental price of the second piece of software to the provider is zero. So it’s all margin for vendors, right? So I understand that model, and I worked in that model for a long time.

In a SaaS model, and we’re looking at path capacity, and you’re absolutely right, we want to understand that before we even get into pricing discussions, because it’s a big deal, right? We, as a SaaS vendor, are paying for the utilization of the hardware and the supporting software to run our iPaaS. We’re paying a hyperscaler for that utilization. We’re not running our own data center. And so we have costs that we have to pass on to our customers. And of course, we have a little bit of margin on top of those costs, as any company would.

But those costs for us are fixed. So, the more capacity we use on behalf of our customers, the more we have to pay. And so it’s important for us as a vendor that we understand that capacity, and clearly also then important for the consuming organization as well. And that’s, I think, also another really nice thing about the SaaS model is that it really does foster a more collaborative approach to that reality, right? So, in the former approach, the costs are all on the consuming organization. But in the SaaS model, the costs really are shared. And so no organization wants to incur any more costs than they need to. And I think, as such, most SaaS vendors do everything that they can to keep those, let’s call them those operating costs of managing the hardware, or I should say, the hyperscaling environment that we get. Because the more of those costs we incur, as I said earlier, the more costs we have to pass on, and we don’t necessarily want to do that. So I think that’s fundamentally what’s different about the models.

CAIT PORTE

I think we could talk about pricing for probably an entire episode. But I think there’s some really good information there, particularly about the difference between traditional pricing model or legacy, and these SaaS models where it’s a little bit more shared. And most companies are transparent about that, including ourselves.

Let’s talk about resourcing. Really important thing to think about when buying a new piece of software, something that we go through all the time on the revenue side of the business, “who’s going to use this”, “how they’re going to use it,” “who do we have to staff it?” Legacy vendors have required historically specialized developers or resources, not only to ensure that the buyer’s on board the tool successfully, but so that they can continue to use these tools effectively.

What’s the main difference between a legacy vendor versus Digibee when it comes to the time and cost commitment around resourcing? 

MATT DURHAM

Right. Yeah, I think everything you said, of course, is right there. And I would point out that, again, it was a core model of the legacy pricing approach, or I should say the perpetual licensing approach. Most enterprise software vendors had a model where they would charge roughly 20% of the perpetual license for annual maintenance. And then, depending on the part of the software market that those vendors were in, there was an assumption of how much of the, again, the perpetual license costs would also be charged in services for implementation, often by the vendor itself, sometimes by system integrators. And that, again, that percentage would vary a little bit by the market, by the specific, or sub-market, I should say.

And again, the beauty of the SaaS model is we remove perpetual license and maintenance. Those are combined into a single subscription fee. But straight to your point about what’s different about Digibee compared to many of our competitors, and certainly the legacy pricing model, is we take a very different approach to how we target our users or who we think our users should be. And very simply, we think our users should be every or any software developer who could contribute to writing integrations. And that’s distinctly different from requiring specialized integration developers who obtain and maintain certifications on the variety of legacy vendors that we compete with.

Those certifications have costs associated with them. They drive, actually, the costs of the developers themselves up, because it creates some uniqueness in them, right? They have a specialty. And so, the average cost for a specialized integration developer is higher than it is for the average cost of a developer. And so at Digibee, our core operating principle is that every developer can use our technology to build, deploy, and manage integrations. That’s a fundamentally different approach. And in fact, Cait, we don’t, as a standard practice, we don’t even offer certifications on Digibee. So if, Cait, you wanted to become a Digibee-certified developer, you really wouldn’t be able to do that because it’s our idea that that’s a capability that you, Cait, as a developer, should be able to have without any specialized training from us. And I don’t want to overstate that. Of course, you have to learn how to use our platform. And we offer training that’s really great. That’s also, by the way, part of the cost that we share with our customers. But, it’s a relatively short cycle to do that. And it doesn’t require, again, those ongoing commitments to certification just on us.

CAIT PORTE

I’ve been looking at CRMs and different CMSs. One piece of advice that we’ve gotten from advisors is choose something that doesn’t require you to have a specialized resource to utilize because it’ll hold you back. And, that advice extends to sales and marketing software, to integration software, like we’re talking about. Anything, you don’t, as a business user or owner or buyer, want to be held back by that specialization. So, I think it’s a really good point to highlight that it exists in this space as well.

MATT DURHAM

Yep, absolutely. 

CAIT PORTE

Not surprisingly, let’s go to our final topic, but we’re all trying to do more with less, which is quite a challenge. We talk about the benefits of cloud-native architecture here at Digibee. In terms of productivity, cloud-native architecture has proven to be differentiating and impactful for our customers.

In the white paper, you talk about end of life, upgrade paths, and how painful it can be to move for a team trying to move quickly because it’s a required step. Why does it matter about the architecture of a platform versus the way that Digibee is?

MATT DURHAM

Let me say one, a couple of quick words about cloud-native. So, cloud-native is a very loaded term that there are literally competing definitions in the market for cloud-native. So, we are cloud-native. We’re very confident in that based on the commonly-accepted definition. We’re also born in the cloud, and that’s a distinction. So what I mean by that is our founders, when they founded the company, they began developing the solution based on hyperscale technology, as opposed to based on a server that was sitting in their office or whatever, and then later deployed to a cloud environment. And, that’s kind of the reality of many of our legacy competitors. They were developed in a client-server world, and they’ve been refactored to run in the cloud. And, that creates some technical limitations for some of their scenarios.

You talked about end of life also, and I think it’s really important to talk about that. End of life, probably a better term is end of support. End of life, and I say that because end of support is kind of the technical term, and there are probably no organizations in the world that are going to run software that’s unsupported, particularly integrations. Let me say that again, that run integration software that’s unsupported because it’s so critical, right? And so your organization might run unsupported software for something that’s not mission-critical. Although unlikely, but you’re certainly not going to run it for integration. So end of life, end of support, let’s, we can use those sort of interchangeably.

At Digibee, and for any SaaS vendor, there is no end of life. There is no end of support, right? Because there’s no versioning per se. The version that you’re on, is the current version, and the version that you’ll be on tomorrow, is the current version. And whether a vendor practices the continuous delivery, model of software updates, or whether they ship updates on a scheduled basis, monthly, quarterly, whatever, the fact is that all of their customers are always on the same version. And, always on the current version. And there’s real value in that.

We’ve talked about this before with the challenges of upgrading on-premises integration technologies and how really, really painful that is. So, there are clear benefits in leveraging technologies that fully take advantage of the benefits that we get from working with hyperscalers. And there’s simply the benefit of never having to upgrade your software, right? So there are the really cool technical benefits in terms of vertical scaling and horizontal scaling and immutability and, and, and, and, and… boy, just not having to upgrade. That, in and of itself, is super, super powerful.

CAIT PORTE

I can barely remember to click the button on my Chrome browser to upgrade it. I’ve got that little red notification, you know, five days out of seven. I can’t imagine what it would be like to have to upgrade legacy technology with a team that is already saddled with a heavy backlog.

MATT DURHAM

It’s tough work. It’s tough work for sure.

CAIT PORTE

Well, Matt, once again, thanks for joining.

For those listening, please take a look at the link in the episode or visit digibee.com to download your copy of the white paper on Price, People, and Productivity, comparing Digibee to a legacy vendor. That’s it for this episode of “Integration. Redesigned.”