I need your advices again, regarding relations between a business service and IT&C infrastructure CIs ("used by"). In CMDB we have relations between HW CIs and SW CIs of different category installed on(Applications, OS, DBMS, etc). The question is how to relate infrastructure components involved in a business service? Individually, one by one, at lowest level of each CI involved, even is an operating system for example, or, taking into account the already existing relations between SW and HW CIs only main applications, servers and network components involved? This question is generated due to following reasons: 1. Case of an incident, to be able to see directly all CIs involved which could affect availability of that business service. 2. An easier way to calculate IT cost for that service. Based on your experience, I'm waiting your valuable advices regarding a model of how to relate a business service with infrastructure components involved in. Many thanks in advance.
I think the key to the question is whether you want there to be a relationship between the CI and the Service when you create an Incident or a Service Call. Normally, you know in which CI the symptoms of an incident are detected so you can easily enter that. The question is whether you should only be able to select a service that depends on that CI.
If the answer is yes, and if you are a medium to large size organization, then IMHO, you have a gigantic, unmanageable mess.
If the answer is no, then I would relate only the top level applications to services.
From your two reasons, you seem to be leaning toward Yes. Maybe there is a simpler way to achieve what you want.
Regarding the question of which CIs affect service availability, in my experience sophisticated monitoring tools are better suited than OVSD to answer this sort of question. If you try to model this in the CMDB by making a 1:1 relation between every service and every CI than affects its availability, you are likely to have a huge job of keeping that information up to date. This is why I suggest only modeling the relationship with the high level applications used by the service.
Regarding the calculation of a service cost based on the CIs implicated - OVSD is a very poor tool for doing this. You have to build all the rather complicated logic yourself. It might be a lot simpler to decide, when you buy a CI, how to split its costs amongst services and regard this information elsewhere than in OVSD.
By the way, with the purchase by H-P of Peregrine, we might hope that the integration of Peregrine Asset Center will, in term, provide more sophisticated management possibilites of the sort you are seeking.
Thanks a lot for your replay. What you said is very similarly with my point of view. Indeed, taking into consideration how many CIs are involved and how many IT business services are, the result will be an incredible number of relations to be created and mentained! Regarding cost calculation our intention was to do this outside of application based on a reference list taken directly from service related CIs if the first solution should be used. While I'm waiting for other replays, please, receive a small reward!
I think Josh is right in saying that SD is not a handy tool to calculate the cost of IT services, however a range of recommendations can be found in the ITIL books how to do costing, you might find a compromise. As to relations between services and CIs: you can record your services as CIs, and can build a hierarchy from the services as well. This way you will have an abstract level of your services and an actual physical level of your CIs. The two should meet in the middle, for example your business service will be provided by some IT service, in providing that IT services several applications will take part, those applications will have databases, and other physical components, etc. There are several things though to consider when doing a "service map" like this: 1. How will the relations be maintained? 2. What is the level you will want your specialists to record incidents, problems, changes, etc. against? 3. Reporting: How are you going to extract this data from SD, preferably in a visual format to aid you in other processes (like impact analysis for a Change implementation)? I hope this was some help to you. Judit
Thanks for your interesting comments. Initially, we have had a similarly approach, trying to create IT services as a special CIs named 'IT Solutions' and relate them with business services. Of course, IT Solutions contains relations with all CIs involved in those solutions. The disadvantages of this approach are the following: 1. We can't see directly CIs 'used by' a business service (we can see only IT solutions) 2. IT Solutions are virtual CIs ('super CIs') which must to be created and maintained and the same time, another ring in whole chain of relations. So, we decided to relate CIs directly to business services.
obviously every organization has to decide on their best practice, so without knowing what your business is, I can't suggest anything more than what you're already doing.:) My scenario was a highly IT and network- dependant service, mobile telecoms, that's why it made sense to distinguish between lower level services, as for instance in the business service of billing, it makes not only IT elements to provide its smooth running. I'm not saying that you should go into investigation down to the last form which should be filled to provide a service, but it's good to know about the parts you do not control, just as a black box. This is true especially if you are obliged to register incidents for those elements as well. Again, these are just my thoughts- offered humbly.
Thanks, again. Highly appreciate your comments and time spent.Indeed, our concerns are related with this ability to identify a CI responsible for an incident and further, to establish the impact against business service availability case of not a direct relation between CI and service, at reports level. Cheers,
Our Service, CI relation structure are similar. We have 4 types of relation that makes tree type structure. in the root there are business service -1->CI(software)-2->CI(software)-3->CI(hardware)-4->CI(hardware)
Problems in this type of structure is that the same CI (for example hardware) can support more than one business service so it is un possible to select service for this type of incidents. To calculate availability correctly we have to register separate incident for each service. incident about hardware component that fails will be related to operations management service.
Many thanks for your replay. A very good idea to create incidents and relate this with operational management services. This is a way to verify and control associated OLAs. Using OVO, these incidents could be created automatically if there are agents installed on critical servers, for example. However, when a HW CI (e.g. a server) is shared between two or more business services, when this HW CI is down, all business services will be affected same time with same time duration. Our help desk officers will record one service call for each complain and based on associated info will relate a business service or another to service calls. Practically, all business services should be finally related with that server via different service calls.