Maintenance assessment management

A computer-implemented method, system, and computer program product for assessing environment specific maintenance actions are provided. The method includes identifying a maintenance update for a specific environment including one or more computer systems, where the maintenance update addresses one or more known problems. The method also includes applying factors to determine an assessment index for the one or more known problems as a function of the specific environment. The assessment index indicates a level of installation criticality relative to the specific environment. The method further includes outputting an installation recommendation for the identified maintenance update in response to determining the assessment index.

BACKGROUND

The present invention relates generally to managing software deployment, and, in particular, to assessing environment specific maintenance actions for software updates in computer systems.

Modern software applications typically utilize a number of functions, directly and indirectly. The fulfillment of function requests frequently cross multiple operating system components. Software applications may call the functions explicitly via an external call, or, a software application may invoke function A, where function A may subsequently call function B, C, and D. Some software problems (e.g., bugs) may surface in customer environments. The software problems may only surface for a specific set of circumstances (e.g., order of function calls, software level, hardware level or any combination there of) or in highly involved timing situations. Customers desire to keep their system(s) as stable as possible. In order to ensure an enterprise is as resilient as possible to software defects customers must review and apply maintenance (individual fixes to software defects) on a regular basis. Today, the review of software defects is a manual process. It is highly complicated to determine which fixes apply to particular environments, if the environment in which the defect can be encountered exists in the customer's enterprise and which fixes introduce more risk than they stabilize.

SUMMARY

An exemplary embodiment is a computer-implemented method for assessing environment specific maintenance actions. The method includes identifying a maintenance update for a specific environment including one or more computer systems, where the maintenance update addresses one or more known problems. The method also includes applying factors to determine an assessment index for the one or more known problems as a function of the specific environment. The assessment index indicates a level of installation criticality relative to the specific environment. The method further includes outputting an installation recommendation for the identified maintenance update in response to determining the assessment index.

Another exemplary embodiment is a system for maintenance assessment management. The system includes a service inventory identifying a specific environment of the system and a maintenance assessment tool (MAT) executing on a user system. The MAT performs a method that includes identifying a maintenance update for the specific environment, where the maintenance update addresses one or more known problems. The MAT also applies factors to determine an assessment index for the one or more known problems as a function of the specific environment. The assessment index indicates a level of installation criticality relative to the specific environment. The MAT outputs an installation recommendation for the identified maintenance update in response to determining the assessment index.

A further exemplary embodiment is a computer program product for assessing environment specific maintenance actions. The computer program product includes a storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for implementing a method. The method includes identifying a maintenance update for a specific environment including one or more computer systems, where the maintenance update addresses one or more known problems. The method further includes applying factors to determine an assessment index for the one or more known problems as a function of the specific environment. The assessment index indicates a level of installation criticality relative to the specific environment. The method additionally includes outputting an installation recommendation for the identified maintenance update in response to determining the assessment index.

DETAILED DESCRIPTION

Exemplary embodiments provide a maintenance assessment tool to assess environment specific maintenance actions. Large and complex computing environments, such as mainframe computer systems, can execute numerous software applications on variety of processing subsystems. As problems are discovered and solutions are created to remedy the problems, enterprise administrators must sift through available maintenance updates to determine which updates are applicable to their specific environment. Since different enterprises can vary dramatically in customized configurations of hardware and software, it may be difficult for software providers to accurately assess the likely impact of installing updates with respect to potential adverse side effects for all enterprises. Introducing unnecessary changes can place an enterprise at risk of a harmful side effect without the benefit of fixing a critically important problem. Conversely, failing to install a critical update can lead to detrimental results. The process of manually analyzing available maintenance updates, assessing needs, and potential impacts can be a time consuming process for enterprises as well as the software providers that assist the enterprises. In an exemplary embodiment, the maintenance assessment tool assesses environment specific maintenance actions for a given enterprise and provides an assessment index indicating the relative value of installing maintenance updates as a function of the specific environment. Additionally, the maintenance assessment tool can track evaluations and maintain notes about the enterprise's decisions regarding each maintenance update, or, automatically take actions for fixes based on a determined assessment index threshold.

