Is there a technical paper/white paper that explains what you are indicating? That is there documentation that explains how to non-intrusively build applications to work with the OOB ITSM modules? In looking under some of the covers of this OOB application there appears to lend a hint that one could create application workflow that is not touched during the OOB upgrades. And that the additional data elements are simply "Just Identified" to the ITSM application to enable it to prompt the User for specific pieces of information that are independent of other types of Changes. For instance we would like to use one RFC form to allow personnel to submit requests for changes to any kind of object, like configuration items such as hardware, network devices, software, etc.
We should be able define a CI class for special objects, add attributes pertinent to that item, and configure the system to automatically populate/instantiate a CI from this class at the create or modify time of the RFC. David _____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Jason Miller Sent: Wednesday, December 26, 2007 2:43 PM To: arslist@ARSLIST.ORG Subject: Re: ITSM Change RFC Design Question Hi David, I haven't worked with ITSM 7 yet but speaking from customizing other version of ITSM you can usually create add on functionality fairly unobtrusively. Basically you develop the circuit form to work almost completely stand alone and then you have a hand full of Active Links/Filters (maybe a field or two) that are the hooks in to your custom form. If your hooks were to break during an upgrade it shouldn't take much to fix them or rebuild them. Doing this also makes the circuit workflow portable, easily used on/with other forms and the data is not affected during an ITSM upgrade. It probably depends on the companies view on customizing by changing ITSM configuration vs. actual development work. Jason From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of David K Hill Sent: Wednesday, December 26, 2007 12:43 PM To: arslist@ARSLIST.ORG Subject: ITSM Change RFC Design Question ** I just want to get an opinion of other developer's ideas to see if I am going down the right path with this design strategy for our RFC (Request for Change) of the ITSM Change Module. The situation is this: 1. We have requirement to capture additional information that would be considered important for the request for change of a telephony or network "Circuit" in a network topology. That is, a customer would like to "Add", "Change", or "Remove" items that are deemed as "Circuits" in his network topology. A circuit is, for a lack of a better word, a collection of information describing two endpoints, ownership, support structure, location, punch down coordinates, costing, configurations etc. 2. They would like to have this information included for the review and approval stages of the RFC. That is some how available. (e.g. Location, Circuit ID, POC info, support info etc.) It would just be just another kind of RFC to submit, review, approve and implement. 3. At the same time, we would like to keep the OOB functionality of the ITSM Change module untouched to allow us upgrades in the future. (I know this sound contradictory). 4. We need the extended data to be available in reports so that RFC data is available along with the Circuit Here are some of the scenarios that I am thinking might satisfy the requirements. 1. Scenario: Create a separate form that captures the information that is different from the RFC and do a data driven workflow relationship to relate the extraneous data on a one to one relationship. Create work flow that will capture the information on "Create" and "Modify" of RFC that are classified in this Tier 1, Tier 2 and Tier 3 categorization. The only caveat here is that we have to take in consideration of the Upgrades and preserving our changes in the work flow and forms every time we upgrade the system. (ITSM). 2. Scenario: Create a CI Class that can be instantiated as a "Circuit" that captures the special attributes listed above and use it as a Relational item instead of creating a special form to denote a "Circuit" concept. I am thinking if we build/create a class that captures the fields we can use the Configuration Management components and the other Suites such as AM, PM, IM etc. out of the boxes with no additional work flow changes. Do we know of a CI that is indicative of a "Circuit" per se'? Looking through the existing CI, I can see some classes that would come close to the idea of a "Circuit". I would just need to add the extra info fields. I am thinking that a Circuit CI could show a relation ship of all the child devices/components that are affected. If we could go with Scenario 2 and it's my understanding that everything would behave natively. We would derive data driven Work Flow that will automatically relate the Circuit CI to the RFC at create/modify time. The only problem I can see is that I will have to build a special class to support this kind of CI. Am I going about this the right way? Thanks for any thought you may have in this. David Hill Verizon Business __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
