For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone
Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
Posted: Wed Mar 19, 2008 9:54 pm Post subject: Relationship Crossroads
Hello Everyone,
We are using a product giving the relationship information on CI for Upstream and Downstream. I am somewhat confused on upstream and downstream words. When I use this in context of English language it tells me that from Switch to Application is a downstream impact in terms of relationship but when I look from OSI model it seems like it is upstream relationship from Switch to application. Not sure ITIL is providing this in-depth information but can someone provide the inside information how they are doing in their company.
Joined: Sep 16, 2006 Posts: 3118 Location: London, UK
Posted: Wed Mar 19, 2008 11:10 pm Post subject:
You need to ask the people who produced the products for the answer
I dont use upstream or downstream as I cant fit in the canoe and there are too many waterfalls and rocks
On a related note, you have it right.. if you look from the end user usign an applciation to the server that produces the application you are looking down.... _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Another convention is use which means the same is parent/child. For instance for service mapping a pyramid structure similar to the following may be used.
1. business process
2. services
3. systems or application
4. virtual hosts (VM, LPAR, partitions)
5. hardware
In practice it is a design choice and some of the layers may be expanded to suit the communication needs of change and incident processes.
The trouble is, you would map an organisation as an org chart, a location as a drill down to a room from a site etc. So when you try getting more complex by mapping services or systems to users or locations you end with a mess.
If you start mapping shared infrastructure devices such as switches, sans and other resilent devices it becomes so tangled as to be ineffective. If you have to deliver a CMDB that supports service impact understanding then keep it small, focus on key systems and it might deliver.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum