**Steven Forth** is a Managing Partner at Ibbaka. See his Skill Profile on Ibbaka Talent.

Optimize your pricing strategies with ibbaka valio - learn more here

Integrations have become central to how software applications create value. It is rare to find all of the data needed for insights and predictions locked within one application. Instead, the smartest enterprise customers are thinking in terms of application ecologies, and are requiring vendors to support integrations. At the same time, integration platforms are coming to prominence (they have existed for decades) and establishing themselves in the market. Many SaaS product managers are asking how to price their integrations and the API libraries they use to support them.

As with the pricing of predictive analytics, value-based pricing provides a way towards strategic pricing of integrations. In this case though, the situation is complicated by the multiple players involved. There are the two (or more) vendors, the company using the integrations and possibly an integration platform acting as an intermediary. The integration platform could be proprietary, with its own pricing and monetization mode, or an open source alternative. Sometimes the data stays on the application where it originates, other times it is passed through to another application, or it may flow into a data lake where many applications can access it.

Untangling value and differentiation, the foundations of value-based pricing, can get complicated fast in this world.

The basics of software integration

Before we dig into value metrics and pricing metrics, let’s take a look at the most common integration patterns. Fortunately this is a mature space. And the patterns are well understood. The classic books on the topic are Hohpe and Woolf Enterprise Integration Patterns and Patterns of Enterprise Application Architecture by Martin Fowler.

There is even an excellent wiki style website with extensive discussion of the different patterns: Enterprise Integration Patterns.

Some of the most common patterns you will want to be aware of as you think through pricing issues are listed below. It is important to understand these patterns as the value associated with them is different.

Messaging: Applications can be set up to send and receive messages. These messages can come in many different forms. They can be sent by email, text messaging, inside communications applications like Slack and MS Teams. Basically any digital channel that humans use to communicate can also be used by machines (even voice if there is is some reason to do so). The message can be simple text, something fancy like a JSON (JavaScript Object Notation) or something in between like a .csv file (CSV means comma separated values).

Extract Transform Load (ETL): This is the grandmother of integration styles. You pull out some data (extract), change it around (transform) and upload it into another application (Load). This approach is still surprisingly common and is often a first step to a more sophisticated approach. The ETL process can happen once, to move data across, or it can be scheduled to happen as often as necessary.

Application Program Interface (API) and Remote Procedure Innovation (RPI): This is the fancy way to do integrations and sophisticated vendors will talk about their API libraries. This is great, but an API is really onl;y a door, and just because there is a door it doesn’t mean that the data that comes out will be usable by another application. There is usually still work to do and some transformation of the data is usually needed somewhere.

Enterprise Service Bus (ESB): A bus carries people around town (“the wheels on the bus go round and round”), an enterprise service bus carries data from one place to another, often along scheduled routes defined by business processes. “The bus will drop you off here to get your hair done, then pick you up and take you to the restaurant for dinner.” ESBs are a class of software with both proprietary and open source options.

Shared Database: Sometimes two (or more) applications want to get really intimate and share a database. This is unusual, most vendors are jealous of their data and their data structure, but in some cases, where there are many different but tightly dependent uses this can be the best approach.

A Data Lake: When there is a lot of data from many different sources, it can make sense to have it all flow together into one large data store called a data lake. This approach is often used for pattern recognition, predictive analytics and other artificial intelligence (AI) applications that need large and diverse data sources.

In general, integrations that rely on APIs are seen as reflecting greater commitment and having more value than the ETL style, which is seen as being a bit old school. A shared database is rare as it reflects a very deep level of integration, and trust. Data lakes, on the other hand, are often seen as low value enablers of high value predictive analytics.

An example from the talent management space

To give you an idea of just how extensive these ecosystems can become here is an example from Ibbaka Talent. Data flows in many different directions with everything from basic ETL approaches to dynamic APIs.

