Patent Application
20100318391
The present invention relates to a method for changing an information technology system comprising a plurality of interacting components.
The present invention further relates to a computer program product for providing a change schedule for changing an information technology system comprising a plurality of interacting components.
The present invention yet further relates to a system comprising a computer including such a computer program.
Information technology (IT) systems such as networked systems have reached high levels of complexity. This complexity for instance manifests itself in the system comprising a large variety of hardware and software components between which complex dependencies exist. It is well-known that IT systems regularly require maintenance, e.g. because software and/or hardware components need rebooting, replacing, updating and so on. In the context of the present application, such maintenance tasks are generally referred to as changes, and are usually performed during pre-agreed maintenance windows. The complexity of the system under maintenance is reflected in the complexity of the maintenance task itself; because of the increasing volume of changes, it has become virtually impossible for a system manager to manually schedule the required changes during available maintenance windows.
For this reason, several at least partially automated processes have become available to help generate change schedules for IT systems. An example of such a process is the IT information library (ITIL). The IT Information Library defines several processes to enable IT service management. Change management is one such process. Its objective is to ensure that IT changes are recorded, evaluated, authorized, prioritized, planned, tested, implemented, documented and reviewed in a controlled manner; see for instance the ITIL Service Transition book, 3rd version, which can be purchased on-line from http://www.itil.org.uk. Several ITIL compliant change management systems are available from various software vendors. These systems are useful in tracking, coordinating and visualising changes.
Another change management system is disclosed in ‘The CHAMPS System: Change Management with Planning and Scheduling’ by Keller et al. in Proceedings of the 9th IEEE/IFIP Network Operations and Management Symposium (NOMS 2004), Seoul, Korea, 2004, pages 395-408. The CHAMPS system consists of a task graph builder and a planner & scheduler. The task graph builder is designed to determine temporal and location constraints of tasks needed to complete a request for change by creating reusable workflows from existing component dependency descriptions, whereas planner & scheduler uses the constructed task graph to construct a change schedule. The CHAMPS system is particularly designed to introduce a large degree of parallelism in the change process by parallelizing changes that are independent of each other.
Both prior art approaches assume that a feasible change schedule can be derived from the required changes and the associated constraints. However, in practice, the complexity of the set of constraints may be such that the known change management approaches cannot produce of a feasible change schedule, which forces an IT manager to redefine certain constraints and repeat the scheduling exercise. This not only is time-consuming, but also introduces an increased risk of the IT manager introducing conflicts in the schedule to be produced. Consequently, there exists a need for an improved change management method.
Embodiments of the invention are described in more detail and by way of non-limiting examples with reference to the accompanying drawings, wherein:
It should be understood that the Figures are merely schematic and are not drawn to scale. It should also be understood that the same reference numerals are used throughout the Figures to indicate the same or similar parts.
In this description, the following vocabulary is used to describe the change management domain, e.g. the system architecture 100 in accordance with an embodiment of the present invention as shown in
Following ITIL terminology, any IT component that needs to be managed in order to deliver an IT service is called a configuration item (CI). A CI may be a hardware component or a software component. An activity changes a CI of the IT system. A component, or CI, is said to be a Changed CI (CCI) if it is directly changed by an activity. A CI is said to be an Affected CI (ACI) it has a dependency on a CCI (for instance a web server is an ACI if the underlying server is rebooted).
In an embodiment, each activity may require a skilled human resource such as a technician. The technician can be named explicitly in the activity. Alternatively, the activity can specify the required skill, e.g., a UNIX engineer.
The change management architecture of
The architecture comprises a first database 110, which constitutes a Change Management System (CMS). CMS 110 comprises the required component changes, which are sometimes referred to as requests for change (RFCs). Such an RFC typically includes a description of the component change, as well as component change attributes. Such attributes may include one or more of the following: a status of the change indicating the step in the change lifecycle (for instance “created”, “approved”, “implemented”, “closed”), a change deadline, and acceptable maintenance windows. The RFC further comprises the detailed workflow of each change, said workflow comprising a list of change activities subject to precedence constraints between them, e.g. activity A must be performed before activity B, and temporal constraints, e.g. activity A must start after 10 am, as well as details of each change activity. Such details may include duration, required skill or required technician for executing the activity.
CMS 110 may further include a calendar of available maintenance windows, and, in case the change activity details include required skill or a required technician, the CMS 110 may further include a calendar of available technicians. It will be appreciated that the data stored in CMS 110 requires little knowledge of the actual IT system to which the RFCs have to be applied. In other words, CMS 110 stores little dependency information other than the order of the activities in the RFC workflows. This makes it relatively straightforward for a systems manager, or any other suitable person, to add a RFC to CMS 110. The addition of a new RFC to CMS 110 may be realized in any suitable way, and will not be further discussed for reasons of brevity only.
The system architecture 100 further comprises a second database, i.e. configuration management database (CMDB) 120. The CMDB 120 lists details of all hardware and software components in the IT system to be changed. Such components are generally also referred to as configuration items (CI) in ITIL. The CMDB 120 further lists the dependencies between the components of the IT system. An example of such a dependency is “If server A is taken down then application 1 won't be available”, or “If application 2 is taken offline, business service B is unavailable”.
In other words, the CMDB 120 contains the IT system specific information which enables the definition of constraints on the execution of RFCs stored in CMS 110. In other words, the CMDB 120 typically comprises dependencies between components, whereas CMS 110 typically comprises constraints on the execution of changes. It will be appreciated that the respective data formats of the databases 110 and 120 do not have a material effect on the various embodiments of the present invention, and may be chosen to have any suitable data format.
The architecture 100 is designed to translate the information stored in CMS 110 and CMDB 120 into a set of constraints for a change request. Such a translation step typically involves the extraction of the relevant constraints information from the relevant request in CMS 110 and the associated components constraints in CMDB 120. These constraints may be kept in a constraints database such as constraint storage 140. The following types of constraints may be generated:
It will be appreciated that other suitable constraints that can be derived from the information in CMS 110 and CMDB 120 may also be used. Any changes in the content of CMS 110 or CMDB 120 trigger an update of the constraint storage 140.
As previously explained, most constraint-based change scheduling problems such as a constraint scheduling problem based on the above set of constraints turn out to be unsolvable, i.e. it is not possible to find schedules that satisfy all constraints, thus causing the need to relax certain constraints.
In accordance with an embodiment of the present invention, in order to reach a solution, i.e. produce a change schedule that can be executed during the available maintenance windows, a change manager, i.e. an IT manager responsible for managing the change process, may specify his preferences regarding the relaxation of constraints as well as the definition of preference scores for the changes in CMS 100 in the form of production rules, which may be provided in the form of a preference rule set 130.
Such preference rules may take the form of a conditional expression, e.g. IF condition THEN action. The condition of a rule can be on the type of constraint and/or on a change attribute, e.g. urgency, deadline, type of customer, and so on. The action of a rule can be used to adjust the preference score of the constraint. Examples of such adjustments include increasing a preference score, decreasing a preference score and assigning a fixed value to a preference score. For example, such a rule may read: “if the constraint is a deadline constraint and the impacted system is SAP, then increase the preference score by 5”. The preference rule set 130 is evaluated on all the constraints in the constraint store by a change scheduler 150, which will now be described in more detail.
In an embodiment, the change scheduler 150 comprises a preference evaluator 160 and a constraints solver 170. The preference evaluator 160 is configured to evaluate the preference rules in the preference rules set 130 and to assign a preference score to each constraint from constraints storage 140 based on these preference rules. In an embodiment, all constraints from constraints storage 140 have the same initial score, e.g. a preference score of 0. The preference evaluator 160 may be implemented by means of any suitable rule engine, e.g. the Drools system (http://labs.jboss.com/drools) and may apply priority rules to the assignment of preference scores from the preference rules set 130; e.g. the assignment of a fixed score has priority over increasing or decreasing a score. The preference evaluator 160 produces a preference score for each constraint.
The set of constraints with their individual preference scores is forwarded from the preference evaluator 160 to the constraints solver 170. The constraints solver 170 may be implemented by any suitable constraint solver, e.g. the JAVA-based Choco constraint programming system, also known as the Choco solver. The constraints solver 170 attempts to generate a change schedule based on the constraints and their preference scores received from preference evaluator 160. An embodiment of the method, or algorithm, applied by the constraints solver is given in
If the scheduling attempt in step 240 is unsuccessful, the algorithm will check in step 260 if a pre-defined threshold, e.g. a maximum number of iterations or a time limit has been reached. If this is the case, the algorithm will again terminate in step 280 with the provision of the most recently produced schedule as a best attempt to find an acceptable change schedule. In an embodiment, the schedule produced after reaching the pre-defined threshold may be incomplete, i.e. some changes may have been scheduled, whereas other changes that could not be scheduled may have been omitted.
Otherwise, i.e. in case no feasible schedule could be provided, the algorithm will proceed to step 270 in which the preference scores of the selected constraints are modified. Such modifications may include the deletion of constraints having a low preference score, i.e. constraints that are deemed to have limited importance, or the adjustment of preference scores of constraints based on the preference rules provided by the IT manager. In an embodiment, a high preference score will lower the chance of a constraint to be relaxed. The algorithm subsequently reverts back to step 230. This process is repeated until an acceptable schedule or the maximum number of iterations is reached.
In an embodiment, in case a feasible, or acceptable, schedule cannot be reached, the constraint solver may perform an infeasibility analysis using techniques, e.g. a ‘Finding Irreducible Infeasible Systems’ algorithm. An example of such a technique is disclosed by O. Guieu et al. in “Analyzing Infeasible Mixed-Integer and Integer Linear Programs”, INFORMS Journal on Computing. Vol. 11 (1), 1999, pages 63-77. Such an analysis will reveal the potential constraints causing the infeasibility of the schedule to the IT Change Manager. This will help the IT Change Manager to take the right course of action to ensure a feasible schedule may be reached, e.g. changing constraint preferences, deleting constraints or even excluding certain changes.
A key element of any constraint solver is a clever branching strategy for traversing the search tree. In order to produce acceptable solutions within a reasonable timeframe, such a branching strategy should take into account the specificity of the problem to be solved. A branching strategy has to be able to, at any given iteration, choose which decision variable to assign which value from its domain. In the context of an embodiment of the present invention, such decision variables may be chosen from two sets of decision variables, namely a set of change decision variables Cjk which will be assigned a value from the possible maintenance windows and a set of activity decision variables Aijk which will be assigned a start time in a specific maintenance window. In the previous notation, the index i runs over all activities of a change, the index j runs over all changes and the index k runs over all maintenance windows.
It has been realized that the assignment of a change to a change window is pointless unless all the activities of that change can all be assigned a starting time in the same change window. Consequently, any branching strategy should alternate between the assignment of a change and the assignment of all of its activities. In other words, if the present branching object is a change decision variable Cjk, another change decision variable Clk cannot be chosen until all decision variables of the activities associated with change Cjk have been explored.
In an embodiment of the present invention, a branching strategy is used that alternates between change decision variables and activity decision variables. Once a decision variable is chosen, the next step is a value assignment from its domain. It will be appreciated that any assignment strategy should look to assign values that maximize the chance of yielding an acceptable change schedule.
It has been found that for the problem of generating a change schedule, an ‘As Late As Possible’ approach for the assignment of change decision variables and an ‘As Soon As Possible’ approach for the assignment of activities decision variables are most successful in yielding acceptable change schedules.
In an embodiment, the change scheduler 150 is configured to receive an existing change schedule. The use of an existing schedule minimizes perturbations to existing schedules of changes, since the choice of the starting value for the exploration of a decision variable of an already scheduled change is the assigned value corresponding to the previous schedule.
One of the strengths of the scheduling approach of the present invention is that it is based on an optimization strategy. This not only allows the generation of acceptable schedules, but also allows the generation of schedules that optimize a given objective function. Almost any objective function can be plugged in the change scheduler 150. Examples of objective functions include maximizing the number of changes in change windows, minimizing the downtime of IT services, and minimizing the overall cost of the change process. Other suitable examples of objective functions will be apparent to the skilled person.
An embodiment of the method of the present invention, which may be implemented by system architecture 100, is depicted in the flowchart of
Next, an attempt is made to generate a change schedule in step 370, and it is checked in step 380 if this attempt has been successful. If so, the method terminated in step 390. Otherwise, the method reverts back to step 360 to amend the preference scores of the change constraints, e.g. by altering preference scores of by deleting the constraint altogether, after which the generation of the change schedule is reattempted based on the altered preference scores, as also explained in the context of change scheduler 150.
The architecture 100 as shown in
In a further embodiment, the computer program product may be arranged to generate a set of individual preference scores based on the preference rule set 130, and may be arranged to amend the preference scores using this rule set in case an acceptable schedule cannot be generated using the initial preference scores, as previously explained.
In another embodiment, the computer program product may be arranged to include the availability of skilled human resources in the scheduling procedure, as previously explained.
Since the implementation of the various embodiments of the method of the present invention in such a computer program product can be realized by the skilled practitioner in this field by employing his routine skills, such implementation details are omitted for the sake of brevity only.
The computer program product may be made available as a separate product for use with the aforementioned system, e.g. on a computer-readable data carrier such as a CD-ROM, DVD, memory stick, an internet-accessible server for downloading the computer program product, and so on.
It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim. The word “a” or “an” preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several distinct elements. In the device claim enumerating several means, several of these means can be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP2008/051894 | 2/15/2008 | WO | 00 | 8/11/2010 |
