Hi Everyone! I am new to the forum and I am learning a lot. So here is my question, I am starting a CMS/CMDB from scratch for a huge city. We are waiting for HP SM9.3 to be implemented by the end of the year. Right now I am tasked to implement an interim Comfiguration Management process.

Currently I am doing the following:
- Collecting CI Data from a Qualys Report and a Application Repository tool
- I am dumping everything on a csv file given by HP so that when the tool is available we can just upload the data including CI relationships
- Meeting with Business units if they have CI data that we can add to the list

I would like to know if anyone has the experience of building CMS from scratch and can you share the strategy you used?
Can you comment as well on the strategy that I am using right now.

you really need policy, objectives and procedures in place before you decide what data to gather, before you decide what relationships are important, before you decide what granularity to apply to your CI structure.

Are you not talking to the IT units about what they can use and how they want to use it?_________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

Hi Everyone! I am new to the forum and I am learning a lot. So here is my question, I am starting a CMS/CMDB from scratch for a huge city. We are waiting for HP SM9.3 to be implemented by the end of the year. Right now I am tasked to implement an interim Comfiguration Management process.

Currently I am doing the following:
- Collecting CI Data from a Qualys Report and a Application Repository tool
- I am dumping everything on a csv file given by HP so that when the tool is available we can just upload the data including CI relationships
- Meeting with Business units if they have CI data that we can add to the list

I would like to know if anyone has the experience of building CMS from scratch and can you share the strategy you used?
Can you comment as well on the strategy that I am using right now.

I appreciate all your help! Cheers!

Hi Ricky,

I've built many CMDBs and Configuration Management solutions (processes, tools, technologies, roles, responsibilities, etc.) from scratch.
Good configuration management is usually a function of great data governance. In addition to the responses you've gotten from others, here are some of my recommendations...

- Identify the CI Types that you want to collect and track. This should include, both, technical CI Types and non-technical CI Types (i.e. Business CIs).
- Identify who owns and is responsible for the CI sources. You will need to work out processes with those owners to properly populate and publish such information.
- Identify what attributes are important to collect and maintain for each CI Type. The CI Type owners will be responsible for collecting and maintaining the data in these CI inventories
- Identify if any Master Data Management needs to be applied to multiple CI sources in order to create Single Sources of Truth (SSoTs) that don't exist. This is mostly true in the case where you get conflicting data about one CI from multiple different sources (for example, you get a Person and their Location from different sources and the Location data is conflicting but both are correct).
- Identify what relationships are important between CI Types and how you will generate, store, publish and maintain such relationships. Most people that get into Configuration Management have no clue as to the work they're committing to, when they say they will manually maintain relationship data. Look for ways to automatically harvest and maintain relationship data through automated scripts.
- Identify how you will catalog and order all CIs, for the benefit of those who need such data.
- (As mentioned in other responses), Identify all CI Data Governance Collection, Maintenance, and Publishing Processes and the owners of such Processes, so there is complete accountability.
- Identify all roles and responsibilities in the CI Data Governance, Collection, Maintenance, and Publishing Processes.
- Identify the ROI of your Configuration Management solution, including all People, Tools & Technologies, etc. Your business will want to know it, at some point.

Purpose, policy, objectives and process have to come before building a CMDB if you want to have firm foundations and not be wasting time and money. It is helpful to emphasise that.

Quote:

Good configuration management is usually a function of great data governance

Eh? Do you mean that the quality of data governance is dependent, in part, on the quality of the configuration management performed?

Quote:

(i.e. Business CIs)

Do you mean "e.g."? I hope so.

Quote:

Single Sources of Truth (SSoTs)

Not exactly plain English! more like gobbledygook.

Quote:

Identify the ROI of your Configuration Management solution

ROI is extremely hard to pin down in this area. It is not measurable in any meaningful way in isolation from the other processes and activities that are closely integrated with configuration management. If you must do it, then it would be more honest to attempt to measure the ROI of the project than of the "solution". The project can have defined projected costs and benefits, but the "solution" is far too abstract a concept and using it leads to the overwhelming temptation to idealize the values - just like a salesman/consultant might do.._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

Last edited by Diarmid on Wed Sep 19, 2012 5:40 pm; edited 1 time in total

