How to stop your IT system from becoming outdated, obsolete and mouldy

If there is one thing that IT systems do very well it’s become outdated in record double-quick time. This is a fact; IT systems become obsolete faster than you can say Jack Robinson.

The world around us is constantly changing. Your IT system needs to be changed at the same pace or faster. If we do not keep up, the system becomes less useful, outdated, obsolete and in a sense, moldy.

IT systems do not usually become completely obsolete overnight in one fell swoop; normally an IT system gets progressively worse in terms of obsolescence. You can look at it as if it were an upside-down pyramid in that when the pyramid has become big enough it overturns and the system crashes.

A sustainable IT system is easy, cost-effective and predictable to change. With that in mind, here are 12 tips to help you prevent mold in the IT system, that is, to help you in keeping your IT system from becoming obsolete.

1. Just say no personal dependence

Discourage personal dependence. Minimise the risk of “Brian’s system” where the person who set the system up knows most about it and everyone else is completely ignorant. If Brian quits, goes on a long holiday or gets run over by a bus, it becomes difficult or impossible to maintain the system. This is definitely an undesirable state of affairs for all involved.

2. Balance the system

Do your best to strike a good balance between building systems that support everything and building many specialized systems. This is not easy, but keeping it mind will truly help.

Balance between building systems that support everything and building many specialized systems

3. Think on multiple levels

Think of several factors when the system is built. For example, it is not good enough that the system is easy to use if it is completely impossible to administer.

4. Avoid firefighting.

Avoid firefighting like the plague. If long-term planning is absent when changing the system, it will not be possible to have the system for the long term either.

5. Just say no (again)

Dare to say no. Instead of nodding assent continuously, stop, fix and test thoroughly.

6. Avoid technical debt

Poorly planned and badly implemented system changes will increase the so-called technical debt. Technical debt is a metaphor referring to the contingent consequences of poor or evolving software architecture and software development within a codebase. The debt can be thought of as ‘work that needs to be done before a particular job can be considered complete’. As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. The other required, but uncompleted changes, are considered debt that must be paid at some point in the future. Technical debt needs to be managed after the deadline, for example after deployment.

READ MORE about Change Management – Change Management During Maintenance

7. Structure your changes

Why should you structure your changes? Because when dealing with more structured changes there will be more time left for other things. A good way of documenting changes is to use a tool with excellent features for handling changes, such as ReQtest .

Always structure your changes.

8. Deliver more frequently.

It’s not a good idea to wait to deliver the system until the system is complete. Chances for feedback decrease if there are fewer releases. Experiences get lost and there will be more patches and thus more expensive systems. So, deliver more frequently and increase the opportunities to give and receive timely feedback.

9. Plan Long Term

A long-term plan for the system is important. What processes should the system support, whose needs must be met, which are the needs? Set up a maintenance plan and/or a product roadmap that shows what the system will accomplish over time.

10. Invest in automated tests

Today’s technology allows to automate much of the tedious regression testing. Without automated tests, chances are that you do not dare to change the system because a change makes everything needs to be tested again. Lack of automated testing easily leads to passivation and then no changes are made.

11. Evaluate

Evaluate the technology every year and update regularly. Who is responsible for driving the upgrade of technology? Business or IT? Business representatives do not drive technology upgrade requests; they must be made by the part of the maintenance team that has IT skills. If upgrades are regularly postponed, the system will become neglected and in the end will have to be replaced. Replacing a system is expensive and consumes much resources.

12. Discard

Learn to let go and discard the old code. Old code complicates maintenance. A good versioning tool makes it much easier to clean.