Learn how Johnson Brothers successfully tackled their integration challenges using Digibee’s cutting-edge technology.
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.
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.
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.
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.
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?
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.
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?
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.
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.
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?
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.
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.
It’s tough work. It’s tough work for sure.
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.”
A must-read for IT leaders: Gartner discusses how to efficiently align your integration needs and breaks down the pros and cons of common pricing models.
Concerned about the upcoming MuleSoft end of life? Digibee details 3 key differentiators to support your digital transformation efforts.
Discussion with Head of Strategy Matt Durham on leveraging Digibee to overcome the three key limitations MuleSoft users face.
With host Cait Porte, Chief Marketing Officer at Digibee
In this episode of “Integration. Redesigned.,” our host, Digibee’s Chief Marketing Officer Cait Porte, is joined by Head of Strategy, Matt Durham, for a discussion on the crucial task many organizations face in selecting the right integration platform solution. Matt provides valuable insights for making an informed decision. The conversation explores key considerations, including defining your company goals, leveraging research from trusted resources, understanding your integration tool users, and aligning your technology resources with your organization’s broader needs for now and the future.
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 Strategy here at Digibee. Welcome back, Matt.
Today, we’re going to talk about how to select an integration tool that fits your business. IT professionals, similar to marketing professionals like me, are always being sold new and innovative technologies with the promise that it’s going to make your team more efficient, get things out more quickly, be lower cost.
Today, Matt, we really want to figure out how are we going to select an integration platform for your business. And it’s a loaded one, right? We’ve got certainly a number of things that we can unpack related to this. But how might you start out answering that question? How do you select an integration platform?
Right. Well, as you and I talked about, Cait, recently, it’s a big question, and as you just said. And, there are companies like Gartner and Forrester that, to a greater or lesser degree, base their entire business on this question, right? But we’ll try to address this in the few minutes that we have.
So, this may seem self-evident, but I’m going to suggest that it doesn’t always happen, which is why I want to mention it, of course. And so the first thing is, I think, the buyer needs to understand her goals or the buying organization needs to understand its goals. So, again, that may seem really self-evident, but I’ve certainly seen enough RFIs and been involved in enough sale cycles and opportunities where I don’t think the goal was really clear, or the goals (plural), were really clear.
So we’ve had some success at Digibee in helping customers who have required integration technology because they made another purchase that was very strategic for them. And, so I’m thinking specifically about a new e-commerce suite that several of our customers have purchased in the retail protocol. And that was a very strategic, very important action for them. And then sort of on the heels of that, they needed to purchase new integration technology to accomplish all the downstream things that they wanted to, and needed to, with that e-commerce suite.
So, I mentioned that because we, as working for vendors, and working as part of a marketing organization, of course, we want buyers to pay attention to our outreach. But ultimately, the outreach needs to be met with a need. So, what are some big examples? Well, there probably is some sort of a digital transformation initiative happening somewhere in the organization. Perhaps there is a decision to retire some legacy systems and to purchase, as I was just describing, in an e-commerce example, a new modern kind of core piece of software for the company. Maybe there’s an acquisition that’s happened and there’s a requirement to integrate systems. Whatever, it’s not just understanding what the high-level strategy is that’s critical. But, then it’s also really important to understand how that strategy is going to be achieved.
So, I think that’s fundamentally the first thing, is a clear understanding of why these conversations are even happening. And I think it’s incumbent on any seller to discover those things. So, no one should buy anything other than maybe a postcard when they’re traveling, just because, just because, right? So that’s the first thing.
I think the second thing I would say is, (did you want to ask me something else or?) OK, so – and I’m going to qualify this a little bit because of Digibee’s example – but, you know, as you know, Cait, I’ve worked with Gartner and Forrester and IDC and those sorts of companies for decades. And, I think that they’re a very good resource for this sort of question. So, what should I do if I’m going to buy some enterprise software? Well, I’m probably going to talk to Gartner and Forrester and the other firms because they know a lot about them. They know a lot about these things. They publish research reports about them. They talk to the vendors. They talk to the customers of the vendors. They talk to the competitors of the vendors. And it’s not to say that that anyone should necessarily say, should ask Gartner, “should I buy X or Y?” And Gartner “says Y.” And then you go buy Y. That’s not the point necessarily. But it’s another important and valuable source of data.
There’s a caution with that, though, I want to say, I want to mention. Again, it’s been my experience that it’s very common for organizations to build shortlists based on the vendors that are leaders in a magic quadrant or sometimes leaders in a Forrester wave. And, I don’t think that’s a great practice. And I would say very confidently that Gartner and Forrester would agree that that’s not a great practice.
So, first of all, you’re missing out on companies like Digibee that aren’t included in the magic quadrants, in the waves, in our case, because we don’t yet have enough revenue to be included. So, they all have requirements for inclusion. And, you know, we’re a high growth company and we’re approaching that bar and we’ll be at it in the future, but we’re not at it yet. So, it’s a good source of data, or they are a good source of data, but they’re not the only source. So, those are a couple of the things I would start out with. There I have some other thoughts, but I don’t know if you had anything you wanted to ask about – as relates to those.
I think it’s really important to highlight that while you, I mean, I equate this to going out to a mentor for advice or guidance. Sometimes the mentor may know about things that you are not necessarily aware of, in having that conversation. You know, just think again, job searching, if we want to equate the same thing. Right? I go out. I talk to a mentor. They bring me a suggestion on a company, an individual, a source of information that I may not have been aware of. So I think, you know, spot on. Right? The first thing we want to do is understand our goals and needs.
And, the second is back that up, get a mentor to help you out. And don’t be afraid to look at some of the ones that may not appear in your traditional sources for information gathering. Because I think you’re going to find, you know, especially given our relationship with Gartner, that they may know about a lot more than what meets the eye. Right? There’s more to the why there.
The next thing that we had talked about was who’s going to use this? And this is really near and dear to our hearts here at Digibee because we think about that as part of our strategy. But, when you’re thinking about, well, who’s using this and what are they doing with it? How does that – how does that resonate with you? And what might you add there?
Yeah, it’s really an important point. And I’m glad you brought it up because classically integration platforms have been used by a highly skilled team, a highly specialized team, a dedicated team, typically. “My job is to write integrations. That’s what I do, to write and maintain integrations.” And our thesis at Digibee is that that’s no longer a sufficient model. So, I would argue in terms of selection to understand whether a technology vendor can serve the requirements of your broader development organization. And maybe another way to say it is, can the platform that you are considering for purchase, can it be used by a wide range of developers in your organization? As opposed to the two or six people who are deeply trained on integration technology and integration technology only?
The reason that’s important is, if you pursue a strategy where integrations are written as part of your sort of standard work, as opposed to by this highly specialized team, you will be able to burn down your backlog. You’ll be able to have a more efficient development organization and a more agile development organization that can adjust to needs. As opposed to – what is classically a scenario – which is relying on a small team where things tend to bottleneck very, very quickly.
And, one of the super cool things about Digibee and one of the things that we were really proud of here is that we can get developers really proficient on our platform in a matter of days. Whereas with traditional integration platforms, training and certification can take weeks, months, or sometimes even longer. We actually don’t even offer certification because we don’t think it should be used. We don’t think it’s required in our case. So, I think that that’s a really important thing to look for.
And one more thing I want to say about it, Cait, before I pause is if you have, if you, Cait, are the buyer and you have that team of dedicated integration developers, that doesn’t mean you should exclude a modern platform like Digibee because, of course, those people, those integration specialists will be able to use our platform. And frankly, they’ll probably be able to use it really, really well because they understand integration as a sort of as a topology, if you will.
We say this a lot here, select a tool that’s going to work for you, not the other way around. And, I think this conversation really highlights that because when you look at the average tenure of the people on your team, you know, people aren’t staying at companies 20, 30 years anymore. They’re staying at companies, single digits, right? Two to four to maybe six years, even saying six years is a long time these days. And, as you think about that growth, you need technologies that are going to help empower the teams that you’re bringing on if you’re expanding and growing and you want them to use the technologies that you have in place. Or as knowledge departs the organization, you have the ability to educate internally without rushing to get a deadline before someone leaves. So that’s a huge one is, who’s going to use this? How are they going to take advantage of it? And, are we going to have the flexibility once that person is potentially no longer here?
Well, Matt, once again, you know, selecting a tool is challenging, to say the least. I’m constantly looking up articles on “X tool versus Y tool” or “why would I select X?” What are the best benefits? What are the “gotchas?” I’m sure that bloggers make tons of money off of writing these types of content.
I think if we were to boil down today, it’s, you know, what are your goals and needs and how are you going to use it? What mentors or research tools can you go to to get that advice? And then ultimately, well, who’s going to be using it and how does that scale with my business going forward?
Thanks for joining me, Matt. I’m sure we’ll see you again. That’s it for this episode of Integration. Redesigned.
Através da Digibee Academy e documentações da Digibee, a Craft desenvolveu seus próprios pipelines e tornou-se autossuficiente.
Mesmo após mudança de core bancário, Digibee ajuda a lançar o aplicativo da fincare em tempo recorde
Digibee integra maior empresa de medicina diagnóstica do Brasil com a Rede Nacional de Dados em Saúde (RNDS)
Projeto durou apenas quatro meses e reduziu em até 20 vezes o tempo de processamento de pedidos através da plataforma Digibee.