Why not deal with it via Categorization and SLAs? Those could drive increased priority, visibility, notifications, etc. That allows you to keep your Services generic and focused on something actually provided while still giving you control and reportability over the distinct combinations of data management is most concerned about.
On Thu, Apr 3, 2014 at 7:39 AM, Joe D'Souza <[email protected]> wrote: > ** > > That's what I figured was the drive behind it. > > > > While thinking along those lines, I also thought that it might be > appropriate to identify one of the components of software applications as > Application Clients, and classify application clients as thick or thin, the > ports they use, whether they are internal or external, and whether it's a > web application client or a web service, and include firewall load balancer > attributes too as I have seen that a number of times changes to firewalls > or load balancers often breaks a lot of these components.. > > > > Joe > > > ------------------------------ > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Pierson, Shawn > *Sent:* Thursday, April 03, 2014 10:24 AM > > *To:* [email protected] > *Subject:* Re: Web Service CIs > > > > 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: > [email protected]] *On Behalf Of *Joe D'Souza > *Sent:* Thursday, April 03, 2014 9:04 AM > *To:* [email protected] > *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:[email protected] <[email protected]>] *On Behalf Of *Rick Cook > *Sent:* Thursday, April 03, 2014 9:27 AM > *To:* [email protected] > *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" <[email protected]> > 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 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_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
