Legacy System - You're damned if ..... full stop

Within the past year or so, I have worked with an utterly shameful technology. It was initially marketed in the early 90’s as a CRM, the vendor was consumed by a multinational competitor and its flagship product promptly discontinued (the organisation was consumed for its client base, not its product, and its clients were offered an upgrade path to the consumers product). One of the Unique Selling Points (USP) of the technology was an IDE of sorts that enabled the developer to add controls to a form, and attach coded business logic that would be executed when the user performs some UI action, clicking on an OK button for example.  The minds eye view of this technology – think Oracle Forms 4, but much much muuuuuuuch worse. Of course by todays technology standards, this is a laughable USP, and a 2-tier forms technology with a UI and a database is far from anything special.

Now imagine that there is a multibillion Euro organisation still using this technology in 2017/18, with business critical components being developed using this technology on a daily basis. Is this legacy technology a strategic risk to the business, or any sort of risk for that matter?

No and No is the answer, or perhaps No and Yes, or Yes and No, or Yes and Yes (that’s 4 permutations in the punnet, unlike the Rumsfeld set that contains only 3), but whatever is the answer, they are still damned. On the face of it there appear two primary risks.

• The primary risk is that the IT development technology is not supported by a vendor. The technology isn’t even commercially available, and this has been the case for just shy of 25 years. For this organisation, this key risk was mitigated however; this organisation purchased the source-code for this product outright, and more recent in-house modification cycles have resulted in it a) being ported from 16bit to 32bit x86 architecture for execution on modern versions of Windows, and b) to enable some UI components to be written in early versions of .NET. If I am permitted to reword these couple of sentences, this organisation now has its own bespoke development environment and programming language for in-house software development; it is the vendor of the IT development technology, the sole world-wide user of this technology, and further it develops new business software on top of this technology to meet its specific business needs. This organisation isn’t a software house – software is just a core enabler for its business. The approach, although one of big business lethargy and budget constraints rather than a long-term strategic plan, also has the side effect of risk reduction; the entire technology stack is owned by this organisation.
• In my view the primary secondary risk is that the development environment and dependencies are old, they are just not fun to work with, there us no user community for technical support, and there is no expertise pool for recruitment; few developers will exist that have this mid 90’s technology on their CV’s, and of those that do wouldn’t own up to it nor want to use the technology again. Furthermore if one of the cited reasons for internal staff attrition is high because of this technology, how can BAU software developers be attracted to and retained by this company, other than by paying over the odds.

At some point, this organisation will be forced to stop kicking the can down the road and have to replace this legacy technology with something more modern, performant, and that has a less costly SDLC and staff attrition overhead. This will not be today unfortunately. At the moment they are damned (or perhaps doomed); competitors are eating into their traditional market share, new software features to meet changing business requirements, bug fixes and so on are only implemented with speed because of a hoard of unproductive contract developers (and they are certainly not unproductive because of technical ability or nous, but because of tooling – it should not take 2mins to check in changes for a single source code file; some source code is stored in a database in binary, there are concurrency issues with more than one developer modifying a single object at any one time, and there isn’t even the ability to use a diff tool so there is no change history auditing etc – this all causes immense frustration, and more). Furthermore system testing involves dedicated testers bashing keyboards; there is not a single automated test in the underlying application. Of course this organisation may be damned (or again perhaps doomed) if they change too. A recent and topical example of how to not do a migration from a legacy system to a new system is TSB.

Given low technical risk, I doubt this organisation will change and will retain this legacy system for at least another decade. The system is too big and unwieldy to be easily swapped out for something modern and maintainable, and the costs and technical migration path are fraught with danger. The same will be true in a decade too, and the cost to change much higher, even if the replacement system were to be slowly phased in. When large companies merge or divest, like in the takeover of TSB by Lloyds, and then the divesture of Lloyds TSB into Lloyds and TSB, change occurs very rapidly. These activities are often when old systems are taken offline or decommissioned, or new systems rolled out, along with the bigger business architecture changes (and clearly the business case is strong). Perhaps this is what will happen with this organisation. I just do not know. I do know however that I am glad to only have worked with this technology only in passing; having the development technology on mv CV as a core technical skill would be akin to be unemployable as a contract software developer. For a contract software developer, this is not good.

— Published by Mike, 18:09:03 20 May 2018 (BST)