Configuration Management

Disaster Recovery Planning, Seven simple step

root — Sun, 06 Jul 2008 02:16:48 -0700

Step 1 – Admit the possibility of disaster
Just as the first step to personal recovery is admitting one has a problem, so the first step in BCDR planning is to admit the organization faces tangible threats that could jeopardize its prosperity – or its survival. Until this first step is taken at a senior leadership level, go no further.

Step 2 – List and categorize likely threats to the organization
The nature of the business and its physical and social environment will influence the types of threats an organization might face. Once the threats are listed, they should be categorized according to their likely impact on various systems. The cost of the response should be balanced against the tolerance for system downtime -- the less downtime that can be tolerated, the more it will cost to create an appropriate response. Some systems must be functioning again within minutes or seconds, while others can be down a few hours, and still others can be down for a few days without serious consequences.

Step 3 – Outline the organization’s BCDR technology infrastructure
The key technology elements

Penalty charges during incident management

root — Fri, 06 Jun 2008 02:15:41 -0700

Nothing focuses the mind quite like the possibility that the money you have earned through the diligent provision of valuable IT services could be ripped away from your clutches due to poor performance or non-compliance with previously agreed penalty clauses. Punitive penalties are common place within the IT outsourcing market place and can significantly affect the profitability, or indeed very survival, of the service provider.

Are incidents or performance levels that incur penalties clearly defined?
• Is the way non-performance is measured clearly understood?
• Are the penalties time boxed or can they accumulate indefinitely?
• Are service level periods defined? Are these based upon fixed periods or a rolling window of performance?
• Are penalties limited by an upper threshold?
• Are payment terms for penalties defined?
• Are there any arbitration processes described in case of disputes over penalties?

Capacity Management in ITSM Perspective

root — Wed, 04 Jun 2008 06:52:51 -0700

Capacity Management is a process used to manage the capacity of an IT service to ensure that it meets current and future business requirements in a cost-effective and efficient manner. As the usage profile of an IT service changes over time and the service itself evolves, the amount of physical computing processing power, data storage requirements, staffing levels needed to deliver and support the service also changes. If it is possible to understand the demands being made currently, and how they are likely to change over time, then the planning for growth or shrinkage becomes easier and less reactive i.e. painful. If there are peaks in, for example, the processing power consumed by the service at a particular time of the day,

How to manage CMDB Scope

root — Mon, 02 Jun 2008 18:28:32 -0700

Although a CMDB can be extremely complex, it is built of only two elementary constructs, called configuration items and relationships. Configuration items represent static portions of the IT environment, such as computers, software programs, or process documents. Relationships, as the name implies, track how these configuration items are related to one another, and are much more dynamic because these relationships can change frequently. Given these simple building blocks, defining the scope of a configuration management system is as simple as deciding which types of configuration items you want to track and which relationships will be important.

Note that we define scope as which types of configuration items will be tracked, not which configuration items. Once we decide that a particular type of thing is going to be tracked, it becomes part of our scope, even if we choose to track only a single instance of that type of thing. The choice of how many of each type, and exactly which ones, is part of the span of the CMDB

Making Good Decisions with CMDB

root — Sun, 01 Jun 2008 22:46:23 -0700

Consider, for example, the many decisions that are made around the cost of support. Should we outsource our IT support? Perhaps we can move some of the support off shore to leverage lower labor rates. How much longer should we support those old dot-matrix printers? Is the value of the redundancy really worth the cost of supporting the load balancer? These are just a few of the many questions that come up around support costs in IT shops every day. In an era of global economic competition, making wise decisions can be a matter of survival. But wise decisions are fueled by adequate information. Having an accurate CMDB allows the IT manager to understand which components of the infrastructure fail most often, how much change activity is occurring to antiquated equipment, and when to drop support of certain applications or types of equipment.

Although configuration management should never be confused with IT asset management, there is certainly value to having more information as part of the IT purchase cycle. The CMDB can help determine when it’s appropriate to refresh hardware sooner than expected, or when it is acceptable to let the refresh cycle lag behind the original schedule. If a server is hosting businesscritical applications and has had a whole series of minor incidents reported against it, it might be time to escalate the refresh time of that server, or perhaps swap it into a less critical part of the environment. But rather than simply deciding based on the annoyance of the most recent incident, you can have concrete information from the CMDB on which to base this kind of decision.

Where do you go to get good requirements for ITIL?

root — Sat, 31 May 2008 03:23:29 -0700

So where do you go to get good requirements? The best place to start is where you are. Most likely you are involved in building configuration management because of your role in the enterprise. Look at your job description. If it says anything about configuration management, those are probably some requirements. Look at the problems that you, your team, and your organization are experiencing because you don’t have good configuration data. Those problems are a great place to look for a description of what’s needed. Attend some incident management meetings— document what you learn about how configuration data could help, being careful to get only configuration management requirements. Do the same with meetings regarding change approvals, capacity planning, or service levels. In each of these disciplines, you’re likely to discover some way in which configuration management data could help. In addition to these formal meetings, you also want to talk to people both inside your organization and in other organizations who are implementing ITIL. All these areas will help you when looking for requirements.

Certainly you’ll want to schedule time with your stakeholders. Anyone who has a dream, hope, wish, or expectation of configuration management is a stakeholder, and the more of them you can listen to,

How to choose configuration management tools for ITIL compliances

root — Fri, 11 Apr 2008 18:31:59 -0700

Configuration management tools basically come in three different flavors:

Tools to discover configurations in the environment,
Tools that are dedicated to creating a Configuration Management Database (CMDB),
Suites of service management tools that include some level of configuration management capability.

1. Discovery Tools

The strength of point solutions:
Capability captures the target environment with the highest possible accuracy. Because of their narrow focus, and because the publishers of these tools are often in significant business relationships with the suppliers of the components they discover, point solutions are often the first tools capable of identifying the latest infrastructure components. If your organization lives on the leading edge of technology, this may be a significant factor in the choice of which discovery tools you use.

Sample tools: Cisco Routers, Novell Network Directory Service

The weakness of point tools:
Cover only a narrow piece of the overall environment. To get complete coverage across the entire space often requires a hodge-podge of tools and a significant amount of integration effort to get data from all the point solutions into a single integrated CMDB. More tools to purchase and more integration to perform generally leads to a higher cost of initial implementation and ongoing maintenance.

Sample tools: Microsoft SMS, CA Unicenter, Opsware, IBM Tivoli Configuration Manager