Back to news & views

Maximum value from a mixed software economy

Three ways to get COTS packages and custom-built products to work together

The question of buy vs. build has been asked many times. There are benefits to both Configurable Off The Shelf (COTS) and custom-built products. There are many articles out there on how to make this choice (see Forbes, Gartner etc.). The prevailing wisdom is ‘build’ if software can provide competitive advantage and ‘buy’ if it is common functionality available in the market place.

With these principles most organisations will end up with a ‘mixed software economy’ made up of COTS and custom products. The challenge many organisations face is not whether to buy or build but how to get ‘bought’ and ‘built’ software to work together effectively i.e. how to maximise value in this mixed software economy. This isn’t just about the technology, as ever it is a combination of the people, process and product.

Often COTS and custom software are seen as conflicting ideologies; they are considered as externally sourced vs. internally nurtured, Waterfall vs. Agile, ‘Big Bang’ vs. incremental roll-out. Some of these clichés hold true but they can be seen as complimentary rather than conflicting approaches. Organisations should consider how to get both approaches to work together, even when focusing on the implementation of one particular product. The next sections contain a few ideas on how to make this work.

Let’s start with sourcing.  When buying COTS, organisations should think how to integrate it with custom applications. Flexible, functionally rich and easy to use APIs are critical. During the procurement phase, why not test the API?  Give the agile developers a few days, system access and a burndown chart of desired integrations with the COTS product. See how far they get. This could be done with one product or to compare APIs of multiple products.  Not only will it produce a strong analysis of the ease of use of APIs, it will bind the developers into the selection decision.

During development of a custom product consider how the integration with COTS products can be simplified. Those with strong APIs (as a result of a good assessment during sourcing) should be easier to use but they may not be accessible. Standing up development environments for (or connection to) your COTS products will mean agile developers can experiment and bring the technologies closer. Including the COTS product experts in daily stand-ups will bring the teams closer together and foster teamwork and innovation.

When it comes to QA and release management, automation will help to get COTS and custom developments to work effectively together. Automated build scripts, functional and non-functional test suites can work across the two product types. Getting QA teams together to think about common testing and automation can not only improve consistency of product releases, it can save money through sharing tools and resources.

The above are a few examples of how organisations can bring the parts of their mixed software economy together. In extreme cases, different departments within a single organisation can have separate approaches on buy vs. build but the principles hold true. These departments can be brought closer and the more effectively they work together, the more value they will gain from their software regardless of how it is built.