I’ve been a programmer and IT enthusiast for 30 years (since the zx spectrum) and concentrated on AI (neural nets & genetic algorithms) at University. My principle skills are concentrated on Enterprise and Solution Architecture and managing effective developer teams.
I enjoy the mix between technical and business aspects; how technology enables and how that (hopefully) improves profit/EBITDA & reduces cost-per-transaction, the impact upon staff and how to remediate go-live and handover, and risk identification and mitigation. My guiding principle is “Occams Razor” that simplicity is almost always the best option by reducing complexity, time to build, organisational stress and longer term costs.
Legacy to Future - Navigating unsupported apps and shadow IT projects into the light
We're often approached by companies struggling to find a way forwards. They've got old or unloved applications that are core to their business but nobody to support, develop or manage them. Too often other software teams tell the software is unfixable and the only sensible approach is a complete rewrite. Most of the time this is great for the developers and the wrong thing for the business.
We disagree and hopefully this article will help you navigate through the minefield.
All business decisions are based upon two things: risk and reward.
Firstly, the application isn't usually the issue - if it's been central to your business, your processes and fulfils your needs then the application is an asset - it's a codified expression of the business. Of course this doesn't mean that things can't be better or that processes can't be optimised but the application works.
Secondly, you need to factor the risk. Is the problem that the application language or operating system is old? Or that the main programmer is ill or nearing retirement (or in some cases retired and changing things as a favour!). Or purely that the application can't be amended to what you need it to do. Or that it's a security or compliance risk? Even if you don't have the source code (the programming code that's used to make the application) in some cases this can be "decompiled" so there's a limited version of the source code that could be used for the most emergency fixes. In all cases we use the question what would happen if this application failed? How about if it was irrecoverable?
Third, you need to decide what the future looks like. Is it viable to change staff and processes to a new application in a short period or does this need to be an extended timescale to allow the change to occur?
Finding a Plan
Our first advice is to look at the above and find the application a new home. There's a lot of organisations out there that can handle just about any legacy application. These range from RPG and Cobol programmers, through Delphi, Access/Excel/VBA and Visual Basic/COM projects, all the way to more recent but deprecated technologies on older versions of languages like .NET winforms, old PHP or java interfaces. When you do approach the company ensure they're not a single person though - you don't want to move to another single point of failure.
Then evaluate when you should extend the current application and when you should move to a new platform. When you do decide to move to a new platform ensure the provider can use the current application and read the source code so they can re-use all of that business knowledge baked into it.
Lastly, wherever possible, dual-run the project so some staff can use the legacy application while some staff use the new application. In this way you can measure ROI and KPIs while minimising risk (if the new application is missing something or breaks then you have a fallback position).
Building the New Application
Most applications are a product of their time. In the 90s and 2ks applications were largely "passive" as they awaited human input and didn't "help" the operator or suggest things. These days we expect all applications to be "active" and engage with us so consider how that could help.
For example a traditional stock management system would allow you to run a report to show stock disparities, however a modern one should actively look for issues and email the appropriate users to find out why plus escalate that to managers if it isn't remedied in a certain period. The coding work for the example isn't much larger but vastly increases the productivity of the system and stock management as a whole.
We find the golden rule for rebuilding is to start by asking what the application was trying to solve rather than how it solved that problem. Then working from there by pretending the application is another person and in that way we can illuminate some of the "active" features it should have.
Once the new application is working as expected then you can wind down support of the legacy application.
Managing Legacy Data
It's always tempting to retain a legacy application for compliance purposes (be that taxation or legal requirements or for previous data) however we've found this to be problematic as the legacy application will require supporting for longer and it inevitably has issues as soon as it's needed.
Our advice is to get the data out into a format you can re-use but not necessarily load it into the new application.
One thing to consider if you want to use the data for analysis in future is whether the data can be reshaped and used with tools such as PowerBI. In that way you can easily access information without needing the old application.
It's an old adage of the computer business but it is still true: applications cost more over their lifetime than they did to develop.
We may be biased but we've seen too many clients ask us to help when they've developed an application using "the placement student" or "the clever lady in the corner who taught herself" or the "we just hired a contractor to build it for us". Support and maintenance are critical to your future as they ensure the application keeps pace with your business needs, is upgraded and secured and, most importantly, doesn't become a legacy or a bottleneck to your business.
Hopefully this has been helpful and provides some useful food for thought.
If you need anything or want to discuss the items above then please get in touch.
We're Honestly Here to Help!
Get in Touch
Got questions? We're always happy to (at least) try and help. Give us a call, email, tweet, FB post or just shout if you have questions.
Code Wizards worked with us a number of initiatives including enhancing our Giving Voucher proposition and fleshing out our Giving Street concept. They provide a good blend of both business and technology expertise. We are grateful for their contribution to TheGivingMachine allowing us to improve our services and enhance our social impactRichard Morris, Founder and CEO TheGivingMachine
Code Wizards are a pleasure to work with.Richard Corps, Serial Entrepreneur and Augmented Reality Expert
We've challenged their team to integrate our cutting edge AI, AR and VR solutions and always come up trumps.
I love their approach and help on strategy.
Working In Partnership
We're up for (almost) anything.
Our partner network is continuing to grow with like-minded companies that can add value to our mutual client offering. If you would like to learn more about how we can grow together get in touch.