Language: English

4 ways Johnson Brothers praises Digibee partnership

Johnson Brothers (JB), the 4th largest wholesaler and 3rd largest wine distributor in the US, manages over 27,000 unique alcohol products, each subject to different regulations, pricing structures, and distribution rules. JB partnered with Digibee and leveraged our cutting-edge technology to successfully tackle their integration challenges.

2024 Digibee Preview: The developer’s choice for enterprise integrations

In the ever-evolving landscape of information technology, trends come and go. From the Y2K frenzy to the buzzword bonanza of big data, cloud computing and microservices, tech vendors often find themselves riding the same bandwagon, whether the solutions truly warrant the enthusiasm or not. Today, the wave we’re all surfing is Artificial Intelligence (AI). It seems like everyone has an AI marketing message, but how many are releasing features that genuinely deliver real value?

Enterprise Integration: Lessons Learned at Gartner Symposium 2023

Working at Digibee, I spend a lot of time traveling to events where I interact with a broad range of people. As noted in previous posts, this is a part of my job that I really enjoy. The recent Gartner Symposium in Florida was no exception.

Since I’m engaging with people who are interested in evolving their integration strategies, many of the discussions focus on the inefficiencies of existing integration infrastructure and the need to modernize what isn’t working. Top of the list is the massive imbalance in resources required to simply maintain the status quo. 

Evaluating Integration Platform Pricing: Gartner Best Practices for Software Engineers

Gartner® recently published interesting research titled Integration Platform Pricing Evaluation for Software Engineering Leaders. It’s a well-written overview of how integration platform pricing and licensing models are currently structured, and all the variables that organizations need to think through to navigate this complex set of buying decisions.

Digibee has conducted similar research into the complicated pricing models used by legacy integration technology platforms such as MuleSoft. If the MuleSoft pricing model reflects the standard for traditional integration products, then the Gartner research will be very helpful to organizations burdened with (or about to invest in) these solutions.

Platform pricing is a complicated topic, with users required to navigate extremely complex pricing models that use a variety of metrics. For example, vCore, per seat or per user, endpoint connections, network load, instance based capacity, etc. In turn, these may be charged by tier, usage, and volume–all potential factors in determining the costs of different integration platforms.

According to the Digibee State of Enterprise Integration report in 2023, there are additional costs of maintenance and training, which consume almost 40% of integration budgets. There is a whole world of cost and complexity beyond just licensing. 

We’ve gained permission through Gartner to make this research report available to all. Frankly, we believe that the more information IT and architecture teams consume on the complexities of legacy iPaaS pricing and licensing, the easier it is to show the benefits of Digibee’s approach. 

Integration shouldn’t be so complicated

Gartner does a great job laying out the complexities of pricing for various technology models, and we can certainly vouch that most legacy enterprise integration vendors fit this bill.

When planning to obtain a new technology solution, we believe that software engineering and development leaders should be focusing on technology requirements, features, functionality and desired outcomes. Comparing pricing shouldn’t be so complicated as to distract from the real needs and goals.

Accurate comparisons are especially challenging when these exercises could incorporate up to nine different pricing metrics across various pricing models. Most importantly, you can’t limit your calculus to your current state. Future changes in consumption must be considered. You don’t want surprises down the road, and you can’t be in a position where your integration budget is a gating factor in your plans for development and innovation.

Now multiply these exercises based on however many solutions are under consideration and the scope of the work becomes clear.

I would argue that this is a waste of valuable resources that should be focusing on innovation instead. 

The Developer’s Choice

The need to empower software engineering and development leaders to actively participate in critical decisions relative to strategic investments is a business imperative.

Let’s face it, without software engineers and developers, enterprise integration would not be possible.

“Integration platforms are development tools, and like any software development process, you should plan for a staged delivery process – untested deployments to production will eventually cause a catastrophic failure of key business processes and systems.”

Integration Platform Pricing Evaluation for Software Engineering Leaders, Gartner
May 2023

Unless your company has very simple integration requirements, for example supporting a single point-to-point use case, your IT environment is complex, requiring a highly skilled workforce that understands the technology and–most importantly–your business. 

These are the people best-suited to provide technical guidance and to participate in the decisions that inform both your immediate and longer term integration strategy.

At Digibee, we call this Developer’s Choice, the autonomization of developers. Enabling these talented workers to focus on digital transformation that accelerates innovation and ensures the company consistently achieves its business objectives is our goal. 

Estimates show that the majority of integrations use custom coding. This coding time and effort is largely wasted, and it forces developers to do work that lacks scale and governance. Being the developer’s choice means providing a platform for all developers to use – to replace mundane coding and work that must be continually repeated.

Sadly, for many organizations saddled with legacy integration products, these valuable resources spend inordinate amounts of time performing this work. For example, upgrading on-premises integration tools, redundant coding, and other lower value tasks (such as building complex pricing comparisons). 

With contemporary born in the cloud technology, integration is democratized. Complicated workflows and time-consuming work are no longer a requirement. All developers are empowered to contribute, freeing up bandwidth and allowing developers to truly flex their muscles and innovate for the sake of the business.

Modern enterprise integration

If your software engineering and development leaders are sinking significant time into product and pricing comparisons, then you may want to reconsider the complexity of your IT environment.

A Digibee pricing comparison takes minutes. Our all-in-one pricing model is enabled using three SKUs (yes, you read that right), with no limitations. Support, maintenance, and training are included in the subscription price at no additional charge. We help you build your first integrations, and train your developers quickly, without a professional services charge that can too often be a budget buster.

The Digibee Integration Platform streamlines convoluted workflows, providing a technology model that is accessible to all developers. With a 10-day learning curve (at no cost), even the most junior developers are building integrations within weeks.

The role of developers within your company’s integration strategy is undeniable. Not only to guide purchasing decisions, but to develop and execute upon an integration strategy that delivers what your business needs today and into the future.

Next steps with Digibee

Thank you for taking the time to read this blog post. If you have an integration story you’d like to share or you’re in the midst of a project you’d like to discuss, please reach out to me directly on LinkedIn

For a better understanding of how to produce comparisons of complex pricing models during your integration technology selection process, download your complimentary copy of the Gartner research. The templates in particular will be helpful to you in carrying out such intricate work.

If you’re interested in learning more about Digibee’s born in the cloud iPaaS for a simpler, faster, and modern approach to integration, then contact us for a demonstration or visit our website.

Gartner, Integration Platform Pricing Evaluation for Software Engineering Leaders, Andrew Comes, Keith Guttridge, 17 May 2023

GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.

The Future of Integration: Digibee’s Take on Price, People, and Productivity

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


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.


Thanks, Cait. 


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.


Yep, absolutely. 


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 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.”