4 minute read
Time was ticking away for the medical studies department at a top private research university.
Clinical researchers relied on the department’s web collaboration portal to house and share data from their studies of new medicines and medical treatments. And the application was just about to hit its 10-year anniversary – a dubious achievement in software.
The university’s IT department decreed that unless the aged system was modernized within six months to meet compliance, security, and a host of other IT standards, it would be disconnected from the university’s network.
The original developers, when contacted, announced they would no longer support the system. Their company had changed direction and was not interested in helping.
Our phone rang.
“Can your team bring our system into compliance before we get shut down?”
WARNING #1 – Do not trust any consultant who answers “Yes” to a question like this without first having conducted a formal analysis of your system and its environment. There are too many unknowns.
In this case, our analysis of the architecture could have stood as a study on obsolescence. Components were many versions out of date, approaching end-of-life, or harbored security vulnerabilities that alone warranted disconnecting the system from the broader network.
And then there was the source code, which tells the computer what to do. Chunks of it were old drafts. Other chunks were missing entirely. And much of the rest didn’t compile properly.
WARNING #2 – Beware the consequences of letting your systems age too long.
Eventually, you’ll have to catch up, at least to a recent version if not the latest. Why? It could be compliance issues, security threats, or declining performance. Ultimately it’s a simple question of continued viability.
As years pass without attention, the path between your critical system and a successful refresh becomes rough, potholes appear, then even the bridges fall away. The further behind you fall, the more difficult – and expensive – your upgrade process becomes.
WARNING #3 – Delaying modernization jeopardizes your system in the most dangerous way: it’s a slow, almost imperceptible burn that can damage beyond repair.
Years of inattention left this system’s database – containing all the department’s studies, reports, and other documentation – running on a server no longer supported by the vendor. Priceless data on the precipice.
Imagine storing your valuables inside a rusty treasure chest with a brittle key that could break, forever jamming the lock. That’s vulnerability.
WARNING #4 – Own your software. It’s your house. Software engineers are just the architects and builders. Make sure you always have an updated, detailed blueprint of your system, and perform routine inspections and maintenance.
This system was missing both its blueprint and many component parts. The only way to keep it running and address necessary upgrades would be to reconstruct it. We would have to take the application apart, deduce how it works, and fill in the blanks. Ultimately, the software would need a complete redesign.
“Can your team bring our system into compliance before we get shut down?”
Now, with a complete picture, we were able to answer the initial question.
“Yes.” We can defuse your ticking time bomb. We’ll start with the most urgent issue: prevent disconnection from the server. But the crisis isn’t resolved. The system still must travel a multi-step upgrade path to get where it needs to be.
Think this can’t happen to you? Beware!
Old system or new, best practices apply to everyone. Ask yourself:
- Can you put your hands on your system documentation?
- Is it complete? Is it current? Is it accurate?
- Are all the correct components present and accounted for?
- What happens if your developer leaves tomorrow?
- Are your servers being monitored, patched and refreshed?
- What is the first thing you’ll do if your system crashes?
Weak answers to these questions may kindle a fuse not easily snuffed out.
KABOOM!
