As a software vendor, there are a lot of factors that go into planning and executing the right integration approach.
Getting it right has a massive positive impact on your customer’s experience, internal operations, company profitability, and shareholder value. Getting it wrong does exactly the opposite.
In this post, I want to share some guidelines for how to think about integration approach using two factors: customer requirements complexity and customer requirements contrast.
Integration Decision Matrix
Requirements complexity and requirements contrast are far from the only things to consider, but they are two of the most important. Understanding where you fall on the high/low scale for both of these factors will get you a lot closer to making the right strategic integration decisions.
These categories are:
- Low Requirements Complexity, Low Requirements Contrast
- High Complexity, Low Contrast
- Low Complexity, High Contrast
- High Complexity, High Contrast
For the rest of this post, I’ll go through four categories of integration, and how best to approach unique concerns in each category.
Low Complexity, Low Contrast
When your customer’s requirements are of low complexity and low contrast from customer to customer, the name of the integration game is fast and inexpensive.
Low complexity and lack of contrast between customers means that the integration is a commodity. That’s not to say the integration is unimportant, but the integration isn’t doing much to help your customer differentiate. Integration might even be a required cost of entry.
To approach low complexity, low requirements contrast integration, I’d typically recommend building in native integration to your product. The relative cost of building such an integration is low, and supporting it shouldn’t scale inefficiently as you add customers. (It’s just a lot of the same thing.)
Building the integration yourself also gives you the ability to embed the configuration experience (which should be as simple as the the complexity is low) inside your application. Think of something as simple as “enable this integration”.
This approach allows you to provision integrations quickly and easily. It minimizes scalability costs for you. It eliminates the need for the customer to pony up for the integration features, too. This is important if the customer sees the integration as required and/or not differentiating.
(Slight caveat: There are sometimes reasons you would treat the integration capability as an up-sell feature.)
Example: Email Integration
Many tools integrate natively to your email experience–think about a CRM that plugs into Gmail for easy activity recording.
Email is simple and well-understood. There isn’t much opportunity for differentiation, because it’s a ubiquitous concept. When integrating a software product into the email experience, it’s a pretty linear path. And while, your email integration may not help you or your customer significantly differentiate, it might be a must-have requirement.
High Complexity, Low Contrast
When your customer’s integration requirements are of high complexity, but low contrast from customer to customer you need to enable tools for those responding to high complexity requirements without burying yourself in cost.
In high-complexity integrations, it’s common that the customer won’t have a great perspective on what they need or how to get it. This puts the burden on you or a third-party integration service provider to help them through that process.
If you can’t help your customers through these challenges, and the integration is a requirement (not just a nice-to-have), it could scrap the whole initiative. When the project goes poorly, takes too long, or costs too much, you create an unhappy customer even if you eventually and painfully deliver the integration.
The good news is that with low contrast from customer to customer, you (or your provider) can get really good at the specific kind of integration your customers require. This paves the way to expertise in delivering the specific kind of high-complexity integrations that are needed. You/they can build specialization.
Generally, using a moderate-to-high sophistication iPaaS (integration platform-as-a-sevice) to deploy these kinds of integrations is recommended. They allow you to simplify the labor required to get the integration deployed (configuration, not code). They also typically have templating features so you can rubber stamp the parts of the integration that are common to all customers.
Example: eCommerce-ERP Integration
When integrating an eCommerce website to an ERP, the majority of the requirements are the same every time: products/inventory out to the eCommerce site, orders into the ERP, shipping/tracking details back out to eCommerce.
The basics are the same and the market is consolidated around a small number of software vendors (less than a dozen eCommerce vendors dominate the market). However, the basic requirements between a relatively small number of systems is 80% of requirements. The last 20% is where these projects go off the rails.
The detailed, merchant-specific requirements are where all the complexity lives. You will thrive or struggle in that 20%.
Low Complexity, High Contrast
You frequently see low complexity, high contrast requirements in software products that are either hubs of business requirements and/or hubs of software ecosystems.
For the former, think about few (maybe one) product that serves as the nerve center for a business. An ERP/accounting system or a CRM are good examples. Almost every other technology the business uses ideally integrates into this system, which serves as the master of most data and where most people do their jobs.
For the latter, think about the software products that have their own gravity. They have developed ecosystems of system integrators, resellers, and partner ISVs who deploy solutions on their product.
Both of these types of products typically require many different integrations to different types of other products. If your software is of this category, offering many integrations allows you to check as many boxes on your prospect’s RFP as possible. It generally reduces sales friction.
But, there’s a challenge to contend with here!
If you are a software vendor in this category, you must constantly balance depth and breadth. The more sophisticated you make each integration, the more time you spend not building others, and vice versa. You also have to keep a close eye on supporting more and more integrations as you expand. Costs can get out of control.
There are two ways to handle this category of integration requirements.
You could build these integrations yourself (into your product). However, unlike building low complexity/low contrast integrations, in this category, you should be building integration into your engineering team as a core discipline. To be successful here, you need to be serious about it in terms of focus, effort, and funding.
You could also use/partner with a lighter-weight iPaaS (think Zapier). These tend not to have the ability to handle highly sophisticated requirements. They are in the “number of connectors” game. They present a message of “connect anything to anything”. Being one of those things gives your customer an easy path toward a successful integration.
Go the custom route if you think you can and should build integration as a core engineering discipline. Go the lightweight iPaaS route if can’t or you have reason not to do that. There are sometimes reasons to consider both routes, as well.
Example: Salesforce
Salesforce is a juggernaut in the digital experience ecosystem. In many industries, it’s just assumed that you use Salesforce for you CRM, unless otherwise specified. As such, almost every technology that would benefit from CRM integration, has an integration to Salesforce.
Salesforce wants it this way. They deployed an ecosystem that allows a large amount of integrations to different products, even if the mean level of sophistication is relatively low. This positions Salesforce as an ecosystem hub.
High Complexity, High Contrast
As much as we’d love to productize or simplify all integration requirements, the reality is that it isn’t always possible. The final category of integration requirements are those that are high complexity and that vary significantly from customer to customer.
With these integrations, it’s best to use an expert. These will require significant requirements analysis and technical execution for every project. Each one is its own unique animal. As a software vendor, this probably isn’t your business. You really don’t want to be spending capital building out this “expert-level” discipline.
You’ll want to look for system integration partners who you can refer to your customers for accommodating customer needs. Look for the following:
- Deep understanding of APIs and web services–old and new protocols
- Strong DevOps and cloud computing skillset
- Experience leveraging at least one enterprise iPaaS and/or ESB (enterprise service bus) platform
- Multi-discipline engineering team (multiple languages, architectures, etc.)
- Savvy at understanding requirements and translating them to technical solutions
You’re only going to pull this off with customers that are big enough to afford expert consulting and project delivery. If your product is $300/month and it’ll cost your customers $100k to address their integration concerns, either you are severely under priced or you need to rethink your integration approach.
Example: Integration to Bespoke or Enterprise Products
In the enterprise, you see a lot of technology deployments that are fully bespoke software products. You also see deployments of enterprise platforms that require heavy customization, so while they are built on commercial products, they are still highly unique to the customer.
It’s hard to address integrations to these types of products with any regularity or repeatability. Enterprise culture also tends to demand unique project structures, demands, and means of addressing requirements.
Bottom line: the enterprise is just a whole other beast.
Choosing The Right Approach
In reality, the lines between which approach is right for you are not so clear. You’ll likely fall somewhere in between at least two of these. The devil is in the details.
Use this framework as a way to think about and discuss your customers’ integration requirements to help guide your integration decisions. Simply avoiding egregious misalignments and identifying easy wins will get you most of the way there.
Then once you land on an approach, always look at how things are changing around you. Your decisions will evolve over time.
