To buy or to build? A version of this current dilemma has been with us for decades but what is its history and relevance to making decisions today?
During the birth and formative years of IT this was not a debate. Despite companies purchasing buildings, fleets of vehicles, stationery and computers rather than building their own, when it came to software a build culture became the norm. It was a “new” industry and business were keen to build software themselves with the view “our business is unique and we know it best”.
Time moved on and all the Cobol and Assembler programmers retired or died out leaving large organisations, especially (but not exclusively) banks, with huge sets of code that ran their business but that was so “delicate” and misunderstood (undocumented) that organisations would go on to avoid change at all costs.
This lack of efficiency would go on to be the birth of “the software industry” where firms created “off the shelf” software that could be bought and implemented with relative ease. It started with Accounting and HR software but slowly spread to all areas of business applications.
This “freedom from the IT backlog” meant that all sorts of departments and sub-departments went and sourced software to meet their needs. As this was business driven, the concept of IT architecture was seldom thought about and integration rarely enforced. This accelerated with the birth of internet deployed applications and later SaaS where internal IT did not need to be involved in deployment at all.
One of the flaws of the “our business is different” belief stems from companies’ heavy customisation of “off the shelf” software purchased (ask anyone who has spent a career implementing a CRM for a global company). This has two downsides:
1. It is costly and time consuming to implement
2. It becomes so bespoke over time that it suffers from all the issues that development of in-house applications do.
So, if we roll forward to today, we have a landscape in which most major organisations have some of, or all the above. The two relatively new components in this heady mix are:
1. A Transformation Group
2. A Mobile App.
In some places the Transformation Group has become the new version of the old IT Group, often with a consolidated IT agenda as opposed to a particular business agenda. Departments compete with others to get higher up in the Transformation Queue which means everything is viewed with a Pan-Organisation lens such that individual business units often have their immediate concerns and requirements overlooked or de-prioritised.
The Mobile App group has started to have a similar, but maybe more dramatic impact, because most of a business’s customers want to engage digitally via the Mobile App. Departments are queuing up (sometimes literally) to have their functionality delivered via the Mobile App. The Mobile App Group today is essentially what the IT Group of old was – a de-facto bottleneck to rapid deployment of new business functionality for its various units.
So, what are the lessons for you in the Build vs Buy debate today? There are a number that are important.
1. If you build everything you will fall behind your competitors and lose the huge advantage of “fail fast” and “adjust” that you have with bought applications. Buy it now and if you build a better version later, that’s fine since you can just decommission what you have bought.
2. If you buy everything with no strategy you will spend all your time and money building bespoke interfaces between systems.
3. You need to be able to integrate bought functionality with existing applications and delivery vehicles. Your Mobile App can be the initiator of all Customer Onboarding or Services without the Mobile App team having to build that functionality. But if all functionality is only in the Mobile App how do you cater for other channels?
4. Select application providers both for their specific application expertise but also for the provision of common “Platform” capability. Use similar, if not the same, inputs for common processes across your organisation. Consider it as the common reusable building blocks for many processes.
5. Strive for a reasonable balance. Of course, all functionality should be modular and API callable (in the same way as you put new tires on your car) but take this to its extreme you will lose the benefits of the “bought” functionality because you have become a full time “fixer” of parts constructed with thousands of pieces of bought software.
I’d be interested in your view on this topic?
Article written by Frank McCarthy, Business Development Director at Vizolution.