Archive

Posts Tagged ‘DITY’

DITY – Selling ITIL to the top

January 11, 2010 1 comment

Hank Marquis in this edition of the DITY newsletter writes about some points to follow while planning to sell ITIL to the top management of an organization. Here are the points

  1. Identify your unique business or mission drivers
  2. Determine ownership
  3. Identify audit and control requirements
  4. Identify stakeholder relationships
  5. Create a stakeholder map
  6. Translate
  7. Repeat

For more read the online version of the newsletter here, or download it here.

Advertisements
Categories: Good Read Tags: ,

Vital Business Functions – Article on DITY

Article on Vital Business Functions (VBF) on DITY. The article can be downloaded here.

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.