The challenge for IT
When planning the implementation of -related functionality and technicalities in core payment systems it needs to be kept in mind that technical implementation is often a process which takes several years to realise. Such processes are also greatly influenced by other changes in the market, like the roll-out of electronic invoicing, for example. To properly prepare such a mid or even long-term project, a sound roadmap outlining the successive process steps is required. This article focuses on the first step of such an implementation project aimed at upgrading an organisation's existing IT systems to comply with the schemes and standards. While implementation should lead to cost savings based on efficiency gains in the long term, it initially represents a substantial investment, both in IT terms and due to the change in organisational processes.
The goal is to minimise maintenance
Upgrading systems can be a hard task due to software complexity which accumulates over the years. There is a significant risk when adapting the software of legacy IT systems to accommodate that it will lead to high costs, defects in production, and possibly lower performance. It will be particularly important to continue with IT maintenance arrangements, which typically represent a significant annual and recurring cost factor. Maintenance support will ensure that IT systems are kept running in good order, defects are fixed and new business IT demands, based on the provision or use of new payment products and services, are met. The cost of these maintenance arrangements, however, should be minimised to provide the lowest cost solution in the long term when migrating to . The total maintenance cost over the full lifetime of an IT system typically amounts to 80% of the total expenditure for the system. Since is here to stay, it will pay to minimise the future maintenance costs of the systems that will touch.
implementation: continue the legacy or start from scratch?
With , any organisation required to adapt is at a crossroads; initially, a decision in principle must be made: (a) adapt the existing payment systems to support , or (b) acquire new systems for , either by (outsourced) development or procurement of a standard solution. In both scenarios implementation of will be a continuous process that spans several years. Therefore the technical quality of the solutions will play a key role in controlling the costs. In the following, the difference between the two scenarios will be illustrated by an estimated cost development of the implementations.
Scenario A: integration of in existing payment systems
The technical quality of existing payment IT systems determines whether they can be adapted cost-effectively to comply with . For illustrative purposes, this scenario assumes that 5,000 function points1 worth of software have to be developed. Many core payment systems have been in operation for many years. Functionally they perform well, each day processing a large volume of payments. Less visible is the condition of the software "under the hood" - also known as the technical quality - of these systems. Ongoing maintenance almost always leads to a decrease of technical quality when software is based on old, obsolete technology. Often the cost of maintenance, which is already high, increases with each year because of deteriorating maintainability. More and more effort is needed to make the required changes due to the resulting reduced productivity. In the event of further upgrades, low technical quality systems have an increased risk of defects being found in production, because they are harder to test and stabilise. Performance will be equally at risk, because low technical quality makes it harder to tune a system to meet performance requirements.
The integration of in existing payment IT systems will typically lead to lower initial development costs. However, there is a significant risk that maintenance costs will rise further due to the implementation of , if the existing systems are of poor technical quality. In many cases, the cumulative cost of maintenance will far exceed the initial cost of development.
Scenario B: acquisition of new payment systems for
The initial costs of building new systems are higher than upgrading a legacy system, estimated here at 10,000 function points worth of new software. The new systems will, however, be of higher technical quality as they are based on new technologies and have had the benefit of recent innovations in software development, such as continuous quality monitoring. These factors have a strong impact on future maintenance costs.
(click to enlarge)
How to make an informed decision on the appropriate implementation strategy
To make an informed choice between these scenarios requires assessment of the technical quality of the current payment systems in an objective and quantified way. Specifically, such an assessment should generate valid cost estimates for the different implementation scenarios based on system volume, technology, business domain and the level of technical quality. Models developed to project the evolution of maintenance costs demonstrate that already after two years, the cumulative costs for system maintenance are almost equal in both scenarios A and B. A few more years down the road, the cumulative costs for maintenance based on scenario B (new system) are lower than those expected to materialise under scenario A (upgrade of legacy systems). After ten years of maintenance, the total cumulative cost for the maintenance of system could be up to 10 million euro lower in scenario B.
Measuring the key cost factors
The actual technical state of an organisation's payment system is therefore an important factor when determining the appropriate strategy for IT adaptation to comply with the Schemes and standards. Availability of estimates on the development of maintenance costs based on an objective assessment of the legacy system's technical state, allows to make a careful cost-driven decision on the implementation of related infrastructure and functionality. Picking the right scenario can save millions of euros on maintenance costs in the future.
Magiel Bruntink and Zeeger Lubsen are Management Consultants at the Software Improvement Group, Amsterdam, the Netherlands.
Related articles in this issue:
Related articles in previous issue(s):
The big Picture. Dematerialisation of business processes - in payments and beyond ( Newsletter, Issue 5, January 2010)
1 A "function point" is a unit of measurement to express the amount of business functionality an information system provides to a user (Wikipedia). Function points are typically used to estimate the amount of effort needed to develop an information system.
If you would like to comment on this article, please identify yourself with your first and last name. Your name will appear next to your comment. Email addresses will not be published. Please note that by accessing or contributing to the discussion you agree to abide by the EPC website conditions of use.