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.

Is Agile failing the Insurance Industry? Let’s talk about a Product Development Framework!

A lot of organizations are struggling when choosing a project management approach for their legacy transformation project. Agile has been widely advertised as the “one fits all solution” over the last decade, but is this really the case?

Once you as an organisation have decided that a modernisation of the legacy platform is no longer possible and you are launching a legacy transformation project, we first have to establish that any transformation project has the current status of the system landscape as a starting point and an acceptable target area we want to transition to. To get from the current status of our IT platform to our desired target status we can only move in one general direction.

Figure 1 - Target Status

There are two main project management methodologies we can utilize to manage a legacy transformation project in your organisation (and on top of this a sheer endless number of ways to set up hybrid approaches).

Waterfall methodology

The waterfall methodology starts with a meticulous planning phase, where the necessary activities are specified and signed by all parties. The different development phases (Plan, Design, Implement, Test, Release) are processed sequentially with the full scope of the project. After the implementation phase is completed, the testing phase is used to verify if the specifications are met by the implementations.

For projects, where the test phase establishes that the defined and signed specification deviates from the reality of how a company operates, a new target status has to be established and the process has to be repeated to get over the "actual finishing line".

Figure 2 - Waterfall Approach

In short, the waterfall methodology is an approach where all activities have to be specified in detail first, which ensures the architectural integrity and quality of the implementation (if the project is executed with enough know-how on board). Naturally, the more complex a matter, the more complex the task of specifying all activities becomes.

Agile methodology

The agile methodology takes a different approach. There is no overall planning or specification of the target status created when starting with the implementation. Instead, user stories (general descriptions of a feature) and acceptance criteria for them are defined and grouped into epics as a basis for the project. The user stories are then processed in small packages in so-called sprints. At the end of every sprint, feedback is collected from the stakeholders and the next sprint is planned. From the collected feedback, new details or even new user stories and epics can emerge. Graphically depicted the project is starting to move in a direction and gradually “correcting the course” to land at the desired target status.

Figure 3 - Agile Approach

The idea behind the agile approach is that if it is not possible or reasonable to define and estimate the goals in detail upfront, we are trying to achieve an unknown goal with a lot of stakeholder involvement and by iteratively getting closer to it. As soon as all user stories are processed and no new ones are evolving from the stakeholder feedback the project is completed.

In short, the agile methodology is a flexible approach with tight stakeholder involvement and produces a result fast, but with no inherent way of ensuring architectural integrity and quality with a detailed upfront global design.

Implementation Phases - Similar, but different

“According to how it is depicted in some sources, the agile- and waterfall methodology are ‘completely different modi operandi that have nothing to do with each other', but if you take a closer look the only major differences are the amount of scope and the iteration frequency.” - (Kaiss, 2022, p. 141)

With the two graphically very different representations from Figure 2 and Figure 3 above, how dare I say they are similar but just utilise a different frequency? Figure 3 is depicting the aggregated status level of the agile approach. When we are having a look at the individual tasks it becomes clear why this is the case.

Figure 4 - Implementation Phases Agile vs. Waterfall

As illustrated in Figure 4, each user story is processed in the same way (Plan, Design, Implement, Test, Release) as the full scope in a waterfall approach. With every implemented user story the aggregated overall status is iteratively moving closer to a not defined, but still existent, target status.

Figure 5 - Agile Approach Detail

Soley the difference in frequency is the reason for the very different characteristics of the two different variants.

Agile: The pieces of the puzzle are created individually and with only experience-based awareness of other future pieces and the bigger picture.

Waterfall: The full picture is part of the design phase and then divided into small pieces to reach the target in the implementation process.

With insights into the two variants and knowledge of IT systems and IT implementations in general, we are able to draw a few conclusions for the planned transformation project.

Architectural integrity, quality and maintenance

Most of the current theorising about which option to choose is quite one-dimensional. When the differences between agile and waterfall are being discussed, the focus is mostly on the project itself and the time it takes to reach “a goal”. Equally important aspects of your insurance platform, like the quality and maintainability of the produced result, are often completely neglected and not addressed in the discussion.

In the recent past, regulatory authorities like the eiopa also become aware of these factors and have been introducing regulations towards the quality and maintainability of insurance platforms.

“Undertakings should develop and implement a process governing the acquisition, development and maintenance of ICT systems in order to ensure the confidentiality, integrity, availability of the data to be processed are comprehensibly secured and the defined protection requirements are met.” - (European Insurance and Occupational Pensions Authority, 2020)

On top of this, a challenge you as an insurer inherently face during any transformation project is improving the maintenance effort and operational use of the insurance platform. A survey about product development by the Society of Actuaries underlines this and states that even companies with a strong development process, are lacking steering possibilities in the downstream systems, which leads to a lot of maintenance effort there.