Hi Everyone! I am new to the forum and I am learning a lot. So here is my question, I am starting a CMS/CMDB from scratch for a huge city. We are waiting for HP SM9.3 to be implemented by the end of the year. Right now I am tasked to implement an interim Comfiguration Management process.

Currently I am doing the following:
- Collecting CI Data from a Qualys Report and a Application Repository tool
- I am dumping everything on a csv file given by HP so that when the tool is available we can just upload the data including CI relationships
- Meeting with Business units if they have CI data that we can add to the list

I would like to know if anyone has the experience of building CMS from scratch and can you share the strategy you used?
Can you comment as well on the strategy that I am using right now.

Hi Ricky,

i've built many CMDBs and general Configuration Management solutions from scratch.

Dumping to CSV files is a good start. However, creating Relationships between relevant CIs, both within a single CSV file and across different CSV files, will be an area where you will have a challenge. One of the biggest issues with CMDBs is the creation and maintenance of such Relationships. In a big IT shop such relationships change rapidly and keeping up with such changes is not easy.

Some things you may want to consider...
- Identify what CI Types or Categories are important to you
- Identify who owns those CI Types
- Identify the attributes that will need to be collected and maintained for those CI Types
- Identify the processes for how such attributes and their data are and will be populated
- Identify the processes for how the inventory of CIs will be created, maintained and supplied to the CMDB (and other relevant targets)
- Identify what Relationships are important between CIs (of the same type and of different types)
- Identify the Relationship owners
- Identify the attributes that are important to capture about the Relationships
- Identify the processes for creating, maintaining, and supplying such Relationships

Why do not answer the response from Diarmid or post something useful rather than spout so sort of advertising post in the thread

Both your answers are not really answers but more like a bullet list of accomplishments that you are touting

Hi UKVIKING,

I believe his question was: "I would like to know if anyone has the experience of building CMS (and a CMDB) from scratch and can you share the strategy you used?
Can you comment as well on the strategy that I am using right now. "

I believe I answered his question, specifically...

He wanted to know if anyone has the experience of building CMS from scratch. I answered that I had/have that experience, having built CMS solutions and CMDB, both, using vendor solutions and building such solutions from scratch.

He wanted comments and recommendations on his approach, which I provided (refer to bulleted line items).

You state that my bulleted list of answers reads more like accomplishments than recommendations. I reread them and disagree. I gave him a simple set of things to consider, which any good CMS manager would have to consider. If you feel otherwise, kindly point out what is wrong or incorrect about my list of recommendations.

After rereading my responses, I also believe that there are no advertisements to any products or services of any kind. Again, if you believe otherwise, could you kindly and clearly point it out?

I wanted to apologize for the double post. I just realized that my first post, which I though had been deleted, seems to be restored. The second post was an attempt to reconstruct my first response. Sorry for any inconvenience.

Purpose, policy, objectives and process have to come before building a CMDB if you want to have firm foundations and not be wasting time and money. It is helpful to emphasise that.

I completely agree with this statement. You'll notice that many of my recommendations were to do things like identify and establish owners and processes.

Diarmid wrote:

Quote:

Good configuration management is usually a function of great data governance

Eh? Do you mean that the quality of data governance is dependent, in part, on the quality of the configuration management performed?

No, Data Governance is the set of solutions put in place to define what data is important, how it will be collected, how it will be maintained, how it will be supplied, etc. It is the means by which you control what data you want to collect and how you will manage the quality of such data and, therefore, comes before things like Configuration Management. Since your CIs will come from many different areas (Organization CIs and People CIs from HR, Hardware CIs from infrastructure teams, Application CIs from software application owners, etc.), it becomes critical to work with the CI Category owners to understand and govern how the data and its quality will be managed, up front, before the data is passed on to the CMS team and, ultimately, a CMDB and any other downstream targets that would consume such information.

Diarmid wrote:

Quote:

Single Sources of Truth (SSoTs)

Not exactly plain English! more like gobbledygook.

