Not all integrations are created equal: 4 layers of app integrations with SaaS platforms

Disclosure: This is one of those rare articles on this blog that’s entangled with my work as VP Platform Ecosystem at HubSpot. While it’s not specific to HubSpot — this is an issue and a framework that I believe are broadly applicable across all SaaS platforms — I want to be transparent that I do have a stake in how these dynamics play out in our industry.

According to a recent study by the market research firm Ascend2, “integrating disparate systems” is the greatest barrier to success with marketing technology for 52% of marketers.

But why?

After all, we live in the so-called API economy. Nearly every SaaS product has APIs, and nearly all the major marketing platforms have “app marketplaces” where customers can choose apps from a wide pool of certified technology partners.

There’s even an entire category of products — integration-platform-as-a-service (iPaaS) tools — that exist solely to connect disparate systems together. Some have made it so easy for non-technical people to do this that Gartner refers to their users as “citizen integrators.” One of the more popular ones, Zapier, integrates a whopping 1,300 different apps with each other.

For pretty much every pair of popular cloud-based products, there’s some off-the-shelf way to connect them. So why is integration a barrier at all? Haven’t we checked that box by now?

Not All Integrations Are Created Equal

“Does X integrate with Y?” is a deceptively oversimplified yes/no question. In the cloud, the answer is almost always “yes.” It’s kind of like calling a restaurant and asking if they combine ingredients together. Sure they do. But how tasty is the meal? How attentive is the service? How reasonable is the price?

If X integrates with Y, follow-up questions should peel back exactly how deep that integration is:

• What are the use cases of the products working together?
• What data is shared between them? Is it bidirectional?
• What is the flow and user experience like between them?
• What is the experience like for the admins who manage them?

Ideally, the bar we should hold integrations to is: what makes apps better together?

When you start digging more into those details, you appreciate that the capabilities and user experience of integrations can vary significantly. As the average number of SaaS subscriptions per business continues to grow, the “stack debt” incurred from insufficiently deep integrations can mushroom, dragging down our efficiency and effectiveness across the digital toolbox we’ve assembled.

So how might we quantitatively compare apps across the spectrum of possible integration?

The Four Layers of App Integrations Framework

I’d like to propose a framework for evaluating the depth of an integration between an app and a cloud platform as follows:

This model considers integrations on four levels, starting at the bottom with integrating data and working our way up to governing the collection of apps being integrated:

1. Data: passing fields, records, or other packets of information between systems. This is the most common kind of integration between cloud services. How each system interacts with the data is often undefined at this level.
2. Workflow: standardizing or automating the flow of data and activity between people and systems. The most common pattern is an event in one system triggering a sequence of predetermined actions across others.
3. UI/UX: embedding elements of the integrated app — or the entire app itself — in the user interface/user experience of the platform. This gives platform users visibility into and the ability to interact with integrated apps, without continually switching between different systems and interfaces. (See “The One Window Test.”)
4. Governance: establishing and enforcing rules and standards across all approved apps in the platform’s ecosystem. This makes it easier and safer for users to adopt and manage apps built by different vendors with greater consistency and control.

As we go up the y-axis of the above diagram, we advance to higher levels of cognition in the integration. Exchanging data is a relatively rote, mechanical process. Workflow incorporates dynamic behaviors. User experience is how we comprehend and interact with the combined products. Governance is how the collection of apps that we’ve integrated are managed.

Thinking of Integrated Systems as a Digital Language

Here’s a non-technical metaphor to distinguish what’s happening at these different levels:

• data –> nouns
• workflow –> verbs
• UI/UX –> language
• governance –> grammar

Data are nouns, the fundamental objects we work with, and workflows are verbs, the actions we take on or with those objects.

UI/UX is a common language for communicating with those nouns and verbs. Do integrated apps speak the same language, like two collaborators both talking in English? Or is it like a Tower of Babel, where different systems present things very differently — even when they’re talking about the same underlying objects and actions?

Governance is the grammar of the language. Anyone can string words together in a language, but are they combined together as proper sentences that make sense? Good grammar assures us of a certain level of coherence to avoid gobbledygook. So does good governance of apps on a platform.

There’s a wide range of depth and elegance in how different platforms implement these four layers. Shallow integrations give you Dr. Seuss. Deep integrations give you Shakespeare.

The Extent of Integrations Can Vary Significantly at Each Layer

Let’s examine the degree to which apps can be integrated at each of these levels.

For instance, consider the extent to which an app can be integrated at the data layer. A light data integration would simply sling data in one direction, from an app to the platform, with no concern about what happens to it down the line.

Did the data overwrite or conflict with an existing record? Was it in the right format? Did it maintain relational integrity with other data fields? What if the same data is updated later by some other app on the platform? Will the original app get notified of the change? What happens if a problem occurs? Does it ignore, alert, or retry?

A light data integration blithely answers: don’t know, don’t care.