“We have a very strong implementation process. It is a large effort due to the large number of systems that get involved … a lot of downstream work …It’s really all in the upfront part that is more within our product development area that we can have more control over.” - (Purushotham, et al., 2017, p. 76)

The fact that the agile approach is not based on detailed specifications and a detailed architectural concept is a big issue for any legacy transformation project. You as an insurer want to introduce a modern (module-based) insurance platform with an insurance product framework. The steering of the whole insurance platform with static product information, and therefore your future time to market and product development costs, is completely dependent on the platform's architectural integrity and the integration of the core systems. Next to the product development process we also have to fulfil the regulatory reporting requirements which are also completely dependent on our enterprise- and system architecture.

Creating a detailed architectural vision and specification before the implementation starts ensures the architectural integrity of the system platform. During an agile implementation, similar to a case-by-case approach [1], we only consider partial aspects when designing our implementations, which makes it very hard to develop the underlying insurance product framework and in fact any framework.

When developing a framework functionality tight stakeholder interaction and short increments are cannot replace a vision and a detailed concept, since there is hardly anything to show and collect feedback upon during this stage of the implementation. With the bigger context being put aside and having a limited area of vision utilised in the design of the individual implementations, it is probable to produce a result that does not support all cross-platform-, quality-, maintainability-, etc. needs.

“With a ‘case by case’-approach we are creating a ‘historically grown system’ artificially.” - (Kaiss, 2022, p. 39)

“Dr. Chris Mattmann, Chief Technology and Innovation Officer (CTIO) at NASA Jet Propulsion Laboratory, told Forbes Advisor that “agile methodology is used more for IT companies, [companies] that fail fast and move fast, types of places where you can proceed in parallel in different phases.” (Hoory & Bottorff, 2022)

Due to this artificial creation of a "historically grown system" on the fast lane, there is a good chance to recreate issues similar to the ones existing in your legacy platform. We do not only want to create "any new insurance platform" fast, but we want your organisation to use "a well-designed platform" for developing your insurance products over the next decades and the systems have to comply with the regulations in the sector. Of course, the development costs of your IT systems and introducing the new platform as fast as possible are also factors to consider, but during the transformation phase, you are at least not competing with the same time pressure as you will be during the creation of new insurance products.

If your goal is to create a maintainable platform with a product-centric product development framework the waterfall approach fits these aspects a lot better. The better the initial concept the better the time to market and the lower the implementation costs when you are using the new platform!

With an agile approach, you either have to be prepared to rework significant portions of our platform in the later stages of the project or to accept architectural flaws, with the attached maintenance costs and slower product development process. Especially the second option might be tough to accept for the insurance platform you are going to use for your operation over the next decades.

“The organisation is exposed to operation-, maintenance-, and extension costs for a significantly longer period, than the initial transformation project. A slow product development process does not only generate additional costs during the maintenance and product development but also for the business departments and indirectly with losing sales to the competition due to the longer time to market.” - (Kaiss, 2022, p. 186)

Accuracy in defining the business needs

Another important aspect of choosing the right approach is the degree it is possible to accurately describe the business needs towards the IT platform [2] and the target area (Figure 6). The challenge here is to identify the tipping point, where the business requirements are too vague to plan and specify the whole project and the project is better off using an agile approach.

The positive sides of the waterfall methodology can only be utilised if we can properly define the underlying requirements. Describing how the legacy system is implemented is not enough, we need to understand the motivation and the purpose of the processes and functionalities. If we are not able to specify them for any given reason, a waterfall approach does not fit the purpose and we are better off working agile. The agile methodology starts to shine, as soon as the target is getting vague.

Conclusion

We have to abandon the idea that there is a “one size fits all” approach, even within a company. Just because an agile project worked fine when e.g. introducing a small customer portal, it does not mean that this is now also the best approach for a big legacy transformation project. Nor is it the case the other way around.

Figure 6 - Agile vs. Waterfall

Being aware of the different aspects of the two methodologies and their consequences is of enormous help when facing a decision. There are a few crucial factors that have to be considered:

• Implementation project size

• Confidence in defining the business needs correctly and exhaustive

• Skill level of the involved stakeholders – not using the legacy system, but for defining the underlying business needs

• Skill level of the enterprise architects – technological, technical and functional

• Skill level of the implementation teams – technical and functional

• Awareness of the regulatory requirements across the complete team (architecture, stakeholder and implementation team)

• Quality and time-to-market requirements towards the platform

Due to the differences in approach, the agile methodology is more suitable for projects where innovation is the driving factor and for developing prototypes. With big legacy transformation projects, especially in a sector as regulated as the insurance business, the waterfall methodology appears to be the better choice.

