Maintenance of IT Systems – Is It Necessary And Why?

24 March 2021
maintenance of it systems

“Genesis of everything”

Originally, IT systems were difficult, unknown and literally cosmically expensive, making them inaccessible and reserved only for large recipients such as giant financial institutions or leading world powers investing in defense and energy related systems.

With the development of IT, systems became more accessible and began to streamline the key and labor-intensive processes in the company, increasing the efficiency of business processes and the comfort of work. Nowadays, more and more enterprises use dedicated software to secure comprehensively all the processes taking place in the company, such as Management, HR and payroll, Finance and accounting, Production, Logistics, Sales or Service. We meet more and more often with the statement that “Company” is “System”. It is well known that the guarantee of business survival is its continuous development and improvement of solutions, and thus also the continuous and adequate development of IT systems, combined with maintenance work carried out regularly on all components of the production environment.

1. What does the term “System Maintenance” mean in IT projects?

IT systems maintenance – it is basically modifications of software after it has been delivered in order to correct errors, to improve performance or other properties of IT systems.

The key problems of software maintenance in IT systems include both management and technical problems. Important management issues are: adjusting to customer priorities, appropriate system maintenance personnel, cost estimation.

The key technical issues are limited understanding, impact analysis, testing, measuring system maintainability, and infrastructure maintenance.

maintenance activities

2. What is the maintenance of IT systems?

The maintenance of the system is mainly the handling of service requests:

  • Support for helpdesk requests (Issues / Tickets) in systems supporting IT project management (the most popular are JIRA, Redmine).
  • Diagnostics, confirmation and identification of problems reported by the client. Solving problems or supervising the implementation of reports.
  • Contact with the client and other members of the teams involved in the implementation of the request. Planning the implementation of applications, determining the date and manner of implementation.

Service activities, or maintenance activities related to the maintenance of IT systems production environments:

Care of the system environment (Application Servers)
  • Resource utilization analysis. Cleaning up disk space from unnecessary files.
  • System and utility software update.
  • Removal of failures and solving problems related to IT infrastructure.
  • Monitoring of resources and key business processes.
  • Analysis of the current configuration and implementation of good practices to improve efficiency and safety.
Maintaining the database environment
  • Database administration
  • Creating and testing backups
  • Monitoring of database processes.
  • Cost analysis of queries and their optimization (e.g SQL Tuning).
  • Analysis of disk space usage (e.g. reduction of the declared space for different tablespaces).

Repair and development activities:

  • Supervision, preparation and implementation of Updates of the domain system.
  • Updates related to the release of new extensions (Features).
  • Bug fix updates (FiX and HotFix).
  • Service work aimed at implementing changes, bug fixes or reconfiguration.
  • Adjusting the functionality of the software to new needs (Features).
  • Interviewing the client in order to collect the data needed to analyze both development and remedial problems.
  • Performing manual and automatic tests related to changes, both repair and new functionalities. Depending on the commitment and the model adopted, it may be the implementation of all types of tests performed in the software production process, i.e. unit tests (development tests), most often in terms of automation, if implemented. Traditionally, integration, system, smoke and acceptance tests.

Provision of Support services – is an indispensable element of a good maintenance contract:

  • Providing substantive support for it system users (functionality).
  • Technical support provided by specialists with experience and dedicated skills, carrying out IT consultations aimed at helping with maintenance, solving problems requiring specialist IT knowledge (e.g. UNIX Systems Administration, Windows Server, solving network problems, Database Administration).
  • Support and implementation of new solutions based on dedicated IT tools and applications.
  • Integration with products and maintenance of dedicated solutions from other suppliers.
  • Supervision and support over the implementation of System Updates when they are implemented by the Employer.
  • Customer needs analysis and advice on choosing the right tool.
  • Implementation of technical and substantive consultations related to various fields.
  • Conducting training on new and current functionalities of IT Systems.
  • Creation and development of documentation.
  • Service visits at the customer’s premises.
Sample service request life cycle
Sample service request life cycle

3. Why does the project require a maintenance contract?

“Why are there errors on the system that has been tested and received?”

Every system needs a “certain” amount of time from the moment of implementation to start working optimally. The length of this period depends mainly on the complexity of the systems and their field, and is commonly referred to as “annealing“. Even the best-written and tested program is endowed with this feature, as the development and testing environment never fully reflects the target production environment, and in some cases, given the scale and data type, it is even impossible. Generally speaking, the system has been adapted during the production phase to a different environment than the one it will be operating in in the future.

“This is History …”

Historically, in 1969, Meir M. Lehman formulated the concept of maintenance and evolution of applications included in IT systems. The next twenty years of research in this area led to the formulation of Lehman’s law (Lehman 1997), which defines that the maintenance of it systems is in fact an evolutionary development of the application and that decisions related to the maintenance of systems are supported by understanding what is happening in the system (and software) over the time. Lehman showed that systems evolve. As they evolve, it becomes more and more complex, unless some steps are taken, such as refactoring the code to reduce its complexity.

