CC BY
21A Framework for Evaluating Legacy Systems - A Case Study
Slavimir Lj. VesiC1 and Dusko Lakovic2
1PUC "Belgrade Waterworks and Sewerage" 2 Ministry of the Interior of the Republic of Serbia
Article Information*
Research Article • UDC: 004.4:005.6 Volume: 20, Issue: 1, pages: 32-50 Received: February 15, 2023 • Accepted: March 5, 2023 https://doi.org/10.51738/Kpolisa2023.20.1r.32vl
Author Note
Slavimir Lj. Vesic https://orcid.org/0000-0003-2020-8418 Dusko Lakovic https://orcid.org/0000-00Q1-9984-9669 We have no known conflict of interest to disclose. Corresponding author: Slavimir Lj. Vesic E-mail: vesic.slavimir@gmail.com
*Cite (APA):
Vesic, S. Lj., & Lakovic, D. (2023). A framework for evaluating legacy systems - A case study. Kultura polisa, 20(1), 32-50. https://doi.org/10.51738/Kpolisa2023.20.1r.32vl
© 2023 by the authors. This article is an open-access article distributed under the ^ terms and conditions of the Creative Commons Attribution (CC BY) license
(https://creativecommons. org/licenses/by/4.0/).
Abstract
The phenomenon of legacy systems is very complex, insufficiently understood or viewed in isolation in theory and practice, leading to many failed modernization projects even with significant invested funds. In this paper, within the framework of a case study, the problems of legacy systems are observed and classified into appropriate perspectives. A framework for evaluating legacy systems is proposed, which aims to contribute to a better understanding of legacy systems and, thus, to the selection of a suitable modernization strategy for a specific system. A case study was conducted at PUC BWS, together with a value chain analysis. After that, research was carried out on certain city water supply systems in Serbia and the region, where respondents presented their views, as well as professional opinions on legacy systems. Based on the obtained results, it can be concluded that the proposed conceptual framework can serve as a tool through which it can be checked whether the system exhibits the characteristics of the legacy system.
Keywords: legacy systems, evaluation framework, software evolution, perspectives of legacy systems
A Framework for Evaluating Legacy Systems - A Case Study
With the development of the information system and putting it into use, the ageing process of the software begins as its inseparable part. Software ageing is inevitable (Parnas, 1994, p. 279), so maintenance is carried out to remove specific errors and improve performance. For the information system to be the best possible model of the real system, it needs to evolve, which is why its modifications of lesser or greater intensity should be carried out. Lehman pointed out this back in the 80s, classifying information systems in the class of E-systems, i.e. systems that change along with the environment (Pfleeger & Atlee, 2009, p. 538). At some point, it is necessary to implement changes of a more vigorous intensity than maintenance, better known as modernization, to restore the evolutionary ability of the information system (Seacord et al., 2003). When the information system can no longer adapt to changes, it is withdrawn from use, and its place is taken by a new system that begins its exploitation phase within the life cycle. Withdrawing and replacing an information system may seem relatively simple, as with most products, but the practice has shown that it is a much more complex problem. This problem has existed since the time of the first information systems and their commercial use up to the present day. It is embodied in the form of legacy information systems (from now on referred to as legacy systems).
In theory, there are many definitions of legacy systems, and in the most general terms, legacy systems are information systems with a reduced evolutionary capability. They were developed in the past, often in old or outdated technology, designed and implemented under the then methodological settings and development practices (Vesic, 2020, p. 668). There are certain differences in the concepts of the legacy system and legacy code, i.e. legacy software. The legacy system is more complex than the legacy software because it includes: people, expertise, hardware, data, business processes and approaches in software maintenance and development, emphasising the interaction of these elements (Brooke & Ramage, 2001, p. 3).
Many businesses still use legacy systems because they support critical business functions or business processes. IT managers are faced with a dilemma; on the one hand, they want to withdraw them from use because they inhibit the adoption of new and more efficient business models, while on the other hand, they are aware of the significant risks that this can bring due to their support to the core business. This is the reason why many companies choose to invest in
the maintenance of legacy systems constantly. Thus, in the example of the USA, based on publicly available research by the GAO (Government Accountability Office), the US government planned to spend over 90 billion dollars in 2019 on IT, with the participation in that budget being funds intended for the maintenance of 10 critical legacy system of federal agencies had a share of about 80% (United States Government Accountability Office, 2019, p. 1). At the same time, the practice has shown that even after significantly allocated funds for the modernization of legacy systems, there are many failed projects, with the funds invested in some of those projects exceeding billions of dollars (Ulrich & Newcomb, 2010, p. 5).
The vast diversity in the definition of legacy systems, especially between theoretical and practical research, indicates that this phenomenon was observed mainly in isolation and that the authors primarily focused on only one of their characteristics. The authors mainly focus on one of their characteristics. Other studies originating from practice have attempted to provide a more comprehensive view of legacy systems by looking at them through their perspectives (Alderson & Shah, 1999; Khadka et al., 2014).
This research is based on one such approach where the legacy system is viewed from several perspectives. As a result, a conceptual framework was proposed that can serve for a better understanding of legacy systems and their evaluation. With a better understanding of the problems that legacy systems face, a sound basis is formed for adopting suitable modernization strategies to preserve the built-in multidecade knowledge that these systems have and their importance for business. In this way, at the same time, the risks caused by choosing the wrong strategy are reduced.
Methodological Framework Problem Description
Significant financial resources allocated for the maintenance of legacy systems, a large number of different definitions of legacy systems, in theory, significant investments in the modernization of these systems and a large number of failed modernization projects, despite the significant investment of funds in practice, indicate that:
• The phenomenon of legacy information systems is highly complex
• Legacy systems are insufficiently or isolatedly understood in theory and practice
• That failed modernization projects are often the result of insufficient understanding of these systems and
• That the critical step towards successful modernization is their adequate understanding of the complex relationships between all their elements, as well as the factors of the complex and permanently changing environment
Description of the Case
The subject of the analysis, i.e. the case selected for this case study, is PUC "Belgrade Waterworks and Sewerage" (from now on, PUC BWS). It is a Belgrade public utility company engaged in water production and wastewater disposal services in the territory of the city of Belgrade. The company has over 2,500 employees, assigned to carry out activities by units: water system, sewage system, development, design and investments, business-technical support, economic-financial, personnel and general affairs, legal affairs and procurement affairs, safety and quality. The ICT sector carries out various activities related to developing, maintaining and integrating the existing information system and the complete information and communication infrastructure.
PUC BWS has a legacy business information system over 20 years old, written in the Progress ABL programming language, better known as Progress 4GL, and the Progress database. The legacy system mentioned above includes about 40 different modules and applications, the most important of which are: water invoicing, service invoicing, water meter records, warehouse and material management, customers and suppliers, procurement and procurement planning, payroll calculation, personnel records etc.
Connection of the Case Elements With the Problem and Deepening of the Problem
The legacy system of PUC BWS in practice has many problems that can be seen from the point of view of programmers, designers and architects of the system, as well as from the point of view of system users and from the point of view of managers of various departments, as well as from the point of view of top management that takes care of the realization vision, mission and goals of the company. By analyzing these problems in the case of PUC BWS and connecting them with different perspectives of legacy systems, as well as with a look into the future, a framework can be created that enables comprehensive
observation of legacy systems and their better understanding both in the present and in the future. In this way, it would be avoided that the modernization of the legacy system of PUC BWS would not be just one in a series of failed modernizations with significantly invested funds.
The Research Problem's Significance and the Suitability of the Research Method and the Subject of Analysis
Looking at the problems of legacy systems in PUC BWS can also help other companies from the same business domain with similar legacy systems. It is assumed that other public utility companies with a similar or lesser complexity of business, a more or less similar system could use the exposed way of observation and thereby support the modernization of their legacy system.
The case study, as a research method, can be used in exploratory, descriptive and explanatory research, and it is suitable because it can combine qualitative and quantitative research methods. It can provide new ways of understanding research problems not previously exposed in previous research and reveal new and important implications for practice.
For several reasons, PUC BWS is suitable as a subject of analysis (case). First of all, the company has a legacy information system that is over two decades old. In addition, the company is characterized by a variety of business processes, the complexity of which is more significant than in other smaller systems. In addition, the research author has been working for more than one decade in this company in the positions of programmer, designer and system architect. He learned many problems and specificities of that legacy system in practice through his work.
Scientific Significance of the Case Study
The case of PUC BWS will be helpful because it will be able to confirm the facts established so far or point out some new ones and new problems that arise in practice. In addition, it will make it possible to better understand the legacy system through an integral observation of the perspectives and the problems of the legacy systems that arise within them, compared to theoretical research that observes this phenomenon in isolation.
Overview of Existing Considerations (Research Background)
During the last three decades in the literature, there have been many
different definitions, descriptions, interpretations and viewpoints of what legacy systems are. They differ significantly from each other, so there is no single opinion on what this complex phenomenon includes.
The first group of authors, at the same time the largest, points to some of their features, shortcomings and problems that these systems have, often emphasizing their technological obsolescence, maintenance costs, difficult adaptability, etc., while some of them also recognize the importance of these systems have for the business. For example, the authors state that it is costly and difficult to maintain them, while specific business requirements cannot be met (Nassif & Mitchusson, 1993, p. 471). Bisbal indicates that these are systems with reduced possibilities of cooperation with other systems (Bisbal et al., 1997, p. 529). The author cites their obsolescence, high maintenance costs, poor documentation and technical support (Warren, 1999, p. 2). Somerville sees them as socio-technical systems developed in the past, which were created by the use of old or obsolete technology, and which include legacy hardware, legacy software, but also legacy processes and procedures, i.e. old ways of doing things, making them difficult to change because they rely on legacy software (Sommerville, 2016, p. 765). The authors point out that these systems are designed, implemented and installed in a radically different environment than the current IT strategy and that they do not support the current IT strategy (Mitleton-Kelly, 2006, p. 55)
The second group of authors, in relation to the first, examines the phenomenon of inherited systems in practice and tries to see them from several different perspectives; where in this way, they also see some of their "non-technical" aspects that are not emphasized in the first group (Alderson & Shah, 1999; Khadka et al., 2014). The authors look at legacy information systems from 4 perspectives: developmental, operational, organizational and strategic (Alderson & Shah, 1999, p. 1). The developmental perspective is the observation of the inherited system from the point of view of the people who develop it and later maintain that system. These are business analysts, designers, architects, programmers, testers, engineers who care for quality, etc. The operational perspective says that the system should provide adequate service, which users must recognize, whether related to the efficient implementation of operations or cooperation with other systems. The organizational perspective with which managers are connected should assess how the system affects business and whether and to what extent it supports business processes. The top management tries to do everything to fulfil the company's mission, vision and goals, so in this
sense, it makes decisions about undertaking certain strategic activities that should ensure this. Adopting new and more efficient business models when there is intense competition in the market may be conditioned by the application of new technologies, which legacy systems may not be able to support. The strategic perspective considers the costs of lost business opportunities caused by preventing the use of new technologies that the legacy system potentially cannot support.
The results of the research carried out by the authors showed that users value their systems very much and that in addition to the technical aspects, there are business and organizational factors that are very important, which is the opposite of the views of the first group of authors who focus exclusively on the technical aspects of legacy systems (Khadka et al., 2014, p. 36).
Observation of the Legacy System in the Case of PUC BWS
On the legacy PUC BWS system, the author observed various problems that arose in practice when working with this system, which can be classified into one of the four perspectives proposed by Alderson and Shah: developmental, operational, organizational and strategic (Alderson & Shah, 1999, pp. 1-2).
One of the many problems that appear is the reduced knowledge about the system because the system documentation does not exist or is not up-to-date. There is a relatively small number of employees in the mentioned system compared to the number of developed and maintained applications, so there was no time to create and update the necessary documentation. In addition, employees work as software generalists: they take requests from users, design the application, program the application, test its functionality, etc., because there is not a sufficient number of employees to enable the division of work. All this leads to the fact that the knowledge about the structure and behaviour of the system is reduced and that not a single person can understand the system completely and see it in its entirety. In addition, it is problematic that the knowledge is concentrated among the employees who work on that system and only in the part in which they work. An additional problem that arises in the absence of documentation is the slow transfer of knowledge between developers, especially when integration needs to be done.
The next problem is that the employees who worked on the system left the company, which on the one hand, led to an increase in the workload for the remaining developers. On the other hand, it led to the loss of very valuable domain
knowledge about the part of the system on which it was installed that the employee worked. This puts the company in a situation where it has to constantly invest resources in re-learning the system, what functionality that part of the system performs and how it is connected to other parts. The company hires new people, but the problem is that the new employees do not have enough knowledge and skills needed to maintain the system. New employees have mostly graduated from university, and in practice, they rarely have the knowledge to maintain older systems. The curriculum of their studies usually deals with object-oriented programming languages, while in the case of PUC BWS, they had to learn Progress 4GL, which is an older programming language and is not taught in colleges. In addition, very few educational programs in Serbia deal with topics such as legacy systems, software evolution, software maintenance, etc. They concentrate much more on new system development.
Due to the long-term maintenance of the system, over time, the initial architectural idea may be disturbed because the programmers are required to make changes in the existing software solution quickly. As a result, system design activities are carried out quickly, which leads to the fact that the software architecture is not adequately designed. This has negative consequences as it leads to ripple effects. In this case, the programmer makes a mistake by making the program units tightly connected, so changes in one program unit (or component) cause changes in other related program units. Consequently, some parts of the system had to be rewritten from scratch.
Redundancy is an unwanted feature that leads to anomalies in database operations. In PUC BWS, it is very pronounced, primarily due to the inadequate design of some parts of the system that many programmers use in their applications. Although a lot of work has been done to keep it under control, there are still situations when programmer intervention is needed to bring the tables in the database to the appropriate state.
In practice, it happens that when a system is developed in older technologies, it may have ceased to be supported by the hardware on which the system runs or the software. At PUC BWS, the problem arose because the PSC manufacturer for version 10 of the OpenEdge environment retired its reporting software, Report Builder, which had been in use for years before that. At that point, all the developers who had hundreds of reports programmed into that tool had to rework those reports into the new reporting tool that PUC BWS started using. A similar problem occurred with support for various ActiveX controls that were written for the 32bit version of the Windows operating system to work with Progress, causing
many problems.
The information system development in PUC BWS took place by first creating one part of the system, then the next one, and so on. This was primarily done based on the requests of various departments and sectors. Therefore, development took place with a bottom-up approach, with the need to integrate applications after development. This kind of ad-hoc integration led to the previously mentioned problems with architecture, and tight coupling between applications is further emphasized. In addition, there was a need for applications developed in Progress 4GL to exchange data with applications written in a completely different environment, which PUC BWS uses, such as EDAMS, GIS, etc. In practice, it turned out that some tools intended for data exchange between different databases worked very poorly, even though they were made for that. Inadequately implemented ETL processes resulted in incorrect data, duplicates, etc., and additional developer effort was required to overcome this.
The legacy information system performs its functions and thus supports business operations. By creating applications in PUC BWS, the business operations (processes) of the enterprise were established. Over time, there was a need to change those operations. Sometimes it was easy to implement those changes, and sometimes it wasn't because it was necessary to do a complete reprogramming of certain functionalities. Until the reprogramming was carried out, PUC BWS could not execute business processes in a new way. In some cases, when it was necessary to introduce new functionality into the legacy system, managers wanted to change the flow of sub-processes, i.e. the sequence of operations performed in the program, thus starting with the newly created functionality, but this was not possible because it required complete reengineering of the application, which was not justified at the time, and also very risky due to the very poor design of the old part of the application. Therefore, the legacy system of PUC BWS shows great inertness when it is necessary to implement more complex changes, which can even lead to changes in business processes.
The legacy system has been developed and maintained for years. It contains decades of valuable knowledge for performing work and numerous business rules created in the interaction between programmers and users when taking software requests. Those rules and procedures have passed years of testing in the practice of PUC BWS and, over time, have brought business operations to a high level of efficiency. This is very pronounced with those business processes that are not widely represented on the market through integrated software solutions because there are no formalized and software
available more efficient models of business processes with which the PUC BWS process model could be compared.
Top management could make a decision to change the business strategy in order to better achieve the intended goals, and this could trigger the reengineering of business processes to implement that strategy. What can happen is that the legacy information system cannot support the necessary change because it was created at a different time when business processes were arranged in a completely different way. If the strategy of PUC BWS would be to implement a change in the business, such as to change the way of invoicing water by introducing a higher and lower tariff, which currently does not exist, the legacy system due to the problems it has in integration, as well as the fact that very difficult expose its functionalities to other systems would not be able to support it. In that case, the legacy system would be a limitation in adopting the new business model. For example, suppose PUC BWS would use the technology of smart water meters, as well as the technology of sensors that can monitor the consumption of pumps at pumping stations at the same time. In that case, there is a need to exchange consumers data with the legacy system to see which consumer satisfies the condition for charging at a higher tariff. This would not be feasible because PUC BWS's legacy system does not support REST services technology through which the system could be integrated with the described solution.
Analysis of the PUC BWS Value Chain
For this research, we need to look at the limitations that the future strategy of PUC BWS will have by using the legacy system as its primary IT solution. By analyzing the value chain, we identify the critical activities of PUC BWS, their problems, and technological solutions that can improve these activities. In addition, we will analyze how the legacy system of PUC BWS limits the change of the mentioned solutions.
PUC BWS organizes and conducts its business, where the main product is water, and at the same time, consumers also use the wastewater removal service. The PUC BWS value chain is slightly different from the presented model by Ofwat (PwC, 2016, pp. 2-22). It consists of the following activities: water sources, raw water distribution, water processing, beverage distribution water, sale, sewage collection and sewage disposal. Based on the risks presented in the report, problems are associated with each of the PUC BWS value chain
activities. For this manuscript, we will present only a few of them. Water sources have the primary activity of extracting raw water, and the main problem that arises is source contamination. In the case of drinking water distribution, the primary activity is to distribute water from drinking water reservoirs to consumers. One of the problems that can occur is the interruption of supply due to breakdowns in the water distribution network. When selling, the primary activity is reading water meters, and the problem is the accuracy and frequency of readings.
Technological solutions (Difallah et al., 2013) that can help in solving problems in the chain of primary activities are based on Industry 4.0 technologies, namely: Internet of Things, smart meters, cloud technologies, Fog and Edge, then big data technologies, as well as artificial intelligence. They aim to eliminate or reduce the problems PUC BWS faces in its value chain as much as possible.
As the legacy PUC BWS system is built on the Progress OpenEdge 10 platform, it is not possible to create REST Web services that would enable the integration of the mentioned Industry 4.0 technologies that are executed in the cloud so that the entire system combines an on-premise solution and new technological solutions in cloud through a hybrid cloud architecture. As described, the legacy system limits the future strategy of PUC BWS and more efficient operations.
Framework Establishing
The new conceptual framework proposed in this manuscript is based on the work of Alderson and Shah (Alderson & Shah, 1999, pp. 1-2), where the legacy information system is viewed from 4 perspectives: developmental, operational, organizational, and strategic. The novelty in relation to that research is that the problems of legacy systems are viewed in connection with one or more perspectives. In this way, the problem is classified and can be better investigated by focusing on a particular group of employees who deal with that problem. In addition, the proposed framework also aims to integrate the definitions, descriptions and perceptions of legacy systems presented so far, existing in theory and practical knowledge generated in research.
Concerning research (Alderson & Shah, 1999; Khadka et al., 2014), the proposed conceptual framework will incorporate a look into the future as part of a strategic perspective. The conceptual framework is shown in the figure (Figure 1).
Previous research looks at the problems of legacy systems in the present. In the author's opinion, the role of the strategic perspective is to partly anticipate
changes in the future, especially those that can affect the change of the business model, which is important for achieving the company's mission, vision and goals. In addition, if it is necessary to modernize the system, which is a very demanding undertaking from the aspect of finance, human resources management, but also the time that needs to be devoted to those activities, anticipating the future needs of the system can be useful and more profitable if, at the start of the strategy of modernization, future system improvements are incorporated, if possible and financially justified. This may prove to be better than carrying out the modernization without mentioned improvements and then, in a short time after that, again carrying out the extensive modernization procedure in order to enable the mentioned improvements. This idea of a modernization process should include solving current and future problems relevant to the legacy system and the business it supports.
Description of the Research
After conducting a case study on the legacy system of PUK BWS and then analyzing the value chains of PUK BWS, a conceptual framework was defined, so it is necessary to conduct research that aims to evaluate the proposed framework in practice. The goal is to ensure the external validity of the case study as a basis for the possibility of generalizing the results of the case study. This research phase will be conducted through a questionnaire in which IT managers, people who work on system development (programmers, designers, architects, etc.), and mid-level managers express their views on legacy systems.
The questionnaire contains 25 questions, of which the number of open questions is 3, and the number of closed questions with the possibility of choosing one option is 22. The closed questions are arranged according to a Likert scale of 5 answers. Of the closed questions, 21 examine attitudes by selecting one of the offered answers: fully agree, partially agree, divided, somewhat disagree and completely disagree. Question number 4 determines the age of the system, where the respondent can choose one of the options: less than ten years, between 10 and 15 years, between 15 and 20 years, between 20 and 25 years and over 25 years. The questionnaire is given in the appendix.
Answers to the questions were collected from respondents who work in water supply companies in Serbia and the region through an online questionnaire. Communication with respondents was carried out via phone, email and LinkedIn social network. A questionnaire was created in English for respondents in Hungary,
Bulgaria and Romania, and the answers were combined at the end. The sample includes 63 respondents. Serbia had 34 respondents by country, Bosnia and Herzegovina 7, Bulgaria 2, Montenegro 3, Croatia 6, Hungary 3, Romania 2, North Macedonia 3 and Slovenia 3.
Results
To question number 4, respondents gave answers regarding the age of the information system. The values of the statistical feature in the IBM SPSS tool are assigned values in such a way that the answer up to 10 years takes the value 1, the answer between 10 and 25 years takes the value 2, the answer between 15 and 20 years takes the value 3, and the answer between 20 and 25 years takes the value 4 and the answer over 25 years takes the value 5. The frequency table (Table 1) shows the participation of a certain group in the sample.
Question number 5 was open, and user responses were as follows: SQL, Oracle, Dynamics NAV, MS Access, Visual FoxPro, Cobol, Java, VB (Visual Basic), C#, MS SQL, Progress, SQL Server, PL2, .NET, Delphi, Harbor, MySQL, C++, IAF, ASP, PHP, ABAP (SAP) and C. The value of the descriptive statistics is shown in the table (Table 2), which shows the output results from the SPSS tool.
Discussion
The discussion should show to what extent the proposed framework for evaluating legacy systems applies beyond PUC BWS to companies that deal with water production and wastewater disposal services. For this reason, the previously designed and presented questionnaire connects legacy systems' elements (problems) with the perspectives of legacy systems.
We will start by analyzing the answers to questions Q6, Q9, Q15, Q16, Q18, Q19, Q20 and Q21 as they relate to the development perspective. The arithmetic mean values for questions P6 and P9 show that the respondents think the legacy system's software architecture is not well designed. At the same time, the system has a large number of ripple effects that indicate the existence of strong connections to a large extent between different applications and components (Pfleeger & Atlee, 2009, p. 297). This further complicates the maintenance of the system and requires the re-engagement of the development team, which is inefficient. There is redundancy in the systems, based on the
results of the answer to question Q20. As it leads to anomalies in operations when working with the database, such as inserting a new row, changing an existing one, and deleting and displaying data, it should be removed as much as possible (Lazarevic et al., 2006, p. 2). Answers to questions Q18 and Q19 indicate that there is a big problem in the knowledge of the system, which is primarily a consequence of the departure of employees who worked on the development of the system in the past and the fact that the documentation does not exist or is not up-to-date. The authors of an earlier study reached similar considerations (Khadka et al., 2014). Also, based on the results of questions Q15 and Q21, it can be said that it takes a long time for a new employee to become part of the development team, where one part of the problem is technological, and the other part is the slower transfer of knowledge about the system itself. In addition, there is a lack of software engineering best practices, which confirms the views from earlier papers (Mitleton-Kelly, 2006).
Answers to questions Q10, Q11, Q12, Q13, Q14 and Q22 are related to problems that arise from an operational perspective. It can be seen that there are significant problems in the integration of the system based on the views of respondents on questions Q11, Q12, Q13, and partly on Q10. This is manifested through significant adaptation of the system to work with new applications, complex integration with other important information systems for waterworks such as GIS and SCADA, and problems in data exchange with external companies. Part of that problem is the presence of an architectural anti-pattern, better known as a "silo" (Willem-Jan, 2009, p. 22). Respondents' opinions were divided regarding manufacturer support as well as outdated hardware.
From an organizational perspective, respondents believe the legacy system is still valuable because it contributes to the business. At the same time, they believe that modernization would provide better support for decisionmaking because it is currently not at a high level. In addition, they see the system as inflexible, and this prevents them from carrying out business processes in a more efficient way, which is additionally emphasized when performing business processes that are carried out in cooperation with other companies. Other authors have similar views (Wu et al., 1997). The results of the answers to questions Q7, Q8, Q13 and Q23 indicate their attitudes.
Respondents' answers to questions Q8 and Q24 are related to the strategic perspective, where their perception is that the inherited system limits business changes. At the same time, there is an attitude about the difficult
integration of Industry 4.0 technologies and the legacy system, which prevents the adoption of new business models.
As with previous research on legacy systems (Khadka et al., 2014), it is observed that users do not perceive whether the system is old or legacy. For them, it is simply the system they use, as the result of the answer to question Q3 indicates. In addition, users believe that modernization of their systems is needed and that this framework can help with that. They recognize that the framework's value lies precisely in the fact that the problem is viewed from multiple dimensions, i.e. perspective, and that it can contribute to successful modernization, which can be concluded based on their attitudes to questions Q17 and Q25.
Users perceive the importance of viewing the system from several perspectives, which can contribute to a better understanding of the system and the perception of the system. This confirms previously conducted research (Alderson & Shah, 1999; Khadka et al., 2014). It is new that there is now a formalized procedure that can contribute to this, and it can be applied outside the water utility industry with adequate modifications.
Conclusion
The results obtained in this research lead to the conclusion that there is value in looking at the legacy system through its different perspectives provided by the different types of users who work on them and that this is a better option than seeing them from only one angle, e.g. technological. A framework that can be used to evaluate legacy systems has been defined, which incorporates the problems of legacy systems viewed from different perspectives. By understanding these problems along with additional analysis of the legacy system, a suitable modernization strategy can be chosen through which the system in its modified form would continue to live.
The research covers the domain of water companies, where a value chain analysis was conducted for such companies. Companies from another domain have different value chains, and perhaps the technologies that should be applied in the future are not the same as those of water companies, so it is necessary to make appropriate modifications to the framework to perform an adequate evaluation of legacy systems, which is the limitation of this research.
References
Alderson, A., & Shah, H. (1999). Technical opinion: Viewpoints on legacy systems. Communications of the ACM, 42(3), 115-116. https://doi.org/10.1145/295685.295722
Bisbal, J., Lawless, D., Wu, B., Grimson, J., Wade, V., Richardson, R., & O'Sullivan, D. (1997). Overview of legacy information system migration. Proceedings of the Asia-Pacific Software Engineering Conference and International Computer Science Conference, APSEC and ICSC, 529530. https://doi.org/10.1109/apsec.1997.640219
Brooke, C., & Ramage, M. (2001). Organisational scenarios and legacy systems. International Journal of Information Management, 21(5), 365-384. https://doi.org/10.1016/S0268-4012(01)00023-8
Difallah, D. E., Cudre-Mauroux, P., & McKenna, S. A. (2013). Scalable anomaly detection for smart city infrastructure networks. IEEE Internet Computing, 17(6), 39-47. https://doi.org/10.1109/MIC.2013.84
Khadka, R., Batlajery, B. V., Saeidi, A. M., Jansen, S., & Hage, J. (2014). How do professionals perceive legacy systems and software modernization? ICSE 2014: Proceedings of the 36th International Conference on Software Engineering, 36-47. https://doi.org/10.1145/2568225.2568318
Lazarevic, B., Marjanovic, Z., Anicic, N., & Babarogic, S. (2006). Baza podataka [Databases] (3rd ed.). Fakultet organizacionih nauka.
Mitleton-Kelly, E. (2006). IT legacy systems: Enabling environments that reduce the legacy problem: A complexity perspective. In N. Madhavji, J. Fernandez-Ramil, & D. Perry (Eds.), Software evolution and feedback: Theory and practice (1st ed.). John Wiley & Sons Ltd. https://doi.org/10.1002/0470871822.ch3
Nassif, R., & Mitchusson, D. (1993). Issues and approaches for migration/ cohabitation between legacy and new systems. SIGMOD '93: Proceedings of the 1993 ACM SIGMOD International Conference on Management of Data, 471-474. https://doi.org/10.1145/170035.170145
Parnas, D. L. (1994). Software Aging. ICSE '94 Proceedings of the 16th
International Conference on Software Engineering, 279-287.
Pfleeger, S. L., & Atlee, J. M. (2009). Software engineering: Theory and practice (4th ed.). Pearson.
PwC. (2016). Balance of Risk: Risk and reward across the water and sewerage value chain. http://www.ofwat.gov.uk/wp-content/uploads/2015/12/rpt com201512pwcrisk.pdf
Seacord, R. C., Plakosh, D., & Lewis, G. A. (2003). Modernizing legacy systems: Software technologies, engineering processes, and business practices. Addison-Wesley Professional.
Sommerville, I. (2016). Software engineering (10th ed.). Pearson Education Limited.
Ulrich, W. M., & Newcomb, P. H. (2010). Information systems transformation: Architecture-Driven modernization case studies. In Information systems transformation. Morgan Kaufmann OMG Press Titles. https://doi.org/10.1016/C2009-0-19987-7
United States Government Accountability Office. (2019). GAO-19-471 - Information technology - Agencies need to develop modernization plans for critical legacy systems. https://www.gao.gov/assets/700/699616.pdf
Vesic, S. L. (2020). Uticaj razvoja IT tehnologija na prevazilazenje problema nasledenih sistema [The impact of the Development of IT technologies in overcoming the problems of legacy information systems]. Kultura Polisa, 17(42), 667-678.
Warren, I. (1999). The renaissance of legacy systems. Springer.
Willem-Jan, van den H. (2009). Aligning modern business processes and legacy systems: A component-based perspective. The MIT Press. https://doi.org/978-0262513463
Wu, B., Lawless, D., Bisbal, J., Grimson, J., Wade, V., O'Sullivan, D., & Richardson, R. (1997). Legacy systems migration-a method and its tool-kit framework. In Proceedings of Joint 4th International Computer Science Conference and 4th Asia Pacific Software Engineering Conference, Hong Kong, China, 1997 (pp. 312-320). https://doi.org/10.1109/apsec. 1997.640188
Okvir za evaluaciju nasledenih sistema - Studija slucaja
Slavimir Lj. Vesic1 i Dusko Lakovic2
1JKP „Beogradski vodovod i kanalizacija" 2 Ministarstvo unutrasnjih poslova Republike Srbije
Sazetak
Fenomen nasledenih sistema je veoma slozen, nedovoljno shvacen ili izolovano posmatran u teoriji i praksi, sto dovodi do velikog broja neuspelih projekata modernizacije cak i pored znacajno investiranih sredstava. U ovom radu se u okviru studije slucaja posmatraju problemi nasledenih sistema, klasifikuju u odgovarajuce perspektive i daje se predlog okvira za evaluaciju nasledenih sistema, koji ima za cilj da doprinese boljem razumevanju nasledenih sistema, pa samim tim i odabirom pogodne strategije modernizacije za konkretan sistem. Studija slucaja je sprovedena na JKP BVK, zajedno sa analizom lanca vrednosti. Nakon toga je izvrseno istrazivanje na pojedinim gradskim vodovodima u Srbiji i regionu gde su ispitanici izlozili svoje stavove, ali i strucna misljenja o nasledenim sistemima. Na osnovu dobijenih rezultata moze se zakljuciti da predlozeni konceptualni okvir moze posluziti kao alat putem kojeg se moze proveriti da li sistem iskazuje karakteristike nasledenog sistema.
Kljucne reci: nasledeni sistemi, okvir za evaluaciju, evolucija softvera, perspektive nasledenih sistema
