The RSPA Niche & Startup ISV Community helps software developer executives meet and network with fellow RSPA ISV members in a vendor-neutral setting. To join or sponsor the RSPA Niche & Startup ISV Community, email Membership@GoRSPA.org.

By: RSPA Niche & Startup ISV Community

It’s commonly understood that a single software can’t handle every aspect of a solution. Consequently, software vendors must prioritize seamless integration to avoid islands of data. During a recent RSPA Niche and Startup ISV Community meeting, ISVs explored integration paths then shared 10 critical factors for integration decision-making. Here are the key discussion insights:

When we look at the need for integrated systems, there’s really four basic options: 

1. The first one is eventually in time if we feel like the functionality represented by the third-party system is core to a large portion of our customers, we actually plan to include that capability within our product roadmap, and in some cases that takes away for the integration need altogether. 
2. The second option is that we develop natively an integration to that third-party system, and that kind of signifies that we recognize that there’s a need for that third party capability, but we don’t see it as a core part of our product. 
3. The third option is we look to a third-party software developer integrator. This would be a company that is known for system integration and productization of system-to-system mapping. 
4. The fourth option is allowing our partners and supporting them in the effort to create customer-specific integrations. 

• If you want to go a little bit further, there’s probably a fifth option which is providing resources for customers to do it themselves. We have some larger customers that have development capabilities. 

10 factors to consider when determining if an integration should be pursued: 

1. Size of customer– Depending on the size of the customer, can they do it on their own? 
2. Functionality – If the functionality is beyond your core, it’s more likely you will need to do an integration. If you need that competitive advantage, you can’t wait for your own folks to develop that functionality. 
3. Support– You have to determine the level of support you will need to provide as well as the level of support your VARs will need to provide. 
4. Current integrations / customer needs– Understand what other integrations the customer currently has that you will need to navigate. 
5. User experience – If that third-party solution requires a totally different workflow and a totally different user experience (e.g. an application needs to be accessed and pops up in the middle of a customer transaction), that’s not a great customer user experience. 
6. Amount of effort to execute– It’s parallel to triaging support tickets and understanding how many customers is this likely to be impacting. 
7. Number of customers integration will impact
8. Amount of impact on customers affected – If it means their system is down and it creates a mission-critical impact, that also raises the priority. 
9. Opportunities to expand our market: will this unblock lost sales?– It becomes even more complicated to try to think about what a core product should do across segments and regions. If you want to be seriously considered in that market, you have to be able to support that product. 
10. Cost– If the third-party capability is very expensive, even though it’s superior in capability, we find that maybe 80% of the customers are balking at the additional cost. That might be another justification for us to develop it ourselves.