Configuration Management

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

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 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,

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

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.