When we undertake a Systems Health Check, it’s usually because the client has concerns about their system. Concerns take many shapes, such as:
- What is the quality of the implementation?
- Is the source code right for the system?
- Will the system scale?
- Is the system implemented securely?
- Is the system implemented following industry best practice and so able to be supported and maintained?
- The age of the system raises concerns about how to proceed
Financial underinvestment in systems is common and poor performance is impactful in so many ways, that getting a systems health check is imperative and when done, will produce a roadmap that will put you back in control.
So what’s covered in a Systems Health Check?
This review systematically covers:
- Overview of existing architecture
- Overview of application’s main functionality
- Assessment of the state of the system and its code base
Following the review, recommendations are made to improve the quality of the system that will support the business in the future. These are broken up into:
- Suggestions for short-term actions – actions that we strongly recommend are addressed immediately to mitigate risks in the short term
- Suggestions for medium-term actions – actions that can be achieved soon to either bring a system back in line with best practice or to address a looming issue
- Suggestions for long-term actions – actions that aren’t required for immediate resolution but address longer-term goals for the organisation, preparing the system for long-term supportability
The short-term actions will make immediate improvements, work will be done to enable the users to see continuous improvement with few negative effects.
A Rough Order of Magnitude (ROM) estimates for the work is provided at this point.
You can see that based on a few days’ work, a comprehensive report and a costed out plan of modernisation, will be at your disposal. The continued problems that could be range from performance, extensibility, and scalability to meet the business’ needs don’t need to be endured any longer, they can be eradicated and a far more efficient, user-friendly, modern system take its place.
OK, that’s the theory, but in reality, what can I expect to see covered in a Systems Health Check?
We recently did a Systems Health Check for a nationwide company who had a monolithic large-sized system that had been in use for ten years. However, it had grown in such complexity that it was neither scalable or flexible enough to properly support the needs of the business.
Aside from expanding its functionality, it had been under-invested in. But as it was written in well-known technologies such as .NET Framework, SQL Server and Angular, technologies that are vendor supported and have roadmaps going forward years, it meant that the system wasn’t going to be limited by a core technology problem or availability of developer knowledge in the industry. It could all be used in the re-writes.
We discovered, what its users had most likely known for quite some time, that the performance in its current form was poor, mostly driven by the structure of the database and the complexity of the stored procedures. A database server cannot scale effectively when also running large swathes of business logic.
The structure of the code base, that had 35 different solutions for the one monolithic application made it hard to navigate and modify the code, e.g., performing code clean-up or large refactorings. The mechanism used to split up the functionality of the system wasn’t common practice within the developer community, a barrier for new developers coming into the company.
We made suggestions to improve the quality of the system and enable it to support the business in the future. We provided Rough Order of Magnitude (ROM) estimates for that work, to allow the company to understand the level of effort required.
Proposed actions to improve the system were split into short-term actions that made immediate improvements, medium-term actions to start working on the core technical debt, and long-term actions that focus on the wider problematic areas. We firmly advocate not doing these all at once, but recommending that they are incorporated into a roadmap for the system that includes user-facing improvements and enhancements. This means that users continue to see improvements without having to wait a long period of time.