Hi, I have built 2 CMDBs and I hold another opinion. CMDBs in themselves are fairly simple entities. Building a system which allows the user to build relationships between various objects is straightforward.
The great difficulty comes with the rules around how the CMDB is used in conjunction with the rest of the business. In my experience it is often harder to get a business to decide what the end game of CMDB is, than actually building it. The key in both CMDB's I have been involved with is the data model. Keep it simple and clear and define individual objects by the data within the model, rather than by the additon of more form objects. My current company has just gone through the compare and contrast. We came to the conculsion that the amount of additional roles the Asset module introduced put the whole system in the "operationally challenging" pile, not to mention the additional bespoke plug in's which would have been required. Hope this gives a little more into the debate Chris On Nov 28, 2007 1:20 PM, Carey Matthew Black <[EMAIL PROTECTED]> wrote: > Kathy, > > While it is far from a CMDB I can say that I have seen applications > developed to store data like Network devices (and their > configuration), People information, Incidents, Problems, etc... all > custom developed based on the base ARS tool set. So I have to say that > it can be done. However, there are bound to be quiet a few > differences/details in the administration and development that would > be quite different between a home grown CMDB and an ARS application to > hold the same kind of data. Some of those differences might be > "better" in the custom application case, but I suspect that not all of > them would be. > > > Before making that decision I would suggest that you give some serious > consideration to the secondary benefits of using the OOB BMC CMDB. > Like (for example and not limited to) access to AIE (Atrum Integration > Engine) to populate the CMDB from other data source in your buisness. > Yes you can build an "AIE" too. However, it is likely a part of the > custom build that you have not yet considered. Also consider that if > you buy "Service Desk" or "Change Management" or "Asset Management" > then you kill several birds with one stone. Then there is the fact > that BMC has published a CMDB API too. (BTW: The CMDB API sets on top > of the ARS API, so it is a wrapper of sorts.) > > Also be aware that BMC's decision to package any of their products > with any of there other products could be changed at any time. [more > likely between versions/releases] Also the terms of "how you can use" > such applications with custom applications could also be changed. For > example, it is possible that BMC would allow you to have a "basic" (As > defined by them) CMDB for use with their applications "at no > additional cost", but they could also restrict your ability to > customize it at some point in the future too. However, to be very > clear, I know of no such intentions from BMC at this time. I have even > heard some current high level people make statements about the idea > that the OOB apps "will likely never" be deployed as "locked > applications". As long as that attitude prevails, then I would expect > the ability to customize any OOB application (or purchased sub > component) to persist. (So I can see a good reason to _not_ buy such > an important part of your IT infrastructure from any vendor that would > later determine the rules for how you can or can not do things in the > future too. But that is more of a business risk assessment. You could > also choose to develop from scratch at a later point in time too. Then > it could be a "panic" implementation instead of a "planned" choice.) > > ( As usual it comes down to a build vs buy decision for your business. ) > > In summary: > If your management is in the mood to build, then go build. > Almost no decision you make today will prevent you from doing the > exact opposite tomorrow. > > I believe that buying "ITIL processes" is not such a great thing. > Buying technologies that allow you to quickly implement ITIL practices > is a better approach. At the worst case you spend a lot of time and > effort to find out how much work the OOB CMDB is really worth to you > and you can later go buy the features (AKA: The right CMDB for your > needs) that you are struggling to implement. At the best case you are > able to build only the feature you need for today and later can either > move to or integrate with an OOB CMDB (maybe in ARS, maybe in other > technologies.) > > HTH. > > -- > Carey Matthew Black > Remedy Skilled Professional (RSP) > ARS = Action Request System(Remedy) > > Love, then teach > Solution = People + Process + Tools > Fast, Accurate, Cheap.... Pick two. > > > On Nov 27, 2007 2:13 PM, Kathy Morris <[EMAIL PROTECTED]> wrote: > > ** > > We are trying to build from scratch the functionality that Remedy offers > > with the out-of-box CMDB application. > > > > Has anyone ever done this and what has your experience been? > > > > Would you recommend this approach if you have the support from > Management to > > build a customized CMDB? > > Are there any red-flags, gotchas, future upgrade or future process > > concerns that we should have? > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