The German regulatory authority BaFin even specifies that:

“Significant changes in the IT systems as part of IT projects, their impact on the IT infrastructure, the organization and the associated IT processes have to be evaluated in advance as part of an analysis.” (Translated) - (Bundesanstalt für Finanzdienstleistungsaufsicht, 2022, p. 23)

Time will tell whether this makes the agile methodology obsolete in the German insurance sector, if hybrid approaches [3] are going to be used, or if an agile form of “evaluation and analysis” will be accepted by the BaFin.

As is so often the case one of the most important takeaways is not to use or do something “because everybody else is doing it”, but to actively analyse and decide which methodology suits the purpose and the organisation best.

A hybrid approach with three layers (Agile Waterfall Agile) appears to be a good start for the workshops and alignments with the customer.

1. Development of a prototype with an agile approach

2. A waterfall project setting up the platform and the insurance product framework

3. An agile approach again for

   1. additional features

   2. developing the product portfolio.

Notes

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” (especially chapters 1.1 IT System Lifecycle, 1.5 Insurance Product Lifecycle, 1.7 Insurance Product Framework, 1.13 Supervisory Measures and Standards, 2.4 Architecture Vision, 2.15 Agile vs. Waterfall and 5.1 Time to Market), or to reach out to me in the comments or via linked in.

Last but not least, agile is obviously not failing the insurance sector but it is an additional tool to tackle implementations. It has any right to be around for innovative implementation projects and prototypes, where no blueprints exist yet. Agile is just not the answer to every question and sets difficult parameters for a legacy transformation project. Or in other words: sorry for the clickbait :)

References

Kaiss, M., 2022. Replacing Core Insurance Systems. Vienna: s.n., ISBN 9798352709771

Purushotham, M. et al., 2017. Understanding the Product Development Process, s.l.: Society of Actuaries.

Bundesanstalt für Finanzdienstleistungsaufsicht, 2022. Versicherungsaufsichtliche Anforderungen an die IT (VAIT) - Rundschreiben 10/2018 in der Fassung vom 03.03.2022. s.l.:s.n.

European Insurance and Occupational Pensions Authority, 2020. Guidelines on information and communication technology security and governance. s.l.:s.n.

Hoory, L. & Bottorff, C., 2022. Forbes. [Online] Available at: https://www.forbes.com/advisor/business/agile-vs-waterfall-methodology/

[1] The case-by-case approach is implementing one insurance product after the other.

[2] Although we do not know how accurately we can describe the target at the beginning of a project, so we are in fact identifying our confidence in our ability to do so.

[3] E.g. SAP is using hybrid approaches.

1.2 Why do Insurers replace their Core Insurance Platform?

After establishing that IT systems have cycles, we now want to understand when the legacy systems reached their declination point. At this point, a modernization of our systems is no longer possible or economically sensible and the time for replacing the core insurance platform has arrived. The following factors indicate that your legacy platform needs replacing:icaigfactors

​Indicating factors	Category
Declining data quality	Cost and Risk
IT platform is the bottleneck during the product development process	Cost and Risk
Business needs can no longer be met	Cost and Risk
​Supervisory measures can no longer be met	Cost and Risk
Legacy systems architecture prevents a modernization · Blocking new technologies/requirements · Initial architecture did not foresee new requirements · Patchwork of previous modernizations hard to maintain	Cost and Risk
Maintenance becoming too expensive · Big effort to create new insurance products/product generations · Hard to find people with the skill set to maintain your IT systems	Cost
Modernization effort bigger than replacement effort	Cost
Performance issues	Risk
Security risks	Risk
Etc.

Table 1 - Indicating factors for replacing the Legacy Systems

Broken down into the underlying categories, this means your insurance platform has to be replaced when either running the operation with the platform becomes an operational risk or when keeping the platform becomes a financial risk.

Figure 2 - Costs and Risks for replacing the Legacy Systems

Analysing the various indicating factors, we can see that the overlap between the cost- and risk-related issues in your IT landscape are mostly to be found in the system architecture area (product development, business processes, time to market, etc.), leaving us with the conclusion that a significant amount of architecture work will be necessary in any case.

In fact, every factor identified in your legacy systems will have various impacts during the execution of the IT transformation. We have to take note of the present issues for our future project scheduling and planning. Architecture issues in the legacy systems will impact the effort for the architecture analysis and especially the cross-platform processes. Additionally, it creates a need for resolving them during the transformation and adapting the underlying business processes. Issues in the current system with data quality will impact the project during the abstraction process, the product definition, and will require further analysis and effort during the data migration process.

The necessary activities are specific for every company and making a generic statement of the needed analysis steps is impossible. The project teams who are responsible for the execution of the transformation have to draw the applicable conclusions and schedule the necessary tasks.