Richer data integrations, on the other hand, can sync data bidirectionally, intelligently resolve conflicts and collisions, enforce data quality and integrity, normalize key fields such as identity, notify related apps when the data changes, recover gracefully when problems occur, and more.

A rich data integration exerts an opinion on how information is modeled and maintained.

Similarly, a light workflow integration may operate by automatically triggering a simple action in response to a well-defined event. A visitor fills out a form on a landing page, and you enroll them in a list in your marketing automation platform. It’s useful, but limited to relatively basic if-this-then-that sequences.

Richer workflow integrations support conditional logic that triggers different actions depending on the details of an event or the context in which it occurred. More advanced workflows can combine automated and manual steps, for processing requests that require human reviews or approvals. More sophisticated workflows can incorporate custom algorithms, maybe even AI functionality, to dynamically route and respond to events.

Integrations at the UI/UX level have even greater variance. A light UI integration might only have a read-only spot in the platform’s interface where an app may surface limited information about its own data or activity. It may offer a link back to the app, but clicking on it just opens a new window that drops the user in a completely different interface with little or no context.

Richer UI integrations, in contrast, keep more — or even all — of the user experience inside the platform’s interface. Apps can be embedded right in the platform, so users don’t have to jump out to different windows to interact with them. A common, flexible UI “canvas” lets third-party developers build apps that look and feel like they’re native to the platform.

The continuity of rich UI/UX integrations can make it much easier for users to adopt apps, since they don’t have to learn a new interface for each one. They already have their bearings and can quickly focus their attention on the new functionality the app gives them.

The governance layer of integration has a wide range of possibilities too. Light governance might only ask an app to be briefly reviewed before being listed in a platform’s app directory. How the app is sold and supported is completely up to each app developer. It’s a laissez-faire approach to the ecosystem.

Richer governance models impose stricter requirements for an app to be certified. Apps can be sold through the platform’s marketplace, which simplifies installation and billing. A centralized subscription management system gives users greater control over their entire stack of apps on the platform. The platform can monitor and enforce compliance with data privacy regulations, performance SLAs, and security practices. It can authenticate app ratings and reviews from real users to prevent astroturfing.

The more responsibility the platform takes for governing the apps in its ecosystem, the less risk there is for users to adopt them. Since trust is arguably the most valuable asset in any platform ecosystem, good governance can create significant value for all of its stakeholders.

Comparing Different Platform Integrations

“Does X integrate with Y?” clearly deserves better than a yes/no answer.

Using the framework just described, we can now compare the extent of different integrations on each of these four levels. As an example, consider three hypothetical options for connecting a webinar app with a CRM platform:

Option A represents a simple, iPaaS-style integration. A form filled out on a registration page in the webinar app triggers a new contact record to be created in the CRM. If the contact has the same email address as an existing record, the CRM simply overwrites the other fields with the new data that’s passed in. There’s no UI/UX integration between them and no governance. The CRM platform company may be completely unaware of the webinar app vendor if there is an actual iPaaS in between them. Caveat integrator.

Option B illustrates a more direct integration between the webinar app and the CRM. Data is exchanged bi-directionally, adding registrants to the CRM and augmenting the webinar app’s profile of attendees to deliver a more personalized experience. A user can determine whether the webinar app or the CRM takes precedent when data fields are being updated. When a registrant attends the webinar, a note with details — e.g., duration watched, questions asked — is added to the contact’s timeline with a link to the recorded webinar. The webinar app was reviewed and certified by the CRM platform company, but still purchased independently.

Option C depicts a deep integration between the webinar app and the CRM. It takes Option B much further. The entire process of setting up a webinar and promoting it is done in the CRM platform’s interface, with contributions and approvals managed through a structured workflow process. Sequences can be automatically triggered by micro-events during the webinar, such as an attendee staying past the halfway point, submitting a question along the way, or rating the content at the end. The webinar app was purchased in the platform’s marketplace for certified apps, based on verified reviews from other users. The platform continually monitors the app’s performance and compliance with GDPR rules and requests.

These three options offer very different integration experiences.

While an Option A approach is better than nothing if you need to connect two independent cloud services together, it leaves much of the work and responsibility on the shoulders of the user to figure out how to manage the integration. An Option C approach relieves the user of that burden, delivering a qualitatively smoother and safer integration.

Option A is a little like duct tape. Option C is a more like Lego pieces snapping together.

Martech Integrations Can Grow Better

To be certain, building a platform and apps that integrate deeply with each other requires more design effort by the developers on both sides. But that investment can pay off in reduced effort required by users to connect those products and getting them to work better together. When that’s multiplied across thousands or millions of users, and hundreds or thousands of apps, its value grows exponentially.

Because of the real value that can deliver to marketers — and ultimately their customers — I believe that the martech industry will see significant improvements in the depth of integrations between apps and platforms in the years ahead.

Integrations are not black-or-white propositions. But shallow integrations versus deeper ones can be night and day experiences.