Custom Software versus Standard Software

Introduction

There are a lot of articles and websites comparing standard software and custom/individual software, who are leaving the impression that they are comparing bad software of type A to good software of type B, depending on what they want to sell.

Standard software does not equal standard software, and custom software does not equal software. This article is trying to objectively highlight the characteristics of each approach and compare them, to give you a starting point for deciding which option suits your organisation best.

Definitions

Standard software - An IT system supplier provides customisable and extendable IT systems with standardised business processes, covering the internal-, legal-, and regulatory requirements of a sector, or for a cross-sector purpose.

Custom software - An individual IT solution developed by the consumer organisation, or an implementation partner, which is tailored to the organisation's existing business process and its legal-/regulatory requirements.

IT-System lifecycle and development approaches

To fully understand the differences between standard software and custom software we first need to understand the IT system lifecycle and how IT systems and platforms are developed.

While custom systems and platforms are tailored to the existing processes, this is only true if you implement your complete platform and all your products in a big-bang approach, with an aligned underlying architectural concept.

As soon as you are using a phased approach, or if you are establishing a single system for multiple different historically grown subsidiary companies, we are having a different situation at hand. Once the system architecture and the system processes of your custom software have been established, adding functionality for other subsidiaries or different products to your system will confront you additionally with the same challenges as introducing a standard platform would. You will have to adjust the products and the processes of the subsidiary companies to the established system processes, which will require a lot of change management.

Additional factors which can influence the challenges you are facing during the transformation project are the management approach you are utilising to develop your software. A fully agile management approach can bring out similar points of attention as a phased introduction of your platform.

Custom software characteristics

"Custom software to keep the business departments happy?"

When developing custom software your starting point is a "greenfiled", confronting you with a few decisions. First of all, either your organisation has to run the transformation project, or you have to find (an) implementation partner(s) to take up the responsibility for you.

Figure 1 - Custom Software Stages

Developing IT systems from scratch requires a lot of know-how in all areas of IT system- and software development. We have to define the used technology, the system process, the architectural vision, the system architecture, the integration of the platform, quality assurance measurements, the verification process (testing), etc.

All of these factors have to be handled by your organisation and the implementation partner(s), which might be quite difficult for the IT department of a "consumer organisation". The IT department's core competence (e.g. the IT department of an insurance organisation) is to maintain, update and run the current IT landscape. Sometimes this is ongoing for decades, without replacing the current legacy platform. Developing a new platform is a whole different endeavour.

The following table is listing the pros and cons of custom software, grouped by the different areas and stages of a transformation project.

Area	Pros	Cons
System Development	The integration of existing IT systems is relatively easy if taken into account in the architectural design from the beginning	The organisation is not used to implementing modern IT systems and managing the process A lot of know-how in all related areas is required: architectural design, product development framework implementation, MVC, patterns, specification, documentation, quality assurance, testing, etc. Big development effort, that is often underestimated
System-/Business Processes	​Initial development tailored to the organisation's business processes	Shift to using established system architecture after the initial implementation is often overlooked. This can lead to "bending the initial architecture" once different requirements come into play and attached to this the creation of unstable and hard-to-maintain IT systems Change management is not as present in customer projects - business processes that could use a change potentially overlooked
Features	Features can be tailored to the organisation's processes and needs	Features have to be developed from scratch
Testing/ Quality Assurance	Easier to define test cases and quality assurance measures, since the systems are tailored to the existing business processes	During the project: the responsibility of the customer/the implementation partner During the maintenance phase: the responsibility of the customer
Updates and Maintenance	No dependency on updates of software supplier	The systems have to be maintained by the IT department and the mandatory regulatory/legal updates have to be developed within the organisation All bugs have to be fixed by the IT department

Table 1 - Custom Software

Standard software characteristics

"No CFO ever got fired for introducing SAP?"

Contrary to custom software, introducing standard systems means that the business processes and the system architecture are already established.

Figure 2 - Standard Software Stages

On the flip side, this means the organisation or a potential implementation partner has to have a deep understanding of the standard system, to set up the system and utilise the processes correctly. When introducing standard systems it is of utmost importance to utilise the standard process and to maintain the architectural integrity of the IT platform. This is especially the case when enhancing parts of the platform with custom implementations, in the way intended by the software supplier.

The following table is listing the pros and cons of standard software, grouped by the different areas and stages of a transformation project.​

Area	Pros	Cons
System Development	Less development effort Less software development know-how required	Still often underestimated A deep understanding of the standard system and industry standards is required Potentially harder to integrate remaining "legacy systems" into the platform
System-/Business Processes	Change Management is part of the process	Processes not tailored to the company - standard processes have to be used Business processes have potentially been tailored to a "prototype customer" and not to the industry standards and regulations - depends on the quality of the system supplier
Features	Custom-developed features have to seamlessly integrate into the design of the standard architecture	Standard features have to be used
Testing/ Quality Assurance	Delivered standard functionality is tested by the software supplier before delivery. Less test and quality assurance effort is necessary Bugs and missing features found by other customers of the software supplier will also find their way to your organisation with a new release	Testing and quality assurance can be hard to perform in the beginning, considering that you are introducing new software for which the organisation has not built its know-how yet
Updates and Maintenance	Regulatory/legal updates and new releases provided by the software supplier Service contract with the system supplier for bugs in the standard functionality	Potentially change management is needed for new releases provided by the software supplier

Table 2 - Standard Software

Comparison

Comparing the two options, any good software of one type wins over bad software of the other type, but this is not the comparison we are trying to make. You will want to achieve the development of a good platform, no matter which approach you choose.

In the end, it all comes down to the preference of the organisation and how much responsibility and development effort you as a customer want to take up. If you want to have less development effort a standard system is the better choice, but on the flip side, this means that you will have to adjust your business processes to the existing system processes.

If you want your systems to be tailored to the already existing business process the customer-developed software approach is the better choice. The downside here is that there is a lot of development effort involved and that there will be hardly any modernisation of the existing processes taking place.

As always, it is of utmost importance to fully understand the different options, how software development works, how legacy transformation projects are set up, to lay out all facts and to involve all stakeholders when taking a decision.

This article is just a starting point and you will have to analyse the driving factors of your organisation. In such a short read it is impossible to cover all aspects and nuances of the discussion. If you are craving more details and insights feel free to check out my recent publication “Replacing Core Insurance Systems - Learning from the past to be prepared for the future”, or reach out to me in the comments or via linked in.