Value is created in many ways across this ecosystem, and for different stakeholders. Recruiters get value from the integration with the Applicant Tracking System (ATS) as they get immediate information on jobs and the skills they require; learning and development teams are able to design learning to address targeted skill gaps; enterprise analysis can see how skills are contributing to enterprise performance. One could add other applications to this ecosystem. A project management system such as Asana or Basecamp could be integrated so that project members could see the skills and experiences of people on their project, while the skil management platform (Ibbaka Talent in this case) can translate from tasks (the main object in project management systems) to skills (what skill management cares about) and then infer skills from tasks.

Emerging integration platforms and how they price

Integration is so central to building an agile organization and to digital transformation that there is a swarm of integration platforms. Let’s take a look at a few of the more popular ones and see how they price.

Mulesoft: Let’s start with Mulesoft, one of the best regarded iPaaS (integrations platform as a service) vendors. Mulesoft does not publish its prices, but it does disclose quite a bit about its pricing model on its website. There are three tiers, Gold - Platinum -Titanium (works for me, my road bike has a titanium frame). The pricing metric is the ‘core.’ “A core is a unit of processing power, and can be physical or virtual. For your flexibility, we price the physical and the virtual core the same.”

It is interesting to see what is included in each tier and what is priced separately. The lowest tier, Gold, does not include many of the capabilities one would need for a true enterprise solution, such as high availability, external identity management and flexible hybrid development. These are not available as add ons, if you need a true enterprise solution you are looking at the Platinum or Titanium tiers. For all tiers, premium connectors, the cloud messaging service and advanced security are extra.

An interesting feature of Mulesoft’s pricing is that it does not differentiate where the service is hosted or how it is accessed.

Are the ESB pricing, CloudHub pricing, On premise pricing and API pricing same?

Yes. MuleSoft’s pricing plan is consistent with its unified, hybrid integration strategy across cloud, on premises, integration use-cases and API use-cases. The Anypoint base subscription is the default entry point and other add-on functionality can be purchased on top of it.

The value drivers are suggested in this customer quote.

Airbus speeds up IT project delivery by 4X “MuleSoft enables our developers to search, discover, amend, develop, and deploy APIs. Having reusable assets and getting the benefits of those assets across the enterprise allows us to develop faster and cheaper, and at scale.” Chris Taylor, VP, Digital Accelerator, Airbus

Zapier takes a different approach. Its focus is app integration and it is generally used in more agile environments than Mulesoft. Zapier does publish its pricing. It uses a five tier model (including a free offer) with the priced tiers ranging from US$239.88 per year for the Starter tier (which is $19.99 per month, see how tricky pricing designers can be) to US$7,188 for the Enterprise tier ($599 per month).

The value metric here is ‘tasks.’ You get up to 100 tasks per month for free, 750 tasks per month for the Starter package, all the way to 100,000 tasks per month for the Enterprise package. Let’s graph the implied price per task at the different tiers.

Note that we now have two quite different price metrics for integrations, ‘cores’ from Mulesoft and ‘tasks’ from Zapier. The design and construction of the pricing metric is one of the key moves in pricing model design.

Another price metric that comes up in cloud services and in integration is the ‘node hour.‘ Note how this relates to a core (the definition comes from Nimbix).

A node-hour is unit of work indicating that an application ran for a time t on n nodes, such that n*t = 1 hour. Using 1 node for 1 hour is 1 node-hour. This is irrespective of the number of cores on the node you actually use.

Let’s look at one more data integration provider before asking how application vendors should price their own integrations.

