Archive

Archive for the ‘Configuration Management’ Category

CMDB or CMS

Glenn O’Donell writes in his blog on ComputerWorldUK. Please click here to read more…

IT Service Management Starts with?

January 24, 2010 1 comment

According to Mark Schouls, the three processes that IT Service Management starts with are Change Management, Configuration Management and Release Management.

Release Management – Proper release management, which defines the process of building and releasing software, results in a greater success rate in the provisioning of software and hardware to the business, and perhaps more importantly, results in a perceived improvement in the quality of service. Bringing consistency and documented processes to software and hardware releases minimizes downtime, reduces support costs, improves resource utilization and increases confidence across all levels of management.

Configuration Management – Enacting configuration management processes gives organizations a single view of all corporate assets, including their dependencies and interrelationships. Having one federated repository as a point of reference ensures accuracy and eliminates time-consuming duplication of efforts.

Change Management – Codifying change management practices helps organizations better align IT services to business requirements. With rigid processes in place, they eliminate rogue changes, thereby reducing risk and improving user productivity. To undertake change management initiatives, businesses must first accurately assess risk, understand the impact due to any change, analyze resource requirements and make adjustments to align resources as required. At that point they can enact a formal method for approving changes.

Read more of this article on ITSMwatch here.

I would also put Incident Management in this list. IT has to exist in the organization in some form or the other right from the start. Incident Management is one of the key bridges between the IT and its users. It gives a first hand information about the issues which are being faced by the users and would be a key driver for a lot of changes that would be done to restore services.

Relationship between ITIL Processes – 1

Basic! yes! very! But don’t be surprised if there are people who have been managing these processes and still do not completely understand these relationships.

This diagram however cannot be termed complete and there is a lot that can be added to it. Will write about the process relationships in detail in the next few posts!

Black and White of Configuration Management

A term mostly used either with printing or photography, but I use it to today in Not Just ITSM to link to two very different thoughts on CMS or Configuration Management System as most would know it!

In the latest DITY newsletter,  Carlos Casanova has written about A-FIRM structure for CMS and mentions CMS as a successful IT System. A-FIRM stands for

A – Architect: Architect and map out your ascent before actually setting out on your climb. If you do not do this, you will be lucky to reach a base camp from where to launch your serious climb.
F – Federate: Determine which camps may already be well established along your climbing route and which you can leverage on your ascent. These are components that you must factor into your long-term solution and are vital to any success you achieve.
I – Integrate: You will not be able to carry all your supplies on your journey so seek out others who can provide insight and assistance. Be on the lookout for those who may have already succeeded in partial ascents and can work with you to reach the peak. There will be times where you will have to leverage these for short periods of time until you can find a more sustainable long-term solution to accomplish that portion of your climb.
Compared to Federated components, these components are ideally just short-term solutions. They may be able to mature into a long term-federated solution, or they will need to eventually be replaced by a different long-term solution.
The key is to recognize which of these two categories they fall into. Wrongly assess a short-tem stopgap measure as a long-term solution, and you may die on the mountain during your climb because of faulty or incomplete data provided by them.
R – Reconcile: This will likely be one of your most challenging tasks because you will undoubtedly face many situations where you need to make a critical decision armed with less-than-ideal data. These decisions will make or break your entire ascent. Choose the wrong data and your team dies on the climb; choose the right data and you have a chance to succeed. Notice that there are no guarantees of success even if you choose the correct data.
M – Merge: Over time, you will identify situations and groups that you can combine to provide more reliable data and/or support you on the next leg of your ascent. You need to carefully execute these mergers to ensure you do not negatively impact the value you are seeking to achieve. Eliminate the wrong data or people, and you endanger the entire mission. Do it properly and you reach the peak faster, with less risk and at a lower cost.

Read the newsletter here or download a pdf here.

On the other hand, Rob England, the IT Skeptic writes at length about CMDB and CMS being an Industry created myth.

These two are masters of their trade, and have very different views on the same topic. In my limited experience with CMDB, I cannot help but agree with both of them right now. Also I feel that CMDB is a term that is very loosely used by many without realizing or knowing the content that should go in there… For a lot CMDB is the solution to all their problems, and now CMS is the solution to all their problems. I, however, think that CMS or CMDB being the solution to a problem is just a hypothesis, which needs to be proven right or wrong after the roll-out. Small or big, simple or complicated, CMDB or CMS, would NOT work, if one is not aware of what the objective of creating it is for the organization and what we want to achieve from it.

Real world experiences of CMDB success

September 15, 2009 Leave a comment

A very good article and presentation on CMDB Success by Gaurav Uniyal, a lead consultant with Infosys Technologies. In this presentation, and post, Gaurav touches upon some of the key practices to be kept in mind while designing and implementing a Configuration Management solution.

  1. Know what could be delivered and how
  2. Baseline current processes and technology landscape
  3. Structured Requirements Gathering
  4. Analyze impact of the roll-out
  5. Develop processes to extract value out of the roll-out

Click here to read through the post or see the presentation.

Numbered points have been taken from Infosys ITSM Blog

Configuration Management – Do you see both sides?

Two different points of view on CMDB

1.  A whitepaper by David A. Messineo (CA) on Myths of Configuration Management Data Base. He mentions the 7 key fundamental use cases for CMDB in this whitepaper, and talks about some myths around CMDB.

7 Use cases for CMDBHe also classifies the myths into various categories such as

  • Conceptual Myths – growing around the manner in which CMDB has been described in the ITIL Books or similar material
  • Process Myths – focused around the manner in which the CMDB supports ITIL processes or business processes in general
  • Organization Myth – focused around the manner in which the CMDB, through the adoption of ITIL, will improve organization execution and organizational communication.
  • Technology Myth – is the idea that a CMDB that is built or bought will just work as designed.

David then goes on to discuss in detail some myths around CMDB putting then into these categories.

A different point of view and comments can be read on IT Skeptic’s page here. He describes in detail some of the big challenges that he sees with CMDB the way ITIL describes it and implementation issues.

Most text from the Myths of CMDB whitepaper