IT Asset Management and ITIL
Document Actions
ITAM and ITIL and CIs... Oh My!
A topic I see many of our customers and prospects grappling with is how the familiar discipline of IT asset management fits with the relatively newer concepts around CMDB's and ITIL's "Configuration Management"
Beginning in the late 1990s, IT Asset Management created a unique mandate in IT: to reach across technical and organizational silos in order to account for and manage all IT assets in the enterprise. Sure, some data about IT assets would always stay inside specialized tools (application development, UNIX or WinTel administration, network management, etc.) But as IT became a larger and more mature part of the business, the need for a cross-platform approach to business issues such as IT procurement, cost accounting, and compliance became increasingly apparent. And so did the need for a repository of enterprise assets.
Now, the growing popularity and maturity of IT Infrastructure Library (ITIL)-driven initiatives introduces a similar mandate: to account for all IT components (Configuration Items or “CIs”) and their inter-relationships in a Configuration Management Database (CMDB). In ITIL terminology, this discipline of establishing and maintaining a CMDB is called Configuration Management. So now there emerges a critical operational role for a unified repository of information about IT components.
To date, IT Asset Management (ITAM) is conspicuously missing from the list of key processes needed to "run IT like a business". ITIL has not been particularly clear on ITAM's role and fit with ITIL processes like Configuration Management. Do ITAM and Configuration Management have redundant mandates to account for IT components, resulting in an asset repository in one organization and a totally separate CMDB in another? How does an asset repository differ from a CMDB, or an asset from a CI? Is much of ITAM’s role becoming subsumed by ITIL?
Wading Through Terminology
The term "IT Asset Management" is subject to broad interpretation, creating a semantic trap where almost anything in IT can be called an "asset," and anything done to it is "management." For example, a server is certainly an IT asset. Proper configuration of a server can be said to be part of managing that server. But if a server needs to be reconfigured with an application or OS patch to stop a memory leak, is this an "Asset Management" function? Most (but perhaps not all) organizations would agree that patching servers falls well outside the responsibility and expected skill set of ITAM.
What if you use a discovery tool to see what you have deployed in your IT environment – is this "Asset Management"? The answer depends on what you will do with this discovered data. Asset Management relies on discovery data as a starting point, but requires additional processes, strategies and data to manage discovered entities as assets. When you use the discovered data to manage software licenses, track leases or reconcile invoices, then you are performing asset management. Since many discovery tools are marketed by vendors as "Asset Management solutions," it is no wonder that a single tool (discovery) is often confused with the broader discipline of IT Asset Management.
Many disciplines other than IT Asset Management rely on discovered data — from change and incident management to network and datacenter operations. Indeed, many companies use basic "asset repositories" either partly or solely to support service desk operations, such as incident, problem, and change management. For example, a database of which assets are used by which employees is helpful to resolve incidents more quickly, eliminating the game of "20 questions" between the technician and user so that troubleshooting can begin with knowledge of the exact make, model, version, and configuration of desktop, printer, or application is creating the incident. But is this "Asset Management?"
Admittedly, all definitions of IT processes (or any business discipline for that matter) are imperfect, but for the purposes of this discussion let's stipulate a working definition:
IT Asset Management is the discipline of managing finances, contracts and usage of IT assets throughout their lifecycles for the purpose of maintaining an optimal balance between business service requirements, total costs, budget predictability, and contractual and regulatory compliance. Traditional ITAM activities include the management of inventory, software licenses, vendors, procurement, leases, warranties, cost accounting, retirement and disposal.
Thankfully, ITIL's Configuration Management is easier to describe since ITIL is responsible for popularizing the concept, and because its mission includes forging agreement on terminology. To summarize:
The goal of Configuration Management is to provide a logical model of the IT infrastructure that is accessed by all ITIL processes to drive consistency among them. Activities include identifying, controlling, maintaining, and verifying the versions of configuration items (CIs). This CI information is to be stored in a single repository – the Configuration Management Database (CMDB).
So far, so good. But there's one more definitional issue to attend to: ITIL doesn't hold a monopoly over the term "Configuration Management".
Many analysts, vendors and IT practitioners use "Configuration Management" to mean maintaining the configurations of devices (such as servers and networks) in the real world. The reason for pointing this out isn't to start a debate on who has the best definition. But we need to at least be aware of the differing meanings, lest an otherwise productive conversation quickly turn into an episode of Three's Company (whose many plotlines and madcap hijinx started with a simple misunderstanding...) Anwyay, I've found it helpful to refer either to "ITIL's Configuration Management" when talking about documenting/modeling the configuration of an IT environment, or to "Software Configuration Management", "Server Configuration Management", etc. when talking about making physical changes to the infrastructure.
With these definitions and descriptions in place, it’ll be easier to draw both contrasts and comparisons between ITAM and ITIL’s Configuration Management. More on that later... Meanwhile, what do you think?
_____
tags:
IT Environments Management
I have been asked the question several times as to what exactly is IT Environments Management and I have noticed that on the Internet there is not a lot written on it. Having worked as a Consultant IT Environments Manager for several years I decided to share my understanding of the concept. I am quite happy to respond to comments or other views etc.
Application or IT Environments Management service will fall under Application Management as defined in ITIL2 (operational guidance) because it contributes to improving the overall quality of IT Software development and support through the lifecycle. Application Environments Management set encompasses a set of best practices proposed to provide an effective, end to end management service for test software platforms or development environments. The software test bed or development environment could consist of a client server application, Relational Database Management System (RDBMS), middleware, interfaces, daemons, customised processes (written in any software programming language), FTP utilities etc.
Functional test phases such as Unit, Integration, Acceptance, all manner of
performance or non functional testing and development phases all require Application Environments.
The primary clients of an Application Environments Management service are Software Project and Test teams.
The service will cater for the following;
· Manage the creation, build, upgrade and support for all test and development Application environments
· Clearly defining auditable processes of allocating application environments,
multiple bookings or shared usage, code upgrades, service level agreement,
support, decommissioning and re-allocation.
· Manage data refreshes, collating test data and assist in the anonimising of
production or other sensitive data if necessary.
· Supply, provision and manage all Application Environment Requirements
from the Project and Test teams all through the software development cycle
of a project.
· Assist the Project in establishing their application environment
requirements, provide expert knowledge on the APPLICATION
environment’s set up, connectivity and serve as a guide to the projects in
using the application environment in the most efficient manner.
· Review and contribute to the Project Initiation Document (PID) ensuring
that the IT Environments Management function and its deliverables are
clearly defined and captured.
· Create and maintain project plans to assist in managing all activities
required to successfully carry out major code upgrades to all application
environments.
· Provide reports on usage/utilisation, availability, forward planning and schedules.
Application Environments Management is clearly a new and emerging area which has arisen due to the following reasons:
· The increased Application Environment requirements for many companies who have several software projects running at any one time.
· The increased levels of interfacing and connectivity between several systems in most organisations also known as spaghetti. For example in some
companies more than thirty systems are interfaced or connected with each
other exchanging files and data flows etc and has meant that any changes to
one system most times could require a change to many others and then require
large numbers of test and development application environments.
· Increased awareness and more commitment to carrying out rigorous software
testing especially with more companies opting to use the Prince 2
methodology and ITIL Framework
A typical Application Environments Management tool should be able to provide
the following services: environments bookings and allocation, manage multiple
bookings and re-curring bookings. Provide reporting on usage, availability,
interconnectivity or interfacing environments, utilisation and conflict reporting
etc. It must also serve as a repository of all information on an Application
Environment to include Host Server names, Hardware Type, Operating System, IP
Address and Interfaces if any.
The ideal background for an Application Environments Management personnel
could be Software Development, Application or Technical Support, Infrastructure
Project Management, Configuration and Release Management etc but must be
exposed to at least the ITIL Framework, Client – Server development, System
Architecture/Design, Networks, TCP/IP and Messaging systems etc.
Terminologies defined & explained:
Application Environment – A single test bed or development platform instance of a
software application or system that can also be used for all manner of functional and
non functional testing or could be the production instance (production environment).
It could also be large, medium or small which normally refers to the size of data the
RDBMS will be holding depending on the type of testing it is required for.
Integrated Application environments (also known as stripes): More than one
application environment connected to each other also communicating with each other
and exchanging files and data flows. Connections could be via Microsoft ODBC, via
FTP, TCP/IP, daemons, middleware, defined interfaces and database links etc.
Anonimising of data
Anonimising of data refers to the manipulation or transformation of production data
held in the RDBMS such as Oracle, SQL Server, Sybase, Microsoft Access, DB2 etc
to be used in a test or development Application Environment ensuring that for
example real names, addresses, date of birth, bank account details and other sensitive
information or data is transformed to dummy data.
The data is transformed whilst still maintaining its defining characteristics in a
Relational Database Management System table such as character length (Char 25 or
Varchar 50) etc to ensure its usage in testing or development is not compromised and
that the integrity is maintained. For example a valid name such as John Smith defined
as Char 10 will now be updated in the table to become possibly a unique character
string XXXXXXYYYY (comprising of ten characters including the space between
John and Smith).
Pipe cleaning
Pipe cleaning caters for the all the activities required to be carried out before a test or
development environment is handed over to the Test or Project team and includes disk
clear down, archiving and purging logs, importing test data, killing off rogue
processes, resetting passwords, changing environment settings, end to end
connectivity or integration tests to make sure everything is working okay.
Depending on the complexity of the system a checklist of activities may be required
and ticked off capturing all the checks and tests that have been completed on an
environment or an integrated suite of environments prior to its hand over to a Project
or Test team.
Smoke Test
A smoke test describes an initial end to end test of all the integrated or even stand
alone environments very possibly using dummy data and carried out by the support
teams who have created or built the environment or by the test team when the
environment is handed over.
Free download of an environments management tool coming soon here…………….
About the author
Valentine Waturuocha MSC, HBS(ED) is the author of this document and still
provides IT Environments Management consultancy services till date.
Email: waturuochav@hotmail.com Date: 03/11/07
Forgot your password?
New user?
More than half of IT's expenditures come from bought hardware, software and telecommunications; fully two-thirds of IT's expenditures are outside. Despite this there is no other group within most organizations than IT Asset Management that focuses on the issues related to cost-effective acquisition and management (financial and contractual) of IT infrastructure. Effective standards controls and strategic sourcing with a mind to the special needs of IT matters quite a bit.
I think you're missing a LOT. A lot of value is left in the gap between the amateurish approach of the highly-dispersed tactical acquisitions by operationally focused individuals and throughput-minded Procurement personnel.
Cary King
Minerva Enterprises