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 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