Actually, Data Governance and the concept of Single Sources of Truth (SSoTs) are very common and established concepts (arguably more so than Configuration Management Solutions are) in most mature IT enterprises, throughout the world. Such concepts have been in existence for more than a decade, like ITIL. If you don't believe me, simply google "Data Governance" or "SSoT" to see for yourself. I find such practices to be very valuable when implementing Configuration Management Solutiosn and highly recommend learning such concepts as the challenges are exactly the same. I've personally found that businesses tend to understand the language and concepts of Data Governance far more easily than they do those of Configuration Management. However, they're very close to being the same things, so if you can get them on board with Data Governance, it becomes (in my opinion) easier to get them to the step of CMS.

Also, the term "Master Data Management" or "MDM" is synonymous to such concepts but a bit newer. Again, you can google them to see how prevalent they've become and are becoming.

Diarmid wrote:

Quote:

Identify the ROI of your Configuration Management solution

ROI is extremely hard to pin down in this area. It is not measurable in any meaningful way in isolation from the other processes and activities that are closely integrated with configuration management. If you must do it, then it would be more honest to attempt to measure the ROI of the project than of the "solution". The project can have defined projected costs and benefits, but the "solution" is far too abstract a concept and using it leads to the overwhelming temptation to idealize the values - just like a salesman/consultant might do..

In any established enterprise, the businesses that pay for solutions want to know the benefit if such solutions and usually can only think in terms of financial ROI. While I agree with you that capturing the ROI of a CMS program is difficult, if you work in a larger enterprise, my experience has always been that the business will eventually come calling for your ROI. In hard times, if a business can't see a financial benefit, they tend to shut down things they can't justify and my recommendation is that if you build a Configuration Management Solution for your enterprise that do your best to try and capture that ROI and have it available.

The Configuration Management process and how it fits with the rest of the processes is the primary concern

Any useful or useless idiot can build a relational database - which all a CMDB is actually. But if no one uses it or maintains it or ensures that the database is fit for purpose for the organization, then it was a complete waste of time

While all your points are valid - for when you build, design, import the data for the CMDB and for exporting, you are providing information that is NOT relevant to the initial stages as to what to do to start the process that oversees the CMDB or CMS system

Finally, I checked out your web site.....

not really impressed in some ways..
amazed at the amount of veribage in others

What I dont see are the IT standards and best practices mentioned in the web site at all

The Configuration Management process and how it fits with the rest of the processes is the primary concern

Any useful or useless idiot can build a relational database - which all a CMDB is actually. But if no one uses it or maintains it or ensures that the database is fit for purpose for the organization, then it was a complete waste of time

While I agree with your position, completely, I believe his post asked for responses on both concepts, as he was also asking for advice on his using CSV files in preparation for load to a future CMDB system. I believe you'll find that most of my responses were related to "processes", such as identifying the owners and the processes for creating, maintaing, and supplying all such CM related data. I see very little in my responses that talks about the tool.

UKVIKING wrote:

While all your points are valid - for when you build, design, import the data for the CMDB and for exporting, you are providing information that is NOT relevant to the initial stages as to what to do to start the process that oversees the CMDB or CMS system

Again, my suggestions were to identify owners of the data, processes for how such data will be collected, understanding what relationships between such data is or is not important, and owners & processes for collecting and maintaining the relationships. I did not write anything about a tool.

UKVIKING wrote:

Finally, I checked out your web site.....

not really impressed in some ways..
amazed at the amount of veribage in others

What I dont see are the IT standards and best practices mentioned in the web site at all

I see no mention of ITIL, ISO 20000, ISO 9001. ISO 27001, CoBIT. PRINCE2, PMP - to mention a few

Let me preface the rest of the response with I am only writing about our organization because UKVIKING brought it up. Otherwise, I would not have done so at all...

First, let me say thanks for checking out the website. Please know that I did not ask for you or intend for you to do so. You are correct, like this site which allows no links to other useful sites and information, we do not mention any other standards or best practice organizations as we are building our content from scratch. Let me be clear... we do not profess than any one set is better or worse than any other. We simply intend to provide a new option for professionals and, in fact, we recommend that people seeking solutions educate themselves on all available options, as it is almost always the best path for success and building experience. Agreed?

