A really good end product is often the result of the perfect mix of ingredients – not only when baking a cake, but also in software development.
Software is the central ingredient of digitization. Innovative products and services are no longer conceivable without it. Competitiveness crucially depends on the ability to create software-intensive products and services quickly and with highest quality. In software development, one therefore has to face the make-or-buy decision.
Both versions have their pros and cons in terms of cost, quality, time, resources and risks. I will not go into further detail concerning these aspects, as they have already been discussed in abundance. My focus is a different one: the increasing mix of buy and make = BAKE! In the past, people far too often used to think in a black and white scheme in the context of software development:
Make = in-house software development
Buy = standard software (if necessary with relatively expensive adjustment possibility)
Due to technological progress, many different possibilities to meet individual requirements are now available. The BAKE approach reduces both buy-risks such as complete dependence, loss of know-how and incompatibilities of standard software as well as make-risks such as underrated development and maintenance effort and costs and a long time-to-market. At the same time, access to specialized knowledge offers the opportunity of greater innovation dynamics.
In addition to those positive aspects, there are also challenges: These include the coordination of multiple contracts and rights as well as technology differences. Furthermore, the above-mentioned risk of dependence cannot be completely eliminated but only reduced. In my view however, the benefits of the BAKE approach predominate in most cases – especially with regard to the time-to-market. Let us take a look at the two BAKE options:
1 In-house development in interaction with (existing) third-party solutions
Many well-known examples come from automotive development. The depth of production of the individual manufacturers is relatively low, many items are being purchased from specialists. This approach is also possible with respect to software development. Third party software components can easily be integrated – be it components coming from the development of other business units or solutions from the open source environment or from specialized software companies. Depending on the company’s focus and value added, dedicated components can also be reverse-engineered or purchased (= backward integration) as a follow-up. This can replace the “buy-component”.
Also in the travel industry – which is my primary sector of activity – many examples of in-house development in interaction with (existing) third party solutions exist. Among others in the context of national and international travel booking solutions, where diverse content interfaces for e.g. flight, hotel and car rental are required for development. At present, they are not available in a standardized form. As a consequence, any required interface must be connected and maintained individually. The API supplier therefore has to attend to many customers directly. As a result, the market relies on API specialists who bundle content and offer it in a standardized form. As you can see in the diagram, this simplifies not only the integration and communication during and after development, but also reduces complexity. Furthermore, this approach offers greater independence – a change or the addition of an interface can easily be done.
Interface integration and management without and with an API specialist:
2 Custom-tailored third party solution in connection with own components
If off-the-shelf solutions are no longer sufficient and in-house development does not make sense, new, individual solutions are needed. What was once unthinkable is now possible thanks to today’s technology: customized software for the price of standard software, based on reusable components. Often, we call this a modular system or white labeling: One selects the desired blocks, optionally builds further blocks or brings in own blocks. These can be integrated via e.g. a service manager or interfaces. Thus, a customized software is created in conjunction with own know-how. Specialized knowledge, which serves as a means of differentiation on the market, remains to 100 percent in the hands of the company.
Another practical example from the travel industry: The standard business travel booking system of a world-wide financial institution had reached its limits. With the standard set, the reproduction of travel rules became more and more difficult and time-consuming individual programming was necessary. The objective therefore was to implement software which could be supported and developed independently and without much effort. The choice fell on the PASS Online Booking Tool, which was developed as a flexible modular system: in addition to its component-based software development, it is primarily characterized by an integrated rules engine (open source). This enables customers – regardless of the manufacturer – to incorporate know-how and place it at the disposal of internal and external users.
My recipe advice
So what is the perfect buy-or-make mix? Unfortunately, it is not possible to give a standard answer because it depends on many factors. Factors such as time-to-market, overall costs and savings (project and support time), technological aspects (non-functional requirements) and risks. Furthermore, internal factors (strategy, know-how and resources) as well as external conditions (solution availability and contractual conditions) play a role. I therefore recommend the following procedure:
Good luck with baking or rather with software development!
Picture credit: Shutterstock