Written by Bruce Davidson on Wednesday 2 December 2015
Recently we were helping a senior executive understand the state of the numerous change programmes in the UK platform industry. Many of these projects are taking longer than firms originally anticipated, and there was a lively debate in the office about the causes on different projects. In addition to the usual reasons for poor project success in financial services one aspect stood out: the use of highly-configurable software (either as software or as part of a business process outsourcing (BPO) deal) as the basis for delivery. This ought to be a boon for delivering projects, so why has it been causing problems?
In some cases firms have underestimated just how powerful the configuration options are. As with any system the more options you have, the more complex setting up and testing the system will be. If your strength lies in distribution and customer relationships and you just want to provide a platform with your brand and voice and a charging structure to suit your customers, a fully configurable system is probably overkill. White-labelling an existing platform is likely to be a better choice and get you to market far faster.
Many executives see a big distinction between “code” (written in some “complicated” language like C++ or Java; they expect this to be a “hard” problem and slow) and “configuration” (unclear how it’s written but magically “easy” and “fast”). Many vendors have been keen to play to this view. However if the system is sufficiently configurable that it can cover annuities and investment business held under CASS rules via configuration, is there really that much of a difference? When you can “configure” the underlying transaction types used by the system to do its accounting, in reality you are coding. Developers will immediately recognise this for what it is, coding in a “domain specific language”. That should be more efficient than using a lower-level language like C#, but it doesn’t magically make the problem “easy” or “fast”.
The complex nature of the systems means that many configuration items have impacts on others; selecting immediate clearance of direct debits won’t work if you haven’t configured appropriate transactions to account for the necessary pre-funding. Rarely are these dependencies made clear and if your configuration tool is a spreadsheet it’s unlikely to be much help: neither detecting these issues automatically, nor making it easy for the team to spot the issues. Ensuring that the release of this configuration to different environments is controlled as carefully as releases of the “code” is vital, and often overlooked or poorly understood.
Of course not all configuration is so complex. Many vendors have gone to great lengths to allow the configuration typically used day-to-day to be controlled directly by clients. Project teams understand that the annual bps charge or adding a new fund is something they could change tomorrow if they needed to without too much recourse the vendor. However what if they want to tier the charge, or change the tiers – is that still in their power? Can we add this ETF as a “fund”? The boundary between “BAU” configuration, and what is really domain-specific-coding is often unclear to project teams. Ensuring that you understand what skills and lead-times are required to configure different aspects of the system is critical, not only to preparing a realistic project plan but also to avoiding unrealistic expectations on the ability to flex your proposition in the future.
With the platform market in the UK surely approaching saturation and a likely phase of expansion into Europe, the configurability of systems will be tested like never before. Having a solid architectural understanding of all the configuration available to you and a software-and-configuration development process that maximises your project productivity will be crucial to success in this market.