Turning now to the drawings, it will be seen that inFIG. 1there is a block diagram of a system100upon which maintenance assessment management is implemented in exemplary embodiments. The system100ofFIG. 1includes a provider system102in communication with enterprises104and108over a network106. In exemplary embodiments, the provider system102is a processing system including at least one processing circuit (e.g., a CPU) capable of reading and executing instructions, and providing connectivity with the enterprises104and108. Although only two enterprises104and108are depicted inFIG. 1, it will be understood that the provider system102can communicate with numerous enterprise systems of varying sizes and configurations. The provider system102may perform as a Web server, an application server, and a data management system for distributing software and information about problems via the network106.

While only a single provider system102is shown inFIG. 1, it will be understood that multiple provider systems can be implemented, each in communication with one another via direct coupling or via one or more networks. For example, multiple provider systems may be interconnected through a distributed network architecture. The single provider system102may also represent a cluster of provider systems collectively performing processes in conjunction with the enterprises104and108.

The network106may be any type of communications network known in the art. For example, the network106may be an intranet, extranet, or internetwork, such as the Internet, or a combination thereof. The network106can include wireless, wired, and/or fiber optic links.

The enterprises104and108can include any number of computer systems, such as user system110of enterprise104and user system112of enterprise108. The enterprise108includes additional computer subsystems, for instance, remote system114in communication with the user system112. The user systems110and112and the remote system114can comprise mainframes, desktop, laptop, and/or general-purpose computer devices accessed via user interfaces116and118. The user interfaces116and118can include various I/O devices, such as keyboard and display devices. The user systems110and112and the remote system114can execute a variety of applications, some of which may be common between the enterprises104and108. For example, user system110can execute applications120and122, while the user system112executes applications122and124, and the remote system executes application126. The applications120-126can include a variety of complex software applications comprised of multiple components and functions, e.g., a database application, a web server application, a word processing application, a spreadsheet application, a manufacturing control system application, a data warehousing application, an inventory and purchasing application, and the like. In exemplary embodiments, the enterprises104and108are configured with different hardware and/or software such that each enterprise represents a different environment. For example, even though both user systems110and112can execute application122, they may exploit different features of application122or rely on different underlying operating systems and/or hardware platforms.

In an exemplary embodiment, the user systems110and112each employ a maintenance assessment tool (MAT)128to assess availability of updates to the applications in each specific environment of the enterprises104and108. The user system110accesses a service inventory130on a data storage device132that is specific to the environment of the enterprise104. The service inventory130can include information about specific versions of the applications120and122, updates installed and implemented, as well as details regarding the hardware and other software installed in the enterprise104. Data in the service inventory130can be manually configured or automatically populated as the user system110is updated. Alternatively, a script can be executed that discovers and collects configuration data for the enterprise104. The data storage device132may also include profile data134. The profile data134can include an age parameter to specify how long an update should be aged before accepted for installation, thus increasing the likelihood that the update is stable and any problems with the update have been identified. The profile data134may also include other configurable data, such as identified functions or components that are of greater importance or sensitivity. For example, the profile data134may identify problem prone components or functions, components or functions needed for growth, and components or functions of interest.

Periodically or upon a user request, the MAT128contacts the provider system102to determine if updates are available and to assist the user in determining whether particular updates should be installed based on the specific environment as configured for each enterprise104and108. The provider system102accesses a data storage device136to analyze known problems logged in problem database138. The problem database138includes problem reports, also referred to as authorized problem analysis reports (APARs), that detail software defects, including defect attributes such as problem classification, symptoms, triggers to experience the problem (e.g., application, function, parameter, subsystem, etc.), and various identifiers to track problem reports. The MAT128can also access critical update identifiers140on the data storage device136to determine which problems are deemed critical to system performance and which maintenance updates142are for fixing particular problems. For example, a problem in the problem database138can be classified as a high-impacting problem (HIPER), with symptoms such as data loss, system outage, performance loss, and function loss across one or more computer systems, while a less severe problem may result in abnormal termination of an application with no additional side effects. The maintenance updates142represent program temporary fixes (PTFs) that provide workarounds between major product releases to fix the known problems logged in the problem database138. In an exemplary embodiment, the problem database138contains all fixes, the critical update identifiers140contains only high impacting problems, and the maintenance updates142are recommended fixes that have been tested.