Diyotta offers seamless data integration (and their website has a pretty good explanation of some key concepts in data integration. Diyotta also offer a tiered architecture, priced per user with some other interesting fences.

Let’s graph this too. It is a best practice to do this and look to see if the pricing curve is linear, concave of convex.

In this case it is concave, which implies that Diyotta sees more opportunity at the bottom of its market (see Push Me Pull You - Your pricing is a system).

Note that the key pricing metrics here are Users and Agents and that you get the same number of users as agents. An agent is defined by Diyotta as

An Agent is a light Java program that helps move data between servers in a frictionless manner. These agents can be created in the Diyotta server or external servers based on the requirements.
When the data is handled through the Agents, the server compresses the data which eventually reduces the bandwidth required for loading it from source server to target server.

Per user pricing does not make much sense to me for pricing integrations. The number of people managing the integrations will not normally track value. There are cases when per user metrics make sense, but this is not one of them. I wonder if users has not been slipped in to make the pricing seem more familiar and that the real pricing metric here is agent. Remember that the best pricing metrics track value metrics.

The value metric is the unit of consumption by which the user gets value, the pricing metric is the unit of consumption for which the customer pays.

Just who is creating the value (and the differentiation)

Data integration creates a network of applications and the value of the integration lies inside this network. This can make it more difficult to make claims about where the value is being created and what is driving the differentiation. There are are conceptual tools being developed for this, see Judea Pearl’s work on causality, but for now what we need are some heuristics. Let’s begin by answering some questions.

What is the system of record?
Generally speaking the system of record will be able to claim more of the value created.
Which system is generating insights?
If your system is generating insights, it is generally a better strategy not to charge for integrations and to focus on monetizing the insights. See When to price predictive analytics.
Is the data unique and does it provide unique value?
If the data is not unique and could be acquired or inferred elsewhere then it is a commodity and the price should be set relative to the alternative. If the data is unique but becomes more valuable when used with other data, the system is complex. Estimate the value of the total package, allocate 30-40% to the system of record and 30-40% to the predictive analytics platform. Go through each data source, remove it, and calculate the value again. Where the data is multiplicative (the value goes to zero without it) give it a high weight. Where the data is additive (there is still value without it) give it a lower weight. In fact, in the absence of a formal approach to allocating value under complex causality (this is what Judea Pearl’s work enables), this is likely to devolve into a power struggle between the different vendors. Large and powerful companies with sophisticated procurement groups will figure out a way to play the vendors off against each other. It is better to get together and negotiate multivendor integration packages. In most cases, these will be delivered through one or more integration platforms. For example, in the Human Capital Management and Talent Management space, Sapper is emerging as the integration platform of choice.

Some approaches to pricing

Application providers with valuable data have two decisions to make.

Work with one or more iPaaS vendors or go it alone
Charge for professional services, charge separately or make it part of the base offer

Go it alone or rely on an iPaaS vendor

If the integrations are standard and repeatable consider partnering with an iPaaS vendor or building your own integration platform.

Only build your own platform if you are going to be the system of record and plan to offer a predictive analytics solution.

If there is very high demand (market pull) for the integration, consider partnering with one iPaaS vendor that is strong in your space. A revenue sharing arrangement may be possible.

If integrations add significantly to your value and make you more attractive to buyers consider partnering with as many integration platforms as possible.

Pricing your integrations

The two extremes for pricing integrations are to offer them as professional services or to roll the value of the integrations into your base subscription. The middle way is to offer an integration module (not just the direct integrations but the integrations put into context and made meaningful.

When the customer requirements are unique and complex, and cannot be avoided, then you will need to charge for customer services. You don’t want this to be one off, build in an annual fee to capture the value of the integrations over time.

When the majority of your customers will want the integration (this is often the case with Single Sign On or SSO) and the integrations complement or enable your existing value drivers but do not add new ones, then roll the value of the integration into your base subscription.

The really interesting case is when the integrations create unique value for a specific market segment. By unique value I mean that a new value driver is introduced (remember that value drivers come in economic, emotional and community flavors, see What is value-based pricing). In this case consider packaging your APIs into an integration module and pricing it with its own pricing metrics.

So how will you price your integrations?

Integrations are becoming central to how value is created in the B2B software ecosystem. There is no one answer to how to price integrations and it is possible you will want to use a combination of strategies. For the most common integrations, that can be supported by iPaaS vendors, go ahead and partner. If your customers have unique requirements then you will need to offer the integrations as customer services. But if integrations create new value drivers for target segments, create a new module, package it as fully recognized functionality and design a pricing model that communicates and captures the value.

Ibbaka has deep expertise in pricing integrations. We will be happy to begin a conversation with you on this.