Browse Prior Art Database

Centralized Change Execution System through Environment and Asset Suitability Analysis Disclosure Number: IPCOM000227832D
Publication Date: 2013-May-21
Document File: 4 page(s) / 199K

Publishing Venue

The Prior Art Database


In IT services industry, organizations perform change management (execute changes) in a business critical IT environment time to time to keep customer environment secure, available and to meet growing business demands as per the contractual obligation.

High level or subtle nature of many of the changes on the infrastructure or application layer is repeating/same on a frequency basis. Some real world examples are as following:

- SAN (storage area network) augmentation to meet growing storage demands - Critical security patching - Cluster failover test - Housekeeping - Replication syncing test (in DR) - Upgrade or enhancement release to be replicated across etc.

Currently, administrators either tend to reinvent the wheel i.e. prepare technical plans every time or reuse existing assets to perform a change management on an infrastructure or application layer.

The problem with the known practices are as stated below:

Even if asset (technical plans) exists, still requires significant resources and labor hours (a real world experience, for SAN augmentation change, it required 4 system administrators, 1 PM, 1 storage administrator and 1 Backup/restore administrator where as assets i.e. last time change technical plans were still existing that were successfully executed in the same environment) No intelligent analysis on the applicability of the same asset in future. No mechanism that tells if existing asset can be reused. Puts the customer environment and production at high risk if the same asset is reused without any robust analysis. Perception or temptation is to reuse the existing asset, if asset is reused at first place otherwise it is like reinventing the wheel. No analysis what needs to be changed in the existing asset so that it can be successfully applied in the changed dynamic environment. No alerts on the changed environment in real time so that asset can be modified to suit the dynamic environment. No mechanism for modification of assets based on the detected changes in the environment where it was executed successfully. No automated execution of the modified asset when required on the end points. What has changed in the environment and what needs to be changed in existing asset that was executed in the same environment in the past to ensure it can meet the requirement of the change or dynamic environment for the actual execution time i.e. no mechanism to perform fit-gap analysis between the dynamic environment and the existing asset. Isolated change management and asset management threads (no integration).

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 64% of the total text.

Page 01 of 4

Centralized Change Execution System through Environment and Asset Suitability Analysis

Overall Solution Architecture:

Solution functioning work flow:

i) Pre- execution phase:


Page 02 of 4

Description of Fig. 2:

1. Master system triggers for ADDS to discover, chalk out dependency and map for an application environment/systems

2. ADDS system discovers the whole application environment

3. ADDS produces map ADDS-Env1-1

4. ADDS uploads the map to master system

ii) Execution phase:


Page 03 of 4

Description of Fig. 3:

1. Manual execution of the change in an application environment Env1 or systems by system administrators

2. If change is successful, all the executions are recorded and uploaded by the master system agent to the master system. Hence we can see that at this repository has two assets i.e. map of the application environment where change has been executed (ADDS-Env1-1) and a change technical plan (s) that was/were executed successfully for a successful change (Ch-Env1-1)

iii) Similar Change Future Execution First Time Repeat:

Description of Fig 4:

1. Master system triggers for ADDS to rediscover, rechalk out dependency and remap for the same application environment/systems

2. ADDS system rediscovers the same application environment

3. ADDS produces new map ADDS-Env1-2

4. ADDS uploads this new map to master system

5. Master system analyzes the differences between previous (ADDS-Env1-1) and current environment (ADDS-Env1-2). If no difference is found, 6a->...