The MAT128of enterprise104analyzes the problem database138and the critical update identifiers140in view of the contents of the service inventory130and profile134to determine which of the maintenance updates142are the most important for the specific environment of the enterprise104. The MAT128determines the level of exposure to problems as identified in trigger data of problem records in the problem database138through analyzing the service inventory130to determine whether the affected hardware and/or software is presently used in the environment of the enterprise104. In an exemplary embodiment, the MAT128applies factors determine an assessment index for a known problem as identified in the problem database138as a function of the specific environment, where the assessment index indicates a level of installation criticality relative to the specific environment of the enterprise104. The factors include a level of importance as a function of one or more defect attributes associated with the known problem, a level of exposure to the known problem in the specific environment, and policies of the specific environment included in the profile data134. The level of importance of defect attributes can be a weighted value that ranks symptoms of problems based on severity, from a multiple system failure across the enterprise104to failures more localized in scope (system, application, function, component, etc.). Higher weighting is also applied for more frequently used items identified in the service inventory130, as well as the pervasiveness of the problem, e.g., a common path versus a unique path. The profile data134provides additional guidance for weighting applied to the assessment index value, with higher weighting applied to components or functions that are of greater importance or sensitivity. The profile data134can also establish higher weighting to areas that are deemed to have greater future importance for the enterprise104.

The assessment index determined by the MAT128acts as a filter for users to more readily determine which of the maintenance updates142are the most important for the specific environment of the enterprise104. Some of the maintenance updates142will not be relevant to the enterprise104simply because the enterprise104does not have a configuration that would ever result in utilization of a particular update, e.g., a fix to drivers used only by application126. Thus, recommending such a fix under this circumstance would introduce an unnecessary change and associated unnecessary risk; hence, the update will be ignored. On the other hand, when an application is exploiting a function and has the pertinent system configuration, the fix will be recommended. Therefore, the configuration indicates how exposed the enterprise104is to a particular critical fix in the maintenance updates142.

The MAT128can determine importance factors for the maintenance updates142based on the impact of a problem when/if the problem is encountered. For example, if the problem results in a system outage or a loss of data, it is assigned an assessment index higher than a fix that results in an abnormal ending of an application but has no other adverse impacts.

In calculating the assessment index, the MAT128also considers whether the maintenance updates142themselves have known problems in the problem database138. The MAT128does not recommend installing maintenance updates142with known problems that have not been resolved (e.g., zero assessment index). Penetration of the fix (number of systems with the fix installed) is also a consideration. This may be tracked for the enterprise104itself and/or tracked at the provider system102based on the number/frequency of downloads of particular maintenance updates142across multiple enterprises.

The MAT128outputs an installation recommendation for an identified maintenance update in response to determining the assessment index. The recommendation can be in the form of reporting the raw value of the assessment index, a text/graphical recommendation, and/or an audio output. For example, various degrees of critically can result in a flashing red “urgent update needed” message along with an audible beep or tone, while a maintenance update that is deemed low impact can have a basic “update recommended” message. Additionally, the MAT128can block reporting of maintenance updates142that are deemed useless or fail to meet aging criteria (e.g., the fix has only been available for one week and the enterprise waits for a minimum of one month before accepting a new fix).

A decision log144can be provided in which choices made while using the MAT128are recorded. The decision log144provides a source of audit data to compare actions suggested with actions taken. The decision log144may also include note fields to document the user's reasons for installing or ignoring the maintenance updates142. The selected maintenance updates are stored as installed maintenance updates146. The installed maintenance updates146can be applied to update the applications120and/or122, in addition to other elements of the enterprise104that are not depicted.

In a similar fashion, the enterprise108is updated using its MAT128. The user system112interfaces to a data storage device148with a similar but independent version of the service inventory150, performing substantially the same functions as the service inventory130. The data storage device148may also include profile data152, a decision log154and installed maintenance updates156targeting the specific environment of the enterprise108instead of the enterprise104. The MAT128of enterprise108can also manage maintenance updates for the remote system114, e.g., updating application126. The MAT128may write installed maintenance updates158for the remote system114to data storage device160local to the remote system114.

The data storage devices132,136,148, and160refer to any type of computer readable storage medium and may comprise a secondary storage element, e.g., hard disk drive (HDD), tape, or a storage subsystem that is internal or external to the systems102,110,112, and114respectively. Types of data that may be stored in the data storage devices132,136,148, and160include, for example, various files and databases. It will be understood that the data storage devices132,136,148, and160shown inFIG. 1are provided for purposes of simplification and ease of explanation and is not to be construed as limiting in scope. To the contrary, there may be multiple data storage devices utilized by each system102,110,112, and114. Additionally, the various files and databases on the data storage devices132,136,148, and160can be combined within the scope of the invention.

