On Being Directive

Or why you should avoid customizations in IT projects

As you may or may not know, I have been working in fintech for some time now and the experience has been interesting to say the least. I have learnt a trick or two on the way, nothing too disruptive, but still, interesting ideas, concepts or insights on the industry, which I like to share on my blog.

Like directivity for instance, or why and how would you insist on your client to adopt your software solution as it is rather than adapting it to their liking. Or why you would be ill inspired to pave the project road with customizations. Here’s my take on it.

Directivity, the opium of the silent crowd

For most people, opening a spreadsheet or a text editor on their personal laptop is as close as they will ever get to an IT implementation project. Such software is very specific from a features perspective, for instance text editing, and extremely general purpose from a user perspective, as the targeted users are pretty much anyone and everyone.

For them, the software experience is directive by essence, and they seldom see it as a constraint. They have no say in any feature of the software at hand and they can only use it as intended by the software vendor. A bit like the weather: it can only be suffered, and there is no one to complain to, or at least no one who would do something about it.

On the other hand, an integrated financial software platform is quite the opposite. It boasts a wide array of features allowing to represent hundreds of business processes and is intended for highly specialized and somewhat opiniated users working in a very specific (and lucrative) industry, who will have their say on the software features and expect the vendor to comply.

Vendors would try to limit the endless customization requests by packaging business processes in their software instead of selling it as a toolkit, and try to standardize some of the main business processes required by a financial institution in the platform.

The tug o’ war of directivity versus customization

If I used an example based on one business area to illustrate the situation, I would be a vendor pitching an advanced accounting software for instance to prospective clients. Let us assume that it is based on a spreadsheet editor with extremely powerful functions and features. If I sell it as it comes, a blank spreadsheet with a lot of potential but no packaging, the implementation is doomed to fail.

What I should sell instead, is a spreadsheet where I would have configured viable accounting features, like sums, filters, account representation, balance computation, conditional formatting, currencies formatting, lookup tables for reporting, basic macros, etc., which the client can use “out of the box” as we say in the field, with nearly no customizations required. Or so might you think.

In reality, for a long time, vendors could not be directive despite their packaging efforts, and were never successful in limiting customization requests. Packaging was only seen as an accelerator for implementation projects. In fact, customization had been the norm in fintech for decades, especially ever since the deregulation of financial markets in the 1980s, as each institution had its way of doing things and its own view on financial markets and wanted these factored in the software they were to implement.

Many players in the field had and still have their own IT departments who would produce tailor made software instead of leveraging products from a specialized vendor. Vendors were hence compelled to accept a high level of customization in their packaging when they had one, if they wanted to retain customers, gain market share, and keep the pace of an ever-changing industry.

The customization trend kept gaining momentum until the early to mid-2010s, when banking regulations started to tighten up as a response to the sub-prime crisis of 2008, and development frameworks centered around agility and continuous integration started to become the norm in the software industry.

Directivity and continuous integration

One of the principles of continuous integration for example, is that every new feature added in a software code comes with a unitary test, which is added to a battery of automated tests. These tests are launched automatically with every new feature reaching the software code, to ensures that no regressions are introduced to the existing code base.

The same principle applies for customizations required by clients during an implementation project. Given the complexity of the solutions, any customization carries a regression risk, which can only be mitigated by adding extra test cases to the test base. Hence, customizations in a project are treated as code and automatically tested for regressions when first added to the solution, and at every subsequent change of the code base. This means that the test base can rapidly expand if too many customizations are introduced, and the cost of testing might become prohibitive for the institution.

On the other hand, vendors develop, package, and increment their solutions based on the principles of continuous integration cited above: Every increment to the solution, whether a new feature or a bug correction, comes with a unitary test, and correlates with an increment of the test package.

The heavy non-regression testing is hence already factored in the packaged solution produced by the vendor factory: should the clients accept some directivity and opt to implement it without customizations, they would be virtually immune from regressions on the packaging scope, at no to marginal increase of their own test packages.

Adopt it, don’t adapt it

As a consequence, directivity in an implementation project can be a tremendous accelerator to the delivery of high-quality features and secures a smoother support of the platform and cheaper upgrades to higher versions.

Some players in the industry might see directivity as a way to cut budget and secure timelines, but in my opinion, and based on my experience, the incentive for adopting a packaged solution rather than adapting it should be quality first and foremost.

So dear clients, adopt, don’t adapt. You will find that in the long run, this pragmatic attitude pays off in more ways than meets the eye.