Abstract. Change design is one of the key steps within the IT change management process and involves defining the set of activities required for the implementation of a change. Despite its importance, existing approaches for automating this step disregard the impact that actions will cause on the affected elements of the IT infrastructure. As a consequence, activities that compose the change plan may not be executable, for example, due to runtime constraints that emerge during the change plan execution (e.g., lack of disk space and memory exhaustion). In order to address this issue, we propose a solution for the automated refinement of runtime constraint-aware change plans, built upon the concept of incremental change snapshots of the target IT environment. The potential benefits of our approach are (i) the generation of accurate, workable change plans, composed of activities that do not hinder the execution of subsequent ones, and (ii) a decrease in the occurrence of service-delivery disruptions caused by failed changes. The experimental evaluation carried out in our investigation shows the feasibility of the proposed solution, being able to generate plans less prone to be prematurely aborted due to resource constraints.

No abstract

The current research on IT change management has been exploring several aspects of this new discipline, but it usually assumes that changes expressed in Requests for Change (RFC) documents will be successfully executed over the managed IT infrastructure. This assumption, however, is not realistic in actual IT systems because failures during the execution of changes do happen and cannot be ignored. In order to address this issue, we propose a solution where tightly-related change activities are grouped together forming atomic groups of activities. These groups are atomic in the sense that if one activity fails, all other already executed activities of the same group must rollback to move the system backwards to the previous state. The automation of change rollback is especially convenient because it relieves the IT human operator of manually undoing the activities of a change group that has failed. To prove concept and technical feasibility, we have materialized our solution in a prototype system that, using elements of the Business Process Execution Language (BPEL), is able to control how atomic groups of activities must be handled in IT change management systems.

No abstract

No abstract