FIG. 2depicts an example of an interactive interface200for maintenance assessment in accordance with exemplary embodiments. The MAT128of enterprise104or108may produce the interactive interface200and support access to the interactive interface200via the user interface116or118. In an exemplary embodiment, the interactive interface200includes a display list of a product/release identifier (FMID)202, a modification level of the code (SYSMOD) name204, an APAR number206, status associated with the system resolving the SYSMOD208, PTF availability date210, classification of problem212, symptoms of problem214, component affected (COMPID)216, users affected218, user notes220, assessment index222, and evaluated action options224. The status associated with the system resolving the SYSMOD208can provide status of the PTF itself, for instance, the PTF name, status indicating whether the PTF is considered good/functional, and whether the PTF has been received by the particular system running the MAT128. Since problems can be logged in the problem database138ofFIG. 1before maintenance updates142are created, the PTF availability date210can be used to determine when a planned PTF will be available and in aging calculations for released PTFs. The classification of problem212indicates the level of impact of a problem and whether the problem is attributable to an application or to a maintenance update, e.g., a HIPER. The symptoms of problem214may indicate the hierarchical level that the problem appears at, e.g., a particular function or pervasive. The COMPID216may identify a particular low-level software component that is affected by the problem. The users affected218can identify particular users, systems, or group of users that are affected by the problem identified by the APAR number206. The user notes220provides an interactive field for entering reasons as to why a particular PTF should be accepted, rejected, or delayed in installation. The assessment index222can output a numerical score based on weight of factors indicating the criticality of installing the PTF, which can serve as an installation recommendation. Alternatively, the assessment index222can be mapped to various recommendation messages indicating to the user whether the PTF should be installed and may optionally include reasons why the PTF should be installed.

Evaluated action224provides a list of available actions for the user to take. For example, a user may decide to install the PTF, install the PTF and remove the record for the APAR number206from the current display list of the interactive interface200, keep or retain the record to the APAR number206in the current display list, or remove the record for the APAR number206from the current display list. Selecting to install the PTF results in a request to copy or download the selected PTF from the maintenance updates142and write it to the installed maintenance updates146,156, or158depending upon the system affected. If a user decides to keep the record but not install the PTF yet, the reasons for this can be logged in the user notes220, which are then written to the decision log144or154.

Turning now toFIG. 3, a process300for maintenance assessment management will now be described in accordance with exemplary embodiments, and in reference toFIGS. 1 and 2. A user can initiate the MAT128of enterprise104or108to assess environment specific maintenance actions for the respective enterprise. The MAT128communicates with the provider system102to assess known problems in the problem database138and determine which problems have been flagged as critical via the critical update identifiers140. The MAT128can analyze each of the known problems to determine whether an update is available to remedy the problem and assist the user in deciding if the update should be installed based on a maintenance assessment index. At block302, the MAT128identifies a maintenance update (e.g., a PTF) in the maintenance updates142to address one or more known problems that are applicable for the specific environment of the enterprise of the MAT128, which includes one or more computer systems.

At block304, the MAT128applies factors to determine an assessment index for the one or more known problems as a function of the specific environment, where the assessment index indicates a level of installation criticality relative to the specific environment of the enterprise. The factors may include a level of importance as a function of one or more defect attributes associated with the one or more known problems, a level of exposure to the one or more known problems in the specific environment, and policies of the specific environment. The one or more defect attributes can include a classification and symptoms of the one or more known problems. The level of exposure may be determined by comparing problem triggers to the specific environment and further determined by pervasiveness of the one or more known problems. The policies can include an acceptable age of the maintenance update and specific components or functions with a higher degree of sensitivity. The profile data134or152may establish weighting values for each of the factors, allowing the MAT128to apply the weighting values to each of the factors to determine the assessment index.

At block306, the MAT128outputs an installation recommendation for the identified maintenance update in response to determining the assessment index. The output may be displayed via a user interface (e.g., user interface116or118) and can be formatted as depicted inFIG. 2. In an exemplary embodiment, the output is interactive to enable the user to select a recommended action and log notes as to why the selected action was taken. The MAT128can also store user decisions regarding installation of the maintenance update in the decision log144or154.

Technical effects of exemplary embodiments include using a maintenance assessment tool to create and track an assessment index for maintenance updates based upon an enterprise specific configuration and other known factors. Additional technical effects include tracking evaluations and decisions regarding installation of maintenance updates to fix known problems. The assessment index enables users to determine the criticality of installing updates with respect to the present environment and/or the planned future environment.