Communications of the ACM
Home/Magazine Archive/November 2005 (Vol. 48, No. 11)/Maintaining Enterprise Software Applications/Full Text
Communications of the ACM
Maintaining Enterprise Software Applications
Software maintenance is a widely studied area in the information systems literature [2]. This subject is of particular importance because software maintenance costs often constitute a significant portion of the total cost incurred on a software system during its useful life. Despite this fact, software maintenance has a negative image in the minds of software professionals who consider it to be intellectually boring and tedious. However, the recent trend of developing enterprise information systems with integrated applications across the firm has opened up new and significant challenges for software maintenance, rekindling interest in this area.
Nowadays, a software application is rarely designed to operate as a standalone system, but must interact with other software applications [4]. While the push for creating integrated enterprise applications has profound implications for the practice of new software development, this trend has important consequences for software maintenance as well. In today's world of integrated applications, maintenance practice must not only encompass the maintenance of a single system, but also take into account how any maintenance done on an application impacts other (linked) applications. However, the bulk of the research on software maintenance still continues to focus on single system maintenance.
This article takes a holistic approach to the problem of maintaining integrated systems by considering it from three different perspectives: operational, architectural, and organizational. Operational aspects of software maintenance deal with the timing and scope of maintenance activities so as to reduce the total cost of maintaining a group of interdependent systems. The architectural perspective describes steps that can be taken during system development (prior to maintenance) to ease the burden of maintaining a set of integrated applications. Finally, we discuss some organizational issues (such as departmental incentives and benefits from cooperation among departments) that impinge on the successful implementation of any approach that aims to reduce the cost of maintaining interdependent systems.
A variety of factors play a significant role when maintaining integrated systems. Here, we describe these factors and how they affect maintenance costs.
Type of interaction. Interaction between applications may either result from the sharing of data, sharing of processes, or both. Sharing of data usually results when the output of one application is used as input to another application. Maintenance of a software application may result in (relatively) simple changes to the shared data (such as a change in format), or could be more complex as in a change to a set of data items that are shared. In either case, care needs to be taken to maintain compatibility, in format and content, of the shared data between the source and the receiving applications.
Systems can also interact by sharing common processes (for example, one system may call a subroutine or function that is part of another system). Another common source of process sharing is when two or more applications use a common independent program or subroutine. The impact of changes to a shared process can often be significant and result in complex maintenance of the affected systems.
Number of systems involved. With interlinked applications, changes to one application can set off a chain reaction that can result in a considerable amount of maintenance effort. A number of different scenarios are possible. For illustrative purposes, consider three interdependent systems A, B, and C (see Figure 1). The simplest situation arises when changes to A affect both B and C. Another possibility exists where changes to A affect B, which when changed necessitates changes to C. Finally, the most complicated situation is when changes originating from A lead to changes in B and C that loop back to require further changes to A. Clearly, as the number of interdependent systems increases, the complexity of maintenance should also increase. Architectural solutions are particularly applicable in such cases.
Level of interaction. The level of interaction between two applications is a measure of the likelihood that one application will be impacted by changes to the other application. Though the level of interaction will be high for applications that directly interact with one another, the level of interaction may not be zero for applications that are only indirectly connected. Figure 1 depicts a scenario where changes to A affect B, which when changed necessitate changes to C. B will be more affected than C by changes to A, since there is one level of indirection between A and C; however, the indirect impact of A on C (indicated by a dashed line) may still be significant. The bold line connecting B and C represents a higher level of interaction between these two systems. Operational solutions that combine the maintenance schedules of interacting systems will lead to greater benefits in the case of tightly dependent systems.
Direction of interaction. Interaction between systems can be unidirectional or bidirectional. With unidirectional interactions, changes to application A cause changes to application B; however, changes to application B have no impact on A. With bidirectional interactions, changes to system A cause changes to system B and vice versa. In Figure 1 we can see that A affects B, but B does not affect A. On the other hand, the interaction between B and C is bidirectional. This factor is of relevance because it affects the incentives of the owners of the two systems (for example, different departments within the firm) to cooperate with one another.
Type of maintenance. A system can be modified for two reasons: perfective maintenance and integrative maintenance. The term perfective maintenance is a standard term used in existing literature to indicate maintenance done to functionally enhance the system. We introduce the term integrative maintenance to refer to maintenance done to ensure consistency with linked applications. Integrative maintenance becomes necessary when maintenance changes to a system results in loss of compatibility with a related system. This necessitates integration changes in the other system. Integration changes are made for the sole purpose of establishing compatibility and do not provide any new functional benefits.
Maintenance costs. The cost of modifying a system has a fixed and variable component. Previous studies have shown that software maintenance exhibits both scale economies and scale diseconomies [1]. Scale economies can be captured by the fixed component of maintenance costs. The variable cost component leads to scale diseconomies because the variable cost of maintenance increases non-linearly with the number of features or requests that are implemented during maintenance. The third cost component is the waiting cost, which are opportunity costs incurred by the users of a system due to maintenance change requests that have not been implemented. The total variable cost of maintenance depends on the number of change requests that are implemented as well as the time users wait for the change requests to be implemented.
Most of the factors discussed here can have a significant impact on maintenance costs. Maintenance costs for a system increase with the number of related systems since a change to any of the interacting systems may result in changes to the system, thus affecting at least the variable component of maintenance cost. Similarly, type of interaction and level of interaction both have direct impact on maintenance costs since both affect maintenance complexity, which affects maintenance costs. Next, we propose operational approaches that reduce costs by combining the maintenance schedules of interacting systems.
Operational Solutions
Operational solutions optimize software maintenance efforts subject to the constraints imposed by the technical state of the interacting applications. For single software system maintenance, costs can be reduced by considering the trade-offs between scale economies and scale diseconomies of maintenance. This approach has led to the practice of periodic maintenance. For example, a batch of requests (as opposed to a single request) is implemented each time a system is maintained. We make a case for the joint maintenance of interdependent systems.
Consider a system that is due for perfective maintenance. Since such maintenance can break the compatibility with a dependent system [5], it may become necessary to modify the related system to reestablish compatibility; that is, integrative maintenance may be needed on the related system. While integrative maintenance is being done in a joint maintenance policy, perfective maintenance on the related system can also be performed. Thus, fixed costs of joint policy maintenance are shared between perfective and integrative maintenance.
For simplicity, we discuss these approaches in the context of two interdependent systems. Independent maintenance occurs when the two systems (say A and B) are maintained at intervals of ta and tb respectively. When the time to maintain System A, ta (or the time to maintain B, tb) is reached, all change requests to system A (B) are implemented. All resulting integration changes to system B (A) are also implemented at the same time. Joint maintenance occurs when both systems are maintained at intervals of t, that is, the time to maintenance for both systems. When the time to maintain the systems t is reached, change requests to both systems as well as all resultant integration changes are implemented.
Independent maintenance requires no coordination between the owners of interacting systems. Independent maintenance leads to fixed costs incurred on A (B) each time B (A) undergoes modifications that result in integrative changes required on A (B). Thus overall maintenance costs could increase if the fixed costs of maintenance are high. Maintenance costs could also increase if integrative maintenance is typically required when perfective maintenance is performed. Joint maintenance attempts to reduce costs by simultaneously maintaining the two applications and thus reducing fixed costs.
A mathematical model was formulated to study the validity of these hypotheses, namely that by combining maintenance of interdependent systems, maintenance costs can be reduced. Input data for the various model parameters was randomly generated and simulation experiments were conducted to study the cost trade-offs between independent system maintenance and combined system maintenance.
Maintenance costs for a system increase with the number of related systems since a change to any of the interacting systems may result in changes to the system, thus affecting at least the variable component of maintenance cost.
Figure 2 depicts the reduction in total maintenance cost that can be achieved by using joint maintenance over independent maintenance. Figure 2(a) reveals that the advantage of joint maintenance over independent maintenance (measured as the percent reduction in maintenance cost) increases as the fixed cost of maintaining system B increases. This is expected because the joint approach spreads the fixed costs of maintenance over perfective and integrative maintenance. Figure 2(b) shows that increasing the variable cost of maintaining system B has an effect opposite to the one concerning fixed cost. When the variable costs of maintaining B are relatively high, combining the maintenance schedules of A with B may not be a good idea. Figure 2(b) shows that the cost reduction also shrinks as the arrival rate of maintenance requests on system B increases. Figures 2(b) and 2(c) are essentially a result of the same effect. Increasing variable cost and arrival rate both result in more frequent maintenance for system B in the independent approach. When system B is maintained more frequently, the probability that integrative maintenance needs to be performed on system A is lower, resulting in better performance of the independent approach. In addition, the joint approach essentially delays the maintenance of system B, resulting in higher variable costs.
Figure 2(d) shows another interesting trend. As the interdependence between the two systems is increased, the benefit of using joint maintenance also increases. This implies that organizations with interdependent systems must encourage owners of software applications within the firm to collaborate their maintenance efforts so that the overall maintenance costs are reduced.
Architectural Solutions
While the joint maintenance of interacting applications can provide considerable benefits, operational solutions are ex-post approaches to reduce maintenance costs. An ex-ante solution is to build such a set of systems on a common architectural framework. We recognize this may not always be an option, especially when the applications have already been built without considering maintenance. However, when it is known in advance that interaction will be required, a common architectural framework eases the burden of maintaining these systems. We propose two such solutions; an architecture that we refer to as a "hub-based" architecture and another that uses the notion of interfaces.
Hub-based architectures. In hub-based architectures, all applications are built independently of one another. However, instead of interacting directly with one another, all interaction between systems takes place via an intermediary called the hub, which significantly reduces the complexity of interaction and results in reduced maintenance costs for the different systems.
Such technologies reduce complexity by reducing the total number and variety of connections that need to be managed: changes to one system result in changes to at most one other system (the hub) and hence the maintenance effort is greatly reduced. This architecture scales well, is modular in nature, and enables easy addition, deletion, and modification of applications.
Interface-based architectures. This approach requires separating the interface of an application from its implementation: changes to the system are made to the implementation, while keeping the interface unchanged. Thus a change to an application should not lead to integration breakdowns. The interface approach can be utilized to a limited extent even in the case of legacy application by applying a "wrapper" around the original application and using this wrapper as the interface through which other applications will interact with the legacy application.
The latest trend is the use of Web services technology to act as a conduit for communication among multiple systems [6]. Web services provide a simple, dynamic way, using standard protocols and formats like HTTP and XML, to connect distributed software components. The use of standard formats and protocols reduces problems of interoperability and incompatibility that have plagued earlier approaches to application integration. Web services technology can be used either as a hub to interconnect multiple systems or as an interface between pairs of systems.
The architectural solution works well when the interacting applications follow a similar timeline in terms of their life cycle, thus enabling them to be developed and implemented using a common architectural framework. At the very least, the interacting systems should be developed using technologies that are conducive to having a common architectural framework like a hub or wrapper imposed upon them. Thus architectural solutions may sometimes not work with older or preexisting applications.
Organizational Issues
The findings of this study suggest departments responsible for maintaining local systems should coordinate with departments that own related systems. Implementing a joint maintenance policy or enforcing a common architectural framework may not always be possible in a decentralized setting. In such situations, it may be necessary to devise incentive schemes that naturally align the maintenance objectives of the different departments that own related systems. Incentives may be especially appropriate when the interaction between systems is unidirectional. In such cases, the upstream system may have less incentive to collaborate with the downstream system. Exogenous factors will be required to enforce such collaboration. This includes cross-departmental subsidies; for example, one department subsidizes the other's maintenance costs thereby increasing the incentive to collaborate.
Similarly, incentives may be necessary for departments to collaborate during the development phase (building applications with a hub architecture, or building appropriate interfaces that facilitate seamless integration) so that maintenance effort can be reduced. As in the operational case, incentive mechanisms may be needed to bring about architectural cooperation.
In previous research, it has been recommended that the maintenance function should be separated from the development function [7]. While this study was at the level of the single system, a case may also be made to run the maintenance function as a single unit across the entire organization. Having a single organizational team or department for maintenance, however, may lead to some loss of flexibility and control for the end users or the departments that own and directly use certain applications. We therefore believe that economic incentives, rather than organizational structure (centralization of maintenance), are a more appropriate method to solve the problem of optimally maintaining a set of integrated applications with diverse users across the firm.
Conclusion
This article proposed directions to solve new challenges emerging in the area of software maintenance with the growth of integrated enterprise applications. Operational solutions were offered to align the timing and scope of maintenance activities. Architectural solutions approached the problem by embedding maintenance concerns during development through the use of a common architectural framework. Finally, organizational issues including cross-departmental subsidies were discussed, as well as centralization of the maintenance function to address the maintenance of linked applications.
The problem of maintaining integrated applications is by no means a simple one and requires an interdisciplinary approach. The most interesting issues lie at the intersection of computer science and economics, thereby providing researchers and practitioners in information systems rich ground for future exploration.
References
1. Banker, R. and Slaughter, S. A field study of scale economies in software maintenance. Management Science 43, 12 (1997), 17091725.
2. Banker, R., Davis, G., and Slaughter, S. Software development practice, software complexity, and software maintenance performance: A field study. Management Science 44, 4 (1998), 433450.
3. Barua, A. and Mukhopadhyay, T. A cost analysis of the software dilemma: To maintain or to replace. In Proceedings of the 22nd Hawaii International Conference on Systems Sciences (1989), 8998.
4. Harmon, P., Rosen, M., and Guttman, M. Developing E-Business Systems and Architectures: A Manager's Guide. Morgan Kaufmann, 2001.
5. Humphrey, W. Managing the Software Process. Addison-Wesley, 1990.
6. Papazoglou, M. and Georgakopoulos, D. Service-oriented computing: Introduction. Commun. ACM 46, 10 (Oct. 2003).
7. Swanson, E.B. and Beath, C.M. Departmentalization in software development and maintenance. Commun. ACM 33, 6 (June 1990), 658667.
Figures
Figure 1. Interacting systems.
Figure 2. Impact on total maintenance costs using a joint maintenance schedule.
©2005 ACM 0001-0782/05/1100 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2005 ACM, Inc.
No entries found