Also, while I appreciate and respect your feedback on not being impressed, please kindly understand that it is not you who we're trying to impress. We are working at our own pace and have built a very impressive following of enterprises that use our material, world-wide. This includes many of the largest private companies, largest government agencies, non-profits, and most of the higher educational institutions like colleges and universities (over 700 at last count). While this, admittedly, may not compare to the penetration of ITIL over the last decade and a half, please know that we are very happy with our progress over the last two years and have written positive feedback from many of our users, many of whom have expressed severe frustration with ITIL and other best practices. It's this positive feedback that continues to drive us to provide more and better solutions for them.

The original poster assumes that building the CMDB will complete the action of Configuration management. He is obviously not familar with IT Service Management nor with the concepts of putting in a Configuration mgmt process

While your information is valid about the various CI and data. That is NOT more important area of Configuration Mgmt.

The original post should identify what processes are needed to do the stages in config mgmt before they even consider the CIs etc

As for your website....

I am a bit puzzled.
1 - ITIL is Best Practice not a standard. It is used around the world. It is nothing more than common sense regarding IT Service management. The ITIL process set involved multiple countries, governments, universitys in this current version to change the focus of ITIL to a more holistic point of view

2 - ISO 20000 is a standard. So is ISO 27001. So is ISO 9001

3 - I looked at your web site and it appears you are doing nothing more than reguritating what is being said in established areas

4 - As for the success or failure of your web site/business.. shrug... I personally think you are re-inventing the wheel and called it round

The information on the site.. where it is detailed ,,, is quite nice actually_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

The original poster assumes that building the CMDB will complete the action of Configuration management. He is obviously not familar with IT Service Management nor with the concepts of putting in a Configuration mgmt process

While your information is valid about the various CI and data. That is NOT more important area of Configuration Mgmt.

The original post should identify what processes are needed to do the stages in config mgmt before they even consider the CIs etc

I agree with your views on this and please understand that my answer was not intended to give a holistic answer (nor do I believe any post preceding mine attempted to do so, either). Instead, I was just pointing out some key issues that have come up, time and time again, in my own experiences, with the intent to enhance all of the responses posted.

However, that being said, I'm sure you (like me and many others) have walked into many enterprises which have started CMS paths without thinking everything through. It appears that the original poster is already down that path as well. So, I believe that upstream advice and downstream advice both seem appropriate in this case.

UKVIKING wrote:

As for your website....

I am a bit puzzled.
1 - ITIL is Best Practice not a standard. It is used around the world. It is nothing more than common sense regarding IT Service management. The ITIL process set involved multiple countries, governments, universitys in this current version to change the focus of ITIL to a more holistic point of view

As I'm sure you are aware, there are many that disagree with ITIL and who look for alternate options or options that they can mix in with pieces of ITIL to meet their needs.

And, I would add that what you are calling common sense does not register with everyone as common sense.

Also, I'd like to qualify the above by saying that I am not implying that belief in or against ITIL is right or wrong or that belief in or against any other solutions are right or wrong. Instead, I'm simply stating the facts that not all IT leadership would agree with ITIL being defacto and/or common sense, as I'm sure you and others on the site have experienced, too.

UKVIKING wrote:

3 - I looked at your web site and it appears you are doing nothing more than reguritating what is being said in established areas

In some areas, you are absolutely correct, there are some redundancies. However, I believe you'll find that in most other areas there is uniqueness. It really depends what information it is that you're looking for.

For example, we have the head of global Configuration Management (and all of the teams he manages) for arguably the largest provider of ITIL services and tools using our Incident, Problem, Change, and Service Management glossaries in tandem with the ITIL v3 documentation because he believes our glossaries are far more consistent and informative (strictly his opinion) than those provided by ITIL or other best practice organizations. We also have people like the Chief Architect of one of the largest military organizations in the world using our glossaries and taxonomies (and asking for more) because he can't find more complete or higher quality sources. We also get constant feedback that people love our open content model because many believe you shouldn't have to pay for what is considered common industry experience. I can't even count all of the requests that come in asking for more.

The point that I'm trying to make is that there is good and bad in all options, out there. I think we all agree that intelligent and well informed people look at all options and pick and choose the pieces from each that help get them to their end state.

UKVIKING wrote:

4 - As for the success or failure of your web site/business.. shrug... I personally think you are re-inventing the wheel and called it round

The information on the site.. where it is detailed ,,, is quite nice actually

Thank you. I honestly appreciate and welcome all of your feedback, good or bad. It's the only way we will improve.