Save the IT recipe!
Document Actions
CMDB as disaster recovery tool
A recent Gartner note encourages enterprises to use IT Asset Management
(ITAM) data as a means of risk reduction for disaster
recovery. The May 18 note titled “Findings for IT Asset
Management Beyond 2008”, Gartner’s Jack Heine explains:
“An effective IT asset management practice is an essential part of any disaster recovery plan. The ability of the IT organization and the business to re-provision infrastructure resources depends on the availability of accurate asset information for installation services and insurance claims. To ensure that your business can survive a disaster, you need to include the entire computing infrastructure in recovery plans.”
Although Gartner doesn't say so, I believe disaster recovery
highlights yet another reason to build your ITAM program on a Configuration
Management Database (CMDB) rather than
a traditional, stand-alone asset repository.
The importance of maintaining IT asset documentation to aid in disaster
recovery time is not new, and has typically focused on the administrative
aspects of recovery. IT needs a record of which critical assets to
procure and re-provision to get business services operational again, and
finance will require documentation for insurance, budget and reporting.
This has long been a value attributed to asset repositories with their
basic “flat” representation of assets and associated financial and
contractual data. From an operational standpoint, however, this
list of assets isn't particularly helpful in knowing how to put the pieces
of IT back together. In other words, asset repository can record
a list of many of the ingredients of your production IT environment, but
not the recipe. A CMDB’s depictions of assets (CIs) goes further
toward supporting disaster recovery in several important ways:
- CMDBs are about relationships, documenting how different technical components inter-relate to support business services. (Topology discovery tools are also essential in populating and maintaining this relationship data into the CMDB.)
- Configuration data for a given asset (CI) is richer than a basic asset repository. For example, a CMDB can tell you not only what servers you had but also what OS and application software was on them and how that software was configured.
- A CMDB can also be related to a Definitive Software Library (DSL), providing an authoritative source on information on where your “golden copies” of software are.
Although not quite a step-by-step cookbook for rebuilding IT, a
CMDB provides far more of the recipe needed for disaster
recovery than traditional asset repositories’ list of
ingredients. Using a federated approach, your ITAM data on
costs and contracts should be associated to the CIs in your CMDB.
This will give you a financial picture of the ingredients as ITAM always
has, and also how that asset relates operationally to other assets and the
business service(s) they provided.
This leads us to another best practice: just as you do (or should be
doing!) for critical business data, you should maintain an archive of CMDB,
ITAM and DSL snapshots in at least one separate geographic location
from your main center of operations. This way, if disaster
strikes, your recipe isn't lost. In other words, treat your CMDB
data not just as a list of assets, but as a corporate asset in
its own right.
_____
tags:
Forgot your password?
New user?
