Brad, What I would recommend is to understand where and who is going to manage this data. First, I would say it is ideal to have this data in the CMDB classes versus not having it in the CMDB and only in the Remedy Forms. The problem here is if you have it in the CMDB but it is unmanaged you create other problems for data accuracy etc. CMDB accuracy is about data management (config mgmt). If the data is not managed it becomes troublesome and eventually inaccurate.
In a perfect world this is what I would do in your situation. 1. Utilize the CMDB classes for Site 2. The other three items of custom data. Ideally, I would find a class in the CMDB that would fit. I see you have tried to do that but state that there is no class. At first blush, this usually seems the case with the CMDB. However, I would highly recommend another analysis with the ideal of, "I need to find somewhere to put this." If after all searching, you cannot find an OOB place to put this in the CMDB. I would say, then and only then, I would extend the CMDB. In this case, you will probably need to create a custom form or on an existing form you will need to reflect this new extension in Remedy as it exists in the CMDB. That is an entire process in itself also, to extend the CMDB, then reflect those extensions in Remedy (ITSM), It is best to populate the CMDB and let ITSM reflect that data. From a Config Mgmt/CMDB perspective. It has been my experience, managing that data is the limiting factor in this equation. If no one will be able to manage the Site info in the CMDB, in your environment, then I would go through ITSM to manage Site. I normally hear customers say "wow we should have been bringing all of our data into the CMDB all this time." The reason they say this is because normally ITIL begins with Incident, then Change, etc.etc. Followed lastly by the CMDB. You are going about this the correct way. You are trying to build your system with the CMDB as the "brain" if you will, and therefore, taking the CMDB into consideration first. Unfortunately, I have learned this is somewhat of an uphill battle. But it is the best way to approach this. You need the CMDB to be the same as the ITSM suite. You can see as Remedy is developed a much more cohesive application between the ITSM suite and the CMDB. This is most noted in the tight coupling with Asset and Atrium Core. They constantly reflect each other and when navigating Asset you constantly move in and out of Atrium Core. You can also see this coupling in the People form and the Person class in the CMDB. Sorry for the long winded response. Josh On Tue, Jan 28, 2014 at 3:49 AM, BradRemedy <[email protected]> wrote: > ** > Hi Guys > > Quick Question that just wanted come advice from everyone on. Basically we > are busy upgrading our system to version 8.1 and ITSM 8.1. We are busy > planning our data migration and wanted to know what you guys think of the > following. > > We currently have 4 different remedy forms on our old system with data > that we want to migrate to our new version. The new version is installed on > a new server as a clean OTB Install. > One of the remedy forms and data is Site information which we were > thinking of placing into the CMDB however the other 3 are our custom data > that doesn't really fit anywhere in the CMDB. > > Is it advisable to add a new custom class to the CMDB to hold this > information and then form the various relationships or should we rather > create this data on our new remedy environment and not customize the CMDB > at all? > > Any advice or assistance would be appreciated. > > Thanks > Brad > _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
