In contrast to failing IT environments being replaced by businesses, it is typically the quiet failing of current IT environments that results in replacement of the environment as the cost of continuing to maintain it exceeds the cost of change and no-one has noticed the crossover point for change. The signals are there long before the event but they tend to be presented singly as unusual incidents rather than as a developing pattern.
Here’s a way to interpret the various signals to help work out whether your organisation’s IT needs replacement or not.
Recurring incidents are a capacity signal, not a bad luck signal
A single outage is an event, repeated outages occurring 3 times in a quarter indicates your environment is no longer able to cope with the loads placed upon it. As with anything, tracking incidents by root cause as opposed to simply by ticket volume helps to paint a more accurate picture.
Repeating incidents with no fix yet applied is a clear sign that there are underlying constraints that have not yet been addressed. Look for workarounds like ‘restarted the service’ or ‘cleared the queue again’. These accumulate and create new dependencies that are not documented.
What to measure instead of uptime
- Mean time between failures for each business-critical system, tracked quarterly rather than annually
- Percentage of incidents closed with a permanent fix versus a temporary workaround
- Number of distinct systems involved in a typical incident, which rises as environments become tangled
- Hours of staff time lost per incident, calculated from headcount affected rather than downtime duration
Slow systems usually point to architecture, not hardware
When a user complains about something being too slow the typical reaction is to throw more processing power at the problem. Often that processing power is concentrated on the desktop of the user. Rarely is the bottleneck actually on the desktop. More often than not it is in a database that has grown beyond the ability of its indexing to handle it, or it is a network link that has grown with the team but not in the correct ratio, or it is an application that was written to run on servers of a previous generation.
Unless you are completely certain, it is best to start to diagnose problems before spending too much money. To begin to understand your problems, track where you actually spend time when dealing with a slow transaction and whether the problem is to do with the number of users or the volume of data.
A quick triage matrix
| Symptom | Likely cause | Appropriate response |
| Slow for everyone, all day | Undersized link or shared server resource | Capacity review of network and host |
| Slow only at peak times | Concurrency limit in the application tier | Load testing, then scaling or licensing change |
| Slow for one team only | Local network segment or specific application | Segment-level monitoring before any purchase |
| Gradually worse over months | Data growth outpacing design | Archiving strategy and index review |
Security gaps widen as environments age
An organic IT environment typically contains many old user accounts, firewall rules, and integrations into old systems. Each of these old systems usually carries some form of risk which most people are not even aware exists.
As systems age and no longer can receive current patches, you will be forced into using compensating controls. But these controls become exceptions that are rarely reviewed. So it’s worth determining how many of your security exceptions were created over 12 months or more ago by people that still work at the business.
Signs your controls have fallen behind the environment
- Multi-factor authentication is applied to some systems but cannot be applied to legacy ones
- Offboarding requires manual removal from more than three separate directories
- Backup testing happens less often than quarterly, or restoration time has never been measured against actual recovery expectations
- Nobody can produce a current inventory of internet-facing services within a working day
Productivity loss is the cost that never appears on the IT budget
Much poorly performing IT work is covertly re-worked around existing problems in ways that are not recognised in financial reporting but are nonetheless real in terms of volume of work undertaken. So it is important to gather solid evidence of such impacts before seeking funding for a replacement or significant upgrade of an IT system.
Before you even have to think about a business case look to quantify the increases in the time taken to complete routine tasks as well as the workarounds currently undertaken to manage within an underperforming IT system. If that evidence points to a structural problem rather than a one-off fault, it is worth asking a specialist in IT support Sydney to review the findings with you before any budget is committed. Often it is these additional tasks and workarounds that in themselves justify significant investment to improve the current IT infrastructure.
Deciding between repair, replacement and outside help
It’s not all trouble though! So long as a problem is of a configuration type, poor monitoring, or un-documented changes for example, it can often be sorted out within the current IT environment. But true capacity problems and unsupported software need to be replaced!
On the other hand, if all you have is a pattern of recurring technical problems then it is generally better to engage an expert to provide ongoing IT Support for your Sydney business. The real value of such support is in the ongoing root cause analysis of technical problems over months rather than fixing some underlying structural problem in a one off project.
The question to settle first
Most importantly, before you spend a dollar, establish whether you can get your team to explain why they keep having the same incidents again and again. If the answer is no, then spend that dollar on a set of diagnostic tools first. Everything else will depend on them.
