For as long as I’ve been selling enterprise software, I’ve heard the same question over and over:
Does your software integrate with [insert platform here]?
Often, this is asked by people who don’t quite know what it means; they just want to know that whatever they’re about to buy will work — in some undefined way — with a thing they already have or might want to have in the future.
Here's why this is a problem —
The integration question that hides everything
Consider the question: “Do you integrate with Salesforce?”
… well, technically, yes. But in what way?
As of this writing, Salesforce has between 30 and 40 separate products and industry lines (depending on how you count). So, which product do you want to integrate with? And any given product has dozens of features. Which feature do you want to integrate with? And in what way?
It’s like saying, “Oh, you’ve been to Chicago? So, you know my childhood friend, and you’ve eaten at that restaurant I like?”
Well...I know a lot of people in Chicago, and I’ve eaten at a lot of restaurants there, but I have no idea if any of them are the same ones you’re talking about. The possibilities for what you're talking about are literally equal to the number of people and the number of restaurants in Chicago. (Which is a lot.)
There are a handful of common drivers behind the question.
The person simply knows that the two systems “being integrated” would probably be beneficial. They're often driven by the vendor-fueled fantasy of a perfectly interwoven stack of technologies, working as one. (At some level we're all looking for the uber-application, that does everything.)
The person believes that “integrating” with an existing system would help the business case to purchase the new system.
The person has seen some specific example of the two systems working together and wants the same thing.
With the first two drivers, the range of functionality is completely unspecified. The only accurate and honest answer to their question would be, “Integrate in what way?”
The last driver is more specific, but too often, the exact example of integration the person has been exposed to is not made clear. They might simply assume that the phrase “integrate with” adequately covers the specific example they’re thinking of.
Understanding your integration needs before asking
In order to ask the right question, you have to be aware of what you're seeking. What someone wants from an “integration” might be:
“I want to see and work with System B while I’m in System A.”
“I want System A and System B to be able to talk to each other and share information so they can operate differently.”
“I want System A to notify System B when something has happened, so that System B can do something.”
We can roughly categorize these as:
User interface integration: You want to work with one system — or see data from that system — while technically being “in” another system.
Data integration: You want a system to “talk” to another system and be able to make logical decisions based on data in that other system.
Event integration: You want one system to be notified of events that happen in another system and be able to take action in response to them.
These are what we're going to cover below.
What follows is a broad, general survey of patterns. This might seem too general, but that’s the real nature of integrations — while they seem diverse, they’re all mostly just variations of a few core patterns. I’ve included examples with each one, which I hope make them each a little more concrete.
5 core integration patterns
For this article, we’re going to define the terms as follows:
Host: The main software platform the user is working with. This will “host” the integration.
Remote: The “other” software platform; the platform we’re going to “bring into” the Host.
Another key point: They tend to be asymmetric — one system wants data from another system for a specific purpose, not shared by the other system. In each integration, there’s some concept of external data from one system (the Remote) being “brought into” another system (the Host).
Now, we're ready to break down the five major patterns I've seen for integrations.
Pattern 1: Embed — Display Remote in the Host
In this pattern, some user interface element or data from the Remote system is displayed in the Host system. The Host is merely the messenger — it doesn’t know what the data or the interface is, and it doesn’t really care. Its job is simply to get it in front of the user.
In many cases, the goal is to aggregate multiple systems into the much-vaunted “single pane of glass,” which promises that users can see everything in one location.
This is where we get the idea of “dashboards,” often with functionality that lets users customize it to show specifically what they want to see. (Although in practice, this rarely happens).
Remember: The Host is not acting on this data in any way. It’s just displaying it. The Remote system provides the data and the functionality, but exposing this in the Host is usually just to make it more accessible for the user. The Host is just showing a "window" into the Remote.
Examples
Scenario 1: Every night, the production system calculates statistics for all customer service reps and publishes an HTML file showing this data.
The company intranet has a page that displays the current content of this HTML file, so managers know where to find it every morning.
Scenario 2: Administration of the event registration system is limited to a small group of users. However, to simply register for an event, a small application is built that allows employees to indicate their intention to attend an event.
This user interface is “wrapped” in a “custom widget” that editors can configure and embed on intranet pages discussing the event, giving employees an easy way to register directly from the news article.
Keep in mind: It’s worth repeating that, in these examples, the Host doesn’t know what content or functionality it’s displaying — it’s just the messenger, and is not responsible for the message, just like your television set isn’t responsible for (or even understands) the TV show you’re watching.
Pattern 2: Push — Send data from the Host to Remote
In this pattern, the Host system can proactively send data to the Remote system, meaning the Host initiates the connection between the two platforms and sends some of its data to the Remote.
When some event occurs in the Host system — a user logging in, data being saved, etc. — the Host can be configured to push data to the Remote. The data that is pushed is related in some way to the event that just happened. (For example, the ID of the content that was just saved.)
The Remote system is configured and prepared for this. It has an endpoint that receives this data and does something with it.
The cause of this connection and data push can vary. It can occur in response to an event, in what is colloquially called a “webhook.” Other than responding to events, the Host system might push this data on a schedule, or even on demand when a user tells it to.
Examples
Scenario 1: Whenever a new news article is added and published that contains the tag “press-release,” the Host system pushes the content of the news article to an endpoint at the organization’s PR agency for publication as an external news release.
Scenario 2: Whenever a page is changed or deleted, the Host notifies an archival platform and pushes the ID of the page that was just changed. The archival system then retrieves the last version of that page for offline storage to abide by compliance regulations.
Scenario 3: Every night at midnight, the Host sends a log file to an InfoSec server containing the usernames of all employees who logged in that day. That server compares the data to an HR database to ensure no “zombie” accounts of terminated employees still have access.
Pattern 3: Pull — Retrieve data from Remote to the Host
In this pattern, the Host retrieves information from the Remote and uses it in logical execution. This is the opposite of the willful ignorance of the “embed” pattern mentioned above — in this case, the Host is using the data from the Remote to affect how it functions.
In many cases, this information is related to the specific user experiencing the Host. By retrieving information about this year, the Host can alter how it functions to provide a personalized experience for each user.
Examples
Scenario 1: When a user attempts to log in to the intranet, it passes the username and password to another system to authenticate the user and assign them permissions.
Scenario 2: When a user logs into the intranet, it contacts the Human Resources system with the user’s ID and retrieves the employee’s home office address.
It then uses this information to prioritize news articles in the employee’s feed so that they see news affecting their office first.
Keep in mind: In most cases, this pattern implies real-time communication — data is transmitted or refreshed when requested or needed. Necessarily, this means that the Remote system must be available at the moment the data is requested.
For example, consider the first scenario above. If the Remote system is down for some reason, no one will be able to log into the intranet.
Pattern 4: Clone — Translate and recreate Remote data in the Host
In this pattern, the data shared with the Host is imported and turned into native structures inside the Host. These data structures are treated by the Host as if they originated within it.
Examples
Scenario 1: When a news article is published to an “External Comms” folder in the intranet (the Remote), the content management system (CMS) powering the external website is notified (in this case, the Host), and the press release data is transmitted and turned into a “News” item in that CMS.
From that point forward, the CMS doesn’t know if that News item originated from the intranet or was entered directly into the CMS itself. It’s handled the same way, with all the services and features of other News items.
Scenario 2: Overnight, the intranet accesses a file exported from the Human Resources system, which contains the data for new employees. It creates user profiles for each new employee, populating their data with what was exported. Future user management is done manually.
Keep in mind: Unlike prior patterns, this “cloning” process tends to result in a “detached” data structure in the Host. If changes are made to this data in the Remote system, it might be re-cloned to reflect the changes, but once closed to the Host, the data is accessed there.
This means that the Remote system can cease to exist, and the data lives on in the Host. No real-time communication is needed.
Pattern 5: Synthesize — Accumulate multiple remotes’ data in the Host
In this pattern, the Host becomes an aggregation point for data from multiple Remote data sources. The Host can combine, refine, filter, report on, and use this data in combination.
Examples
Scenario 1: The intranet has a centralized notification system. This system can be contacted by multiple systems, each providing information about items needing attention.
The intranet maintains a database of these notifications and can provide them to each user, filtered by time received, calling system, severity level, etc.
Scenario 2: Data warehouses contain summarized data from dozens of systems across the enterprise: transaction sales, inventory management, human resources, employee scheduling, etc. These systems allow this information to be “mixed” together and reported on in ways that would be impossible for a single system working on its own.
To find out if a restaurant sells more expensive dessert items on evening shifts when servers who have received 90th percentile performance reviews comprise more than 75% of the front-of-house staff would require combining data from every one of the systems mentioned above.
Keep in mind: As in the second example, the Host in this pattern is often explicitly intended for reporting (often called “business intelligence” or “decision support” systems).
Recognizing the risks of integration
While connecting software is sometimes seen as a universal good, there are risks, both initial and continuing. The two main risks that stand out to me are as follows:
Build risk
First, if you're integrating yourself (or having it done specifically for your organization), there’s a build risk. These systems are complicated, and connecting them is almost always involves a significant development effort.
Systems speak different languages, but more challenging is the reality that they often have entirely different paradigms of what data represents and how it’s stored and managed. It’s sometimes not only a language difference, but something deeper and more fundamental.
Imagine you need to talk to someone who speaks a language you don’t speak. Assuming you get past that problem, but then find out that they insist that every communication be accompanied by an interpretive dance.
These risks continue after the initial build. Software platforms change over time. A new version of software is often accompanied by “breaking changes,” which will make prior integrations not work anymore.
Runtime risk
Even if you use a pre-built integration, there’s a runtime risk, which is continually lurking in the background. When you connect two software platforms, they now depend on each other for that functionality to work.
This means that the Host needs to be able to connect to the Remote and vice versa. Additionally, that connection has to be stable, fast, and not burden either system too heavily.
The most well-designed integration in the world won’t help if the Remote system is offline. Nor if the Host starts peppering the Remote with so many requests for information that it slows that system down.
Some of these risks can be mitigated by good design principles — for example, the Host can “cache” data, which means to hold onto it, only re-requesting it when it might have changed. As a general rule, you want to reduce the need for real-time connectivity as much as possible. If possible, the Host should sporadically request fresh data from the Remote, but remain as self-sufficient as possible.
But just know that all the mitigation in the world doesn’t change that you’re connecting two systems and thus introducing a dependency.
Understanding the integration economy
Lots of companies build integrations between their systems, for different reasons. Some of these are legitimate needs, but others are more about marketing and positioning than actually solving problems.
Company A might see it as a desirable feature in sales because it wants to appeal to Company B’s customer base. Lots of companies have official “partnerships” that specifically shop around the market for companies they can link to.
Many times, these integrations are superficial — just enough to say that there’s a partner, and so their sellers can answer “yes” when someone asks the infamous question that opened this post: “Do you integrate with X?”
If the integration does exist, sometimes it’s rarely ever used. I’ve seen integrations that existed solely to fill out a “partner catalog,” but that no one had ever actually installed.
Still, it provides value because it frames the company as an integrated member of their industry, and it implies that the targets of the integration (Company B) have given their stamp of approval. But often, Company B doesn’t even know that Company A has built or is promoting an integration at all.
Additionally, even if it’s never used, it’s often helpful to have the integration. Some prospects will inevitably think, “I might use Company B in the future, so it’s good that Company A can support that down the road.”
In the prospect’s mind, Company A is clearly flexible and extensible enough to support integrations in general, and that checks boxes for a lot of people.
Thinking critically about integration: Best advice for success
When talking about connecting systems together, there’s simply no substitute for being as specific as possible. Instead of saying, “Do you integrate with X?”, you should be asking: “How do you integrate with X?”
Then, have them show that to you. Literally visualize the data in both systems, and how a user would interact with it. Ask for a demo.
If you have something specific in mind, spell that out. Know that when you say “integration,” there’s a very small chance that you and the other party are talking about the exact same thing.
And understand if they respond “yes” to your general question, what they’re saying is “We integrate in some way.” Whether this provides the actual value you’re looking for is completely up for grabs. You're asking a vague question, and you're getting a vague answer.
Finally, ask who built the integration. Ask who is going to support it. And ask how many people have installed it and are using it. See if you can talk to one of those people.
Final words on integrations
Over the last 30 years, I’ve seen implementations of lots of software go poorly. Often, it’s because assumptions were made during the sales process about what the system could do, and lots of those assumption were about how it could interact with other software systems.
This is doubly worse when a customer bases the purchase of a system on assumptions they’ve made about how it works with something they already have. They have an existing investment, and they're considering what would effectively be an expansion of that (in the form of connected software). Way too often, they just toss this up to the "integration Gods" and assume that it's going to go well.
The bottom line is that we need to think more critically about what we mean when we talk about integrating software. These are easy — and even fun — to talk about in the abstract. But at some point, actual bytes on disk will be exchanged and processed by both systems, and unless you’re careful, that might manifest itself in a way that falls far short of what you were expecting.
Final advice? Be specific. Don't assume. Ask questions. Request demos.
