I never did figure out Normalization. The interface is a mess, and in 7.6.04 we had bugs in the code so it wouldn't run correctly anyway.
Surprisingly the items likely to make my Top 5 would be non product related. Our biggest frustrations in setting up the CMDB are more process/people related. Especially if you are working with one or more service providers who all need to be on boarded to the new tool and possibly new processes. If I did have to talk product specifics I'd probably say
1. The silly things BMC do with fundamental functionality changes, between versions. Examples would be REID population (settled down now but in earlier versions, painful). Also normalisation. The Normisation status has seen way too many changes in its default value conventions.
2. Autodiscovery integrations. Not just ADDM either. Trying to tie down a consistent reconciliation strategy is painful.
3. Product catalog. The necessary evil.
I'll keep thinking. I'm sure there are more. Still the best product on the market though
Thought it would be worth sharing...
Leonard Warren (old) is reviewing BMC Atrium Core 8.1.0x docs from user perspective and providing some wonderful inputs. An experienced and seasoned eye makes such a difference
Love the way social collaboration works!!!
I am looking into the technical aspect of what works and does not work today. BMC has been very receptive to my efforts and have checked out all of my comments with the Subject Matter Experts at BMC before making any documentation changes.
Now for my top 5 frustrating things with implementing CMDB:
1. Hate to Change - When you have someone that prefers to utilize an Excel Spreadsheet and has used that method for years and will find every way possible to prevent from moving into the CMDB environment.
2. Failure to Implement Change with CMDB - Change Management should be launched at the same time as CMDB because you cannot make adjustments to a business unit's environment without CAB or someone's approval and requiring an implementation, verification and back-out plan.
3. Product Catalog Setup - The customers do not understand what has to be entered into the six fields of the product catalog or what it is primarily used for, Thus, educating the customers on this is a must before any implementation. It drives what you are importing from discovery products and what the end user is seeing - not to mention software license tracking and normalization setup.
4. Starting BIG - The customer wants everything in the CMDB because it is the way to fix all of their issues. That is not the case. Bringing everything into the CMDB on the first phase is not the best approach to take as the End Users are still understanding how things work within the product and the product may not provide all of the process requirements needed by the business unit to support its efforts. Thus, a customer should start small - Servers, Database, Computers with its End User associations is a good place to start. Then incorporate the software and hardware requirements should follow. Then continue the build up.
5. CMDB itself - Changes are a must but some changes result in complexity for the consultants. Take for instance the AST:Attributes split off. One was able to utilize the BMC Data Import Tool to import records into the CMDB but now this process causes default entries to take place inside the AST:Attributes form and fails to match up the entire process. Then there is the multiple modifications to CI records when the Sandbox functionality within Asset Management is activated. There is a Bulk RE Job that runs but it does not trigger when you do a Modify All operation. Thus the customer must decide to have it on or leave it off based on what they can and cannot do. So it does get a little frustrating when CMDB is upgraded to a newer version as there will be changes incorporated that changes what the consultants had previously done one version ago.
I agree with Carey completely, the biggest hurdle with CMDB is people/process. If you get the people/process right, the technology is no issue. Still a few things though:
- The default reconciliation identification rules are not reflecting the modern dynamic data center infrastructure
- Not enough default permissions to CMDB available through ITSM. There are only "Asset Viewer", "Asset User" and "Asset Admin". These are not sufficient in a real world scenario where one would like to give a user permission to modify any CI, but not have access to things like reconciliation or normalization etc. See the idea at https://communities.bmc.com/ideas/6276 as well
- An easy way to disable / enable CDM classes. it would be nice the be able to simply disable classes that should not be used by the users and as such, easing the navigation of CIs. Typically, only about 20% of the CDM is used to define the CIs required. I would like to hide the remaining 80% from the users in both Atrium Explorer and through Asset Management console.
- Painful for CMDB analysts and librarians (well, first there are no suitable permissions availabel for these roles) but more importantly, there is no functionality with CMDB that aids the governance of data or Configuration Management KPIs. Such as measuring the quality and quantity of CIs in the CMDB. Automatically identify "duplicate" CIs (both based on out of the box rules defined as well as custom rules)
- Regarding the Product Catalog... functionality is not a problem.. the problem and frustrating thing is that BMC recommends the Product Categorizations differently depending on where we look. Such as "mapping your data spreadsheet", docs, what is installed with the system out of the box and how data providers such as ADDM sets/defines the CTI values do not all align
- Changes to the CDM in terms of keeping up with new technology or. Stuff like "PrimaryCapability" are missing values that would be great to have, BMC_SoftwareServer and other classes representing instances do not have an attribute to store the specific instance id of that CI (such as the weblogic id, tomcat instance etc) same is true for BMC_DataBase where "SID" would be a typical attribute to be added to that class.
I bet a can figure out a few more, but that´s it for now
This is all good stuff everybody, I'll be reviewing all the comments next week and kicking off another discussion on Wednesday for you all to contribute to. I must say that the comments around 'people' change being one of your biggest pain points is interesting, I'd be interested to hear of things that we could do in the tool to ease this, if there are any, or if something we could do in Best Practices that could ease this area of implementation...
As I was reading your question I started to think of a pain point. Then I read Carey's post. Then the replies by Lenny and Petrus. Damn! They all beat me to it. It isn't so much the product but the people and process. Not saying the product is perfect however the people and the sheer amount of work that is needed has pretty much killed our CMDB effort (there are other factors as well that I'll leave out of a public forum). Now I hope BMCers don't read this an think "well people are not our problem." If you did you might want to think again. Products that are too burdensome are destine to fail (no matter where you are in the Gartner Magic Quadrant).
We have been dancing with CMDB off and on since about 2009/2010 when we did it all wrong because we wanted to throw everything in there, without any governance and without scrutinizing why we were putting different data sources in the CMDB. So we learned that was wrong (well raised concerns but we did it anyway) and the next few years we looked at how to tackle the monster. NOBODY wanted to start small. I can appreciate the logic behind it (as flawed as it might be in terms of CMDB). We need to show value and by putting in a few servers without relationships how we will get buy-in? The app teams are not going to see the big picture. The server guys already have their tools to keep track of what they have so we are not doing them any favors. We really, really want big bang. Something that solves all of our pain points and answers all of our questions regarding dependencies (with little effort of course).
So how do we get there? Learning from our previous attempt... Well we need to define and maintain our Product Catalog; that is going to require some serious time. We buy ADDM (will help with Prod Cat). Getting credentials for systems, tweaking and creating patterns, validating discovered info (we found old entries in DNS can be a a real pain), CAM, then manually associating the * By groups in AM to grant permissions; is going to require some serious time. Adding and managing the non-discoverable items such as new equipment and spares not on the network; is going to require some serious time. Tweaking NE and RE; is going to require some serious time. It seemed each time we discussed CMDB the question of who is going to do something and how much effort it is going to take came up. To the point we realized it takes way more than we want to put into it.
Are some of our issues discipline (or lack of) related? You bet! But that means we would also need to take on a huge cultural aspect as well. It is looking like CMDB is just the wrong fit for us.
So seeing as it appears my current employer will never deploy CMDB (subject to change of course) I don't have much practical/production experience with the product to list the technical pain points. My suggestions:
- Really focus on making things as easy as possible. If there are common tasks that are daunting, figure out a way to make it as simple as possible. If NE rules are too hard to figure out make easier.
- Provide way more guidance and examples.
- Managing an IT infrastructure is not unique in many environments, yes there are nuances to each environment but largely we are all using some combination of the same MFG's hardware and core software in similar configurations (at least at the core infrastructure and service layers). The regularly updated Product Catalog idea was really neat. Being able to leverage that data would help many shops get their Product Catalog and categorization off the ground. Again, why does each customer need to reinvent this wheel? Unfortunately it appear the Product Catalog updates initiative died.
- Mappings and relationships. Provide some in-depth examples of what a real-life data center would look like. Show from experience what really works. Does it make sense to include MAC addresses, Ports and IP addresses? Have real-world use cases why somebody might decide to track down to the MAC level. Explain if it is or isn't feasible to track MAC for some things and not others.
- Real-world examples of setting up and tweaking NE/RE rules. Help organizations make sense of these features.
- Real-world examples of what it takes organizationally to maintain a CMDB. Yes I know this varies widely depending on size of the environment, etc but BMC and partners must have some data on what has been proven to work. Does an organization need a full-time ADDM person, 3 FTE CMDB people, 1/2 FTE for Product Catalog and a 1/2 FTE for contracts. Of course this info needs to be disclaimed as being examples and your organization's mileage may vary but from what I have seen is many people just want some place to start instead of purely guessing.
- Clarify the difference between CMDB and Asset. What are real-life examples of the differences. Give real-life examples of groups of users and functions that work directly in CMDB and same for people that work in Asset. From what I have seen largely organizations don't get the difference between a CI and an asset. Should they? Maybe having the CI vs. asset concept is more trouble than it is worth. I certainly understand there are differences by definition but do the majority of customers view them as the same thing? Maybe maintaining the those definition lines in the product is just adding unneeded complexity? I am aware that CMDB and ITSM are built around ITIL and best practices but at the end of the day if that means unneeded complexity that customer do not appreciate and really do not benefit from then maybe it is time to take another look at that model.
- More generally provide real-world examples and sample data of how the whole system can work end-to-end. From ADDM to CMDB to Asset to users actually maintaining all of those pieces.
- Petrus mentioned this but it is so important I'll mention it again... consistency throughout the products/documentation. If ADDM categorizes a CI one way, docs.bmc.com another, sample data yet another and the mapping your data spreadsheet even another way, customers get very confused. This is back to the point of providing real-world example/sample data so organization can find their way. <HonestyFilter=on> our organization has looked to BMC time and time again for guidance regarding best practices, etc. Surely they know the industry and should be able to help. We view BMC as SMEs. Unfortunately our organization and more specifically IT leadership (VP level) is very disappointed.<HonestyFilter=off>
One product-related (and process-related) pain point that I knew we would have experienced if we were to deploy CMDB/AM is the manual maintenance of the asset to people. Petrus pointed out the Asset 2 People relationship "automation" Idea. I am thinking about the model where ADDM or other AI jobs create CIs for most everything in the environment taking a huge manual burden off of staff but then somebody still has to manually find new assets and add the correct * By groups to give permissions to the Asset.
Notice I didn't say CI in the last sentence? This is back to the point I made earlier about does the difference between CI and asset provide customer value. Being pretty new to BMC and also having experienced some of this BS first-hand I hope your first thought is not "well that is Asset Management, not my problem." I'll go out on a limb here and say I am not the only one tired of this kind of internal BMC politic crap. We are are sold, sold hard, that ITSM and all of the BMC products are designed to work very well together (you know the circle picture of all of the products). And for the most part they do. Once you become a customer you find that the different teams that build those products may not work so well together. I am of the belief that most customers do not care about the difference between CMDB and AM so when we get a response along the lines of "sorry that isn't my team, can't help you" it makes BMC look bad and frustrates us.
Ok, I used up all my time and character limit. I am laying this out for you with a glimmer of hope, having talked to you before at WWRUG and being the new guy not corrupted by the BMC machine.
Thanks for the detailed and thoughtful post, I definitely take your comments on board and can assure you that I don't deem things that aren't directly part of CMDB as 'not my problem' if something interfaces with, consumes or acts as an input to CMDB how this happens is of interest to me and should be as elegant and simple as possible.
I know that 'simple' and CMDB are not words that you usually see in the same sentence however it is a focus for me as we move the Atrium CMDB forward within BMC and the related products. One of the core things for me is that CMDB should not be an arduous task or require large amounts of resource to maintain. Now don't get me wrong - setting up a CMDB is work and some of it is unavoidable and depends on your environment.
You'll see from the upcoming discussions that I will be posting over the coming weeks that I'm very invested in simplifying the experience for setting up, maintaining and consuming the data in the CMDB for realizing business value from it.
For all the participants in this discussion I'm interested in setting up some calls to discuss your individual situations and thoughts you've expressed - please let me know here or by email if you are interested in a follow up discussion.
Thanks for all the contributions so far :-)
Thanks Stephen! It looks like are the right man for the job
An other thing that frustrates me (or annoys me at least) is that in order for CMDB initiatives to be successful, simplicity is a key word in many aspects, like "only track the necessary data", "less is more" etc...
Unfortunately, the CDM introduces alot of complexity and detail, complexity and detail 99% of the users do not need. How about stripping CDM and out of the box, only having the classes that usually provides the biggest value enabled? I am thinking about BMC_ComputerSystem, BMC_BusinessService and other common classes used by I would think everybody. But classes like BMC_LANEndpoint, BMC_NetworkPort etc typically do not add alot of value to the consumers of CMDB data and could therefore be disabled out of the box. I estimate 70-80% of the CDM classes are not used by the majority of the customers. Those who DO use it, I am afraid use it because they are defined and we have documentation telling them how and what data to put in those classes or they do not care about filtering the data sources in to CMDB. The standard CDM installed with the system today, unwillingly "force" a very granular data model in CMDB. Maybe some classes could be collapsed in to one? Maybe some classes or attributes could be merged? A class represented as an attribute of another class?
I am thinking SIMPLIFY
So, just to make sure I understand your point, you are suggesting we ship with the full CDM but have a configuration that allows a customer to enable/disable a class in ‘their’ model, and to add to that we only ship OOTB with certain classes enabled by default?
Great point. The advice is to start small but I think that can easily be lost in the complexity. Many customers think if BMC supplies something (feature, class, etc.) that BMC is recommending it be used. I know that might be flawed logic but that train of thought exists.
Exactly! Spot on!
I think the suggestion is a little more than allowing classes in the full CDM to be enabled/disabled. There are already a couple of ways of hiding (or reducing apparent complexity) in the solution. I think it's to ship the OOB Atrium CMDB with only a small subset of the current model visible, but to have the ability to activate more if required. Call it a best practice starter model (don't you just love it when you can say 'best practice') or whatever, but position customers with the basics, and handle the remainder of the model as an 'Advanced Topics' discussion. This way most people will only go as far as the really need to and have an easier job of it, and hence a greater chance of initial success, but you are also ensuring that the greater granularity is understood and available to explore when the demand is actually there, rather than simply 'because it's there'.