IT Governance, Risk, and Compliance » CMDB

Managing the IT Configuration – Part VIII

Robert Davis — Tue, 01 May 2012 22:24:56 +0000

An IT maintenance request requires analysis of all incidents and problems generated in the entity’s production environment. However, assigned IT service support personnel should make problem evaluation their final step prior to correction. Sequentially, within the evaluation process, an entity’s major problem management tasks should include: resolving problem causes, investigating and diagnosing the root cause of the problem, identifying and recording known circumstances, assessing known circumstances, recording the known circumstances’ resolution and requesting appropriate changes.

IT service support management has a proactive role in identifying application or infrastructure weaknesses and ‘areas of concern’ within the entity’s deployed IT architecture. Once adverse trends are recognized, service problems should be highlighted and corrective action initiated. For instance, a known circumstance can be forwarded to service support change management personnel or used for employee education and training.

“View Part I of the Managing the IT Configuration series here“

Managing the IT Configuration – Part VII

Robert Davis — Fri, 27 Apr 2012 22:19:29 +0000

An IT service problem can be viewed as a demarcated and identified condition extracted from a single incident or multiple incidents exhibiting common symptoms. Initially, the IT service problem is an unknown circumstance awaiting identification and attribution. Through successful problem root cause analysis, the unknown circumstance converts to a known circumstance representing an identified condition where a CI is confirmed as the resource defect. Therefore, a primary problem management process objective should be ensuring IT services stability by identifying and removing known circumstances negatively affecting deployed IT. When cascaded, the primary goals of the Problem Management process are to minimize the adverse impact of known circumstances affecting IT service delivery and to prevent recurring incidents related to known circumstances that can affect IT service delivery. Furthermore, the reactive aspect of these goals is to quickly solve problems in response to one or more incidents; whereas, the proactive aspect of these goals is to reduce the overall number of incidents.

“View Part I of the Managing the IT Configuration series here“

Managing the IT Configuration – Part VI

Robert Davis — Wed, 25 Apr 2012 14:51:19 +0000

Cascading from the primary release management objective, the primary release management goal should be to ensure approved and accredited components are installed malfunction-resistant and on schedule. Consequently, the high level activities associated with this process should encompass: release planning, CI distribution and implementation into production, as well as definitive software library (DSL) and definitive hardware store (DHS) management.

Commonly, change tracking and change oversight practices are necessary but not sufficient to achieve acceptable CI performance improvements. Specifically, there are a variety of potential IT service threats that can convert to intentional or unintentional incidents requiring adequate IT service support. If restoring service normalcy as swiftly as possible and minimizing adverse impacts on entity operations are the primary incident management process goals, then IT support personnel achievement of expected performance levels ensures that the highest possible service quality and availability levels are maintained.

“View Part I of the Managing the IT Configuration series here“

Managing the IT Configuration – Part V

Robert Davis — Fri, 20 Apr 2012 20:41:00 +0000

Once change tests prove satisfactory functionality, most IT CIs should be moved to a secure staging area. Subsequently, a release request should be submitted to the appropriate individual for production implementation. Upon notification of a successfully released change, documentation updates should be delivered to the individual directly responsible for the CMDB. Moreover, a change review should be performed to assess change process performance and development adequacy.

Within the change management process, release management is the practice of software development, installation as well as support for software control and distribution. The primary release management objective should be to ensure that only authorized and correct versions of software are made available for operational production usage.

“View Part I of the Managing the IT Configuration series here“

Managing the IT Configuration – Part IV

Robert Davis — Wed, 18 Apr 2012 21:21:16 +0000

Even a small change in a CI could cause a mission-critical application to fail or disrupt a service. To reduce the likelihood of undesirable consequences, thorough change planning is required for adequate change construction including: back-out planning, change testing and documentation updating. As a particular, back-out planning is necessary should the change result in an unacceptable configuration state. Additionally; since most information systems are frequently too large, integrated and complicated for service design failure or success to be predicted without testing, experimentation should be built into the change process. Lastly, CI documentation affected by the change should be correlated for updating to ensure appropriate resource utilization and maintenance.

“View Part I of the Managing the IT Configuration series here“

Managing the IT Configuration – Part III

Robert Davis — Fri, 13 Apr 2012 20:19:54 +0000

Change management is the practice of ensuring all CI alterations are carried out in a planned and authorized manner. Change can occur for various reasons including response to business process needs, the availability and introduction of new technologies, as well as normal business growth. Changes can be permanent or temporary. However, change management procedures should reduce and provide adequate responses to anticipated or unanticipated incidents as well as problems.

Receiving the request for change (RFC), logging the RFC, assessing the incident or problem, obtaining authorization to perform the change, and planning the change are procedures that should precede change construction. Minimally, the RFC should provide the business or technology reason behind each change; identify the specific CIs and IT services affected by the change; cost estimates; risk assessment; resource requirements; and support process approvals. Logging the change permits tracking and records the RFC has passed initial documentation requirements. Assessing the incident or problem provides analysis and evaluation enabling change prioritization and categorization. To construct the change, IT service support should obtain proper authorizations for the change from the appropriate business and technical experts responsible for change deployment. Furthermore, change planning provides the means to ensure successful change development.

“View Part I of the Managing the IT Configuration series here“

Managing the IT Configuration – Part II

Robert Davis — Tue, 10 Apr 2012 21:23:55 +0000

Enabling accommodation of essential configuration management requirements is the implementation and control of a database (commonly referred to as a Configuration Management Database (CMDB)) containing details regarding infrastructure elements that are utilized in IT services provisioning and management. To ensure successful configuration management, relevant inventory management ‘best practices’ adoption is required. However, when properly deployed, the CMDB is more than an ‘asset register’ since the database should contain information that accurately portrays the maintenance, movement and issues experienced with CIs enabling superior IT service practices.

Active IT networks can be defined as the functions performed by CIs and the interfaces, structure, as well as protocols utilized to enable service execution. Therefore, a fully configured IT network architecture creates a single uniform communication mechanism enabling utilization by resources distributed throughout the IT infrastructure. Consequently, networking architectures have a pivotal enabling role when in-depth information assets protection (IAP) is the operational objective.

“View Part I of the Managing the IT Configuration series here“