Two men are working on computer bugs

4. Maintenance vs. Development

Problems related to the topic of maintaining IT systems basically have two main sources. The first are those resulting from normal use, as well as those resulting from numerous activities aimed at changing, repairing and reconfiguring the system. All these activities naturally lead to a slow degradation of the IT system and other dependent elements included in the production environment. (Here is an example: incorrectly entered or corrupted data, archived logs from the operation of applications working as part of the solution, old unnecessary files and other “garbage” left by users).

The second source is the experience resulting from the evolution of the solution implemented in the applications, forced by the progress and changes of external factors. The software must constantly change in order to be able to adapt to new requirements.

Due to the very dynamic progress, which is inevitable and most noticeable in the IT area, the adaptation of the system to the new requirements should not be delayed too long, as negligence may lead to situations where it is not profitable to adapt the solution, because the refactoring range is so huge, that it is cheaper to rebuild the system. Creating new software does not mean buying a new car with a quick and easy changeover.

The cost of producing, implementing and maintaining a new solution based on old data often has to be migrated to a new model. Data migration can turn out to be very problematic and risky. In addition, you need to take into account the implementation of a new solution, staff training, training for customers and often also the purchase of new equipment, and sometimes even the employment of specialists to operate it. An example would be an old database that is no longer supported by the manufacturer. This creates security problems and the inability to integrate with newer systems.

After updating the database to a newer or completely different version of a different manufacturer, it turns out that, in addition to problems with data migration, it becomes necessary to purchase new network devices, workstations and servers with new operating systems that are no longer compatible with the technologies originally used in the production process the application, the base of which was the most important part. Suddenly, after a few years of neglect in the area of ​​system development and maintenance, the company faces a precipice, has to spend very large amounts of money at once, bear the risk of data migration, and sometimes even data loss. Comprehensive implementation of a huge number of changes that may have a very negative impact on the work of the staff for a long time due to the limited availability of key system functionalities, often reduces productivity, management effectiveness and financial results.

Another example will be a sales system designed to serve the customers of a certain manufacturing company. In 2001, the company was located in a barrack and employed 10 people. It seemed that the number of contractors would never exceed 10,000 and cloud computing and interacting with third-party sales, advertising and billing platforms seemed like some kind of sci-fi.

During the 20 years of the company’s development, the functional requirements have changed several times. Without continuous and systematic development and adaptation, the system would very quickly become obsolete and significantly slow down or even prevent further business development.

“It’s not a bug, it’s a feature”

It is believed that maintaining IT systems only involves debugging the system. However, one study shows that the majority, i.e. more than 80% of the maintenance expenditure, is for all non-repair work (Pigosky 1997). This feeling is perpetuated by users submitting problem reports, which in fact turn out to be extensions of the functionality of IT systems (jargon: “it’s not a bug, it’s a feature”).

It's not a bug, it's a feature


5. What is an SLA and what are its conditions?

SLA (Service Level Agreement) – is an agreement with a guaranteed level of service provision. It is a special document that specifies the minimum level at which the supplier will provide certain services to the client. For the service recipient, the SLA should be the most important element of the agreement with the provider.

What should the SLA include?

A well-structured service level agreement should include the following:

  • Availability level required – Ensuring the level of availability is typically defined as a percentage of the service uptime over a year. The scope should be adapted to the real needs of the client resulting from the analysis of business processes in a given organization.
  • The way and form of reporting problems with the operation of the service – for example, specific e-mail addresses or telephone numbers that should be used to contact the supplier in emergency situations. There should also be hours here when you can report problems. For example, if your company does not work at night, perhaps the range from 8 to 6 pm is enough.
  • Reaction time and problem resolution – this is the determination of the time after which the supplier is obliged to deal with the reported problem and how long he has to solve it. Bearing in mind the cost per minute of unavailability, the shorter this time, the better and the lower the losses for the company. Also note that this is the time maximum – usually the provider will try to fix the failure as quickly as possible.
    In justified cases, there may be exceptions, usually they concern the so-called force majeure.
  • The process of monitoring and reporting the service level – that is, the method of supervising the functioning of the service, collecting statistics, which allows access to statistics through dedicated applications supporting the management process, recording work within the organization.
  • Failure to meet the terms of the contract – if the supplier fails to meet the requirements set by the SLA, he will bear the consequences. These may include the customer’s right to terminate the contract or receive compensation for losses incurred as a result of the unavailability of the service. This is your insurance policy in the event that the Contractor exposes the Employer to losses through his negligence or loose approach to the concept of “customer service”.

4 levels of SLA


Łukasz Bargiel
Łukasz Bargiel
IT Systems Maintenance Specialist New technologies, history and military enthusiast.
Read my other articles

logo stopka
Copyright ©2024, Evertop Sp. z o.o. | Privacy policy
scroll to top