Tracking them as a component of an existing application (or technical service) is the direction I'm looking for. While our security group is the driving force behind it, we need to know how our applications are interfaced from a CMDB perspective as well. It would be nice to know who the consumers are of a web service so when you have a Change Request to rename or modify the structure of that web service, you can immediately see who will be impacted. The internal/external requirement is what the security group cares about the most, but it would be useful so we know if we're potentially impacting outside customers as a result which would bump up the risk level.
Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe D'Souza Sent: Thursday, April 03, 2014 9:04 AM To: arslist@ARSLIST.ORG Subject: Re: Web Service CIs ** I think I sort of see the why. Web Services when published have a potential of being used by n number of systems, and these systems could potentially be affected by an outage or an update of a web service and one could potentially loose track of all the potential consumers of a WS unless you have a proper DB of all its consumers. That's probably the management initiative behind wanting it in a CMDB so that any change requests to any of the systems or thee web services that are used by these systems, can then be tracked, depending on the relations between the system and the WS. If this is the drive behind it, I would think along the lines of considering the WS as a component of an application, rather than creating a specific CI just for Web Services. As for tracking if that WS is available inside or outside the network, you could build an attribute for the components of that application, that publishes that WS, on whether it is On Premise or Off Premise - and if Off Premise if it is a WS. Or maybe create a attribute for Software Applications for being On Premise or Off Premise, and then have components to the application, one of them being the various web services. Something along those lines. That should give you the ability to track change requests tied to a WS. Joe ________________________________ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Thursday, April 03, 2014 9:27 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Web Service CIs ** If you are asking our opinion of the strategy, I am opposed to it. Services are the what, not the how. I might add that management requirements should be the same. Tell me what you need, and let me figure out how. If they want to track this via Services, create one or more that describes the generic function being performed for the customer. Making them customer specific leads to an out of control service catalog. Rick On Apr 3, 2014 5:45 AM, "Pierson, Shawn" <shawn.pier...@energytransfer.com<mailto:shawn.pier...@energytransfer.com>> wrote: ** Good morning, We got a new requirement this morning of setting up web services as CIs so they can be tied to Change Requests as well as provide our I.T. security department a list that they can maintain and monitor. Mostly we would need to just track the name, a URL, and some attribute for marking it as being available outside the network. There are a few different classes that I could see potentially using but since there isn't one that is marked specifically for it I wanted to see where you all would suggest tracking them. Thanks, Shawn Pierson Remedy Developer | Energy Transfer Private and confidential as detailed here<http://www.energytransfer.com/mail_disclaimer.aspx>. If you cannot access hyperlink, please e-mail sender. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ Private and confidential as detailed here: http://www.energytransfer.com/mail_disclaimer.aspx . If you cannot access the link, please e-mail sender. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
