Integration vs. Out-of-the-box

I recently had a discussion on Twitter with a user who believed that products should always have all the features you want and integration is never the right approach. As you might guess, I'm not a big fan of "always" or "never". But it did get me thinking, when is integration the right solution?

When you might choose to integrate multiple software products

There are two primary benefits to integrating software products:

1. You can choose best-in-class solutions for each need you are trying to fill. Let's face it, you may see a shiny new software package that promises to replace your CRM system, your project management system, and your invoicing system, but you're probably not going to find a single software product that has a sophisticated lead management system that also has a robust invoicing system. If you want software that does it all, but does it all well, you're probably going to have to purchase multiple products.
2. If you are looking to integrate multiple disparate business processes into a single software product, implementing multiple systems separately at different times can be less daunting and less risky than implementing a giant system at once. No, you don't need to use all of the features of a gigantic system at once, but sometimes the pressure is there to get the most from your money and effort. Having multiple systems can relieve that pressure.

In summary, you probably would choose to integrate products when you have business-critical systems involved that have needs above and beyond what a simple do-it-all system can provide, or you want a lower-risk method to upgrade a large portion of outdated infrastructure.

When you might choose to purchase a single product

You may choose to purchase a single software product when you run into one of these two typical integration issues:

1. Multiple products from a single vendor that have integration points that come out-of-the-box. These types of integrations typically don't work as well as advertised and cause you to alter the way you'd use one or both products to get the integration to work. These problems can cause your team to lose enthusiasm for the project, if not for the project as a whole.
2. Multiple products from separate vendors that don't talk to each other, so your development team needs to build a bridge between each of the systems. These bridges can be time-consuming and costly to make, in no small part because the documentation for creating these bridges are almost always poor or out-of-date.

To avoid the possibility of missed expectations or costly maintenance, you may choose to purchase a single system to meet all of the needs of your company. You might also choose to utilize a single system for all of your needs if you want to simplify your vendor management.

Other considerations

Most companies I've worked for and contracted with have become dependent on strange idiosyncrasies within their business processes that don't truly provide value to the business as a whole. Purchasing a system that doesn't support these idiosyncrasies can be an impetus to change. You really should only be deviating from standard industry practices when this deviation gives you a strategic advantage of some sort. Otherwise you'll probably decrease costs and variability by adopting industry best practices as a standard.

When companies are trying to replace old systems with new ones, their instincts are to choose systems that have all of the functionality the old one provides, except with a few improvements in reliability, cost of maintenance, features, etc. The problem with that thinking is that companies will often think that they are dependent upon existing features that don't really provide value for the organization. So when you are trying to determine what your new system should do, try to be open-minded about which features you need. This will help prevent you from pursuing best-in-class systems and integrating them when a single system will do.

Beware of systems that claim to be extremely configurable/flexible. The right software for your business will force rogue employees from following their own process and can help guide new employees in forcing them to follow what is "supposed" to happen. The more flexible your software is, the less likely that it will be able to enforce your company-specific business workflows.

What does your existing infrastructure look like? If you are looking at a software system that has a feature you need, but has three you already have elsewhere, will you save money by getting rid of these other systems and moving the three business processes over to the new software product? Is the migration worth it?

Finally, you should ask yourself whether the systems should be integrated at all. I personally hate the idea of having the same information stored in multiple systems (such as customer information duplicated in the CRM system and the invoicing system), but sometimes the costs of integrating these disparate sources of information aren't worth the benefits gained from pulling from a single source.