The bugbear of being Back Office

The recent hoohah over the WannaDecrypt / WannaCry ransomware debacle, and the subsequent shamefaced admittance from a number of institutions that they have not been maintaining and /or future-proofing their systems properly, has once again brought one of my personal ‘bafflements’ into sharp focus.

My background in the IT space has most often been supporting the backroom admin functions. You know? The un-sexy necessities of any large-scale organisation; systems which pay the employees or suppliers, which keep records, that calculate tax, book leave or track the never-ending annual appraisal cycles. These are systems that frequently have to run regression-based Waterfall methodologies due to heavy customisation and monolithic architecture. The ones that look longingly at DevOps Agile approaches, sigh melodramatically, and then pragmatically just get on with the job. Giving credit where it is due, some companies are slowly, slowly! moving towards modernising these unwieldy applications as an inability to migrate these type of customised services into the Cloud highlights some pretty deep cost inefficiencies.

Maintenance of these type of older systems is easily brushed under the carpet; ‘we haven’t been hacked so far, why should we feel any urgency now?’ Or in some cases it is not brushed under the carpet and it is scoped, but then it has to ‘wait’ for a suitable opportunity to test it before it can be put live.

I am not taking a Systems Thinking course for nothing though – so I thought it would be an interesting thought experiment to step away from my own perspectives and look at some others.

In the private sector, budgets are shaped by the bottom line – what is going to MAKE the business money. The company has a finite amount of money to invest and it wants to do so with the biggest return it can get. In this environment, back office systems that handle internal data and files are inevitably going to be low on the pecking order when up against the survival image of the business in its sector. Customer systems are going to get a lot of TLC because of the absolute necessity of a good customer experience. I find this a bit of a catch 22 situation – you need the customers to make the money, but how good will the customer experience be if all of your staff disappear due to a payroll error.

In the public sector the problem is bigger than just back office systems; the constant squeeze from government leaves everyone competing for a piece of an ever shrinking pie. (An ever shrinking pie that seems to pay some pretty incredible sums of money to contractors for their IT systems as well I might add. I have been witness to a few public sector ‘contracts’ and colour me utterly bamboozled by the procurement process!) Taking the beleaguered NHS Trusts as a prime example, choosing between replacing some antiquated systems that seem to be working okay, or paying to keep the lights on and patients moving through their appointments appears to be a no-brainer (especially in view of the ever tightening hospital waiting list targets). But this approach just defers the problem. And defers it. And defers it. And then something goes …ka-boom!  Also – who on earth would hack a hospital… amiright?

Still – the kerfuffle will bring some much needed attention to these darkened corners. No bad thing. However the cynic in me asks – will we learn from it? Or after the buzz has died down, will those bad habits start creeping back in? I would be interested in hearing some other opinions and thoughts about this mess – feel free to post if you feel so inclined.

Technical Debt – having a vision of what should be

Technical debt is a problem for most IT divisions that have been running for a while. The drive for quick delivery to market forces projects to run as fast as possible in order to meet business expectations – and unless a company is very disciplined from the start- this can sometimes come at a cost of shortcuts or ‘acceptable’ defects being introduced.

On a project by project basis this probably isn’t a huge problem – so long as you are within risk tolerance, some projects can go live with known defects or workarounds – but when you start thinking that a lot of major enterprises will be running hundreds of potential projects in a year, and some applications may be several years old, you could see how this could add up if a strategy isn’t in place to handle it.

One of the sanest ways to combat this is to move to a methodology that bakes quality into the process; agile methodologies are very keen on this. However for those companies that are transitioning to agile methodologies this means they could be facing a mountain of technical debt before they even start.

Where do you even start with something like that?

I read a very entertaining blog by Jergen Moons which makes some solid suggestions about tangible ways to approach handling technical code debt. The biggest take away I got from it is to start small and make consolidated targeted improvements as part of a long term vision that works alongside future development. I recommend having a look.