Comments - OBASHI and 'Service' layer? - OBASHI Think2018-05-24T17:17:27Zhttp://think.obashi.co.uk/profiles/comment/feed?attachedTo=6264419%3ABlogPost%3A26539&xn_auth=noHi Herve
To add my 50 cents t…tag:think.obashi.co.uk,2014-04-24:6264419:Comment:269032014-04-24T01:45:42.872ZAndrei Hawkehttp://think.obashi.co.uk/profile/AndreiHawke
<p>Hi Herve</p>
<p>To add my 50 cents to this. Service Assets are defined as Capabilities and Resources of a service provider (internal,external,shared) by ITIL 2011. Resources being hardware, software etc. Capabilities being people and processes. OBASHI already has all those elements. </p>
<p>I suggest if clients want to add an ITIL Service Context to maps that they do it via logical elements (it is an ITIL classification) at the business process layer. Sample below. …</p>
<p></p>
<p>Hi Herve</p>
<p>To add my 50 cents to this. Service Assets are defined as Capabilities and Resources of a service provider (internal,external,shared) by ITIL 2011. Resources being hardware, software etc. Capabilities being people and processes. OBASHI already has all those elements. </p>
<p>I suggest if clients want to add an ITIL Service Context to maps that they do it via logical elements (it is an ITIL classification) at the business process layer. Sample below. </p>
<p><a href="http://api.ning.com:80/files/SPs2IsiC3PJ18ofYyKTjmAxDV0A1CO1s4sP3ZKg7Qb9-w8JIk7Qh0OdvR8Oi-9u-kMuGZWfVVy9R-uoCcXmfAha7dK3Uy*kV/OBASHI_ITIL_SERVICES.PNG" target="_self"><img src="http://api.ning.com:80/files/SPs2IsiC3PJ18ofYyKTjmAxDV0A1CO1s4sP3ZKg7Qb9-w8JIk7Qh0OdvR8Oi-9u-kMuGZWfVVy9R-uoCcXmfAha7dK3Uy*kV/OBASHI_ITIL_SERVICES.PNG?width=750" width="750" class="align-full"/></a></p>
<p> </p>
<p>Andrei</p>
<p></p> Thanks Paul for your prompt a…tag:think.obashi.co.uk,2014-03-03:6264419:Comment:266312014-03-03T06:18:50.132ZHerve Meslinhttp://think.obashi.co.uk/profile/HerveMeslin
<p>Thanks Paul for your prompt and thorough reply.</p>
<p>It will take me a couple of day to 'diggest', share with colleagues, and as I have other high priority tasks, I'll will come back to you later this week/ early next week at the latest.</p>
<p>Thanks and regards</p>
<p>Herve</p>
<p>Thanks Paul for your prompt and thorough reply.</p>
<p>It will take me a couple of day to 'diggest', share with colleagues, and as I have other high priority tasks, I'll will come back to you later this week/ early next week at the latest.</p>
<p>Thanks and regards</p>
<p>Herve</p> Hi Herve,
Welcome to OBASHI T…tag:think.obashi.co.uk,2014-02-27:6264419:Comment:266292014-02-27T21:08:50.617ZPaul Wallishttp://think.obashi.co.uk/profile/PaulWallis
<p><span>Hi Herve,</span></p>
<p><span><br></br>Welcome to OBASHI Think and thanks for posting the question...<br></br> <br></br> In ITIL V2 we saw services described as “ICT infrastructure and management processes that deliver the information and solutions required by the business." By ITIL v3 it seemed to be getting specifically defined as “A service is a means of delivering value to customers by facilitating outcomes customers want to achieve, but without the ownership of specific costs and…</span></p>
<p><span>Hi Herve,</span></p>
<p><span><br/>Welcome to OBASHI Think and thanks for posting the question...<br/> <br/> In ITIL V2 we saw services described as “ICT infrastructure and management processes that deliver the information and solutions required by the business." By ITIL v3 it seemed to be getting specifically defined as “A service is a means of delivering value to customers by facilitating outcomes customers want to achieve, but without the ownership of specific costs and risks.”<br/> <br/> We believe, that's a bit vague, and it depends on perspective as to what it means and how a service should be described.<br/> <br/> If we look at IT as if it was a Utility, then from an ITIL 'User' perspective the service is what comes out of the utility pipe that we can use. From an ITIL 'Customer' perspective, who pays for the service, I guess an understanding of everything that contributes to the cost of the service is important.<br/> <br/> From the Utility companies perspective, what's required to understand the service is a lot more detailed.<br/> <br/> It's for this reason that we don't think there should be a 'service layer' per se. We think we've all of the information needed to describe a service on the B&amp;IT diagrams ... we just need a way of grouping the elements together that provide that service and describe what it is they are delivering to the business.<br/> <br/> As you know, in OBASHI we depict assets using elements so we think of services as being a group of elements that provide that service. We can group those elements representing the assets as sets, or perhaps more effectively using dataflows. If you consider a service, you could imagine that rather than only being a single element in a service layer, there are many elements that make-up that service. <br/> <br/> Because an element can exist in multiple sets and dataflows, you can see how one particular asset contributes to many services, providing for better design, optimisation, redundancy, consolidation, root cause analysis etc…<br/> <br/> Consider the OBASHI B&amp;IT diagram as a map of HOW things are connected. Then think about the Dataflow Analysis View (DAV) as WHY they are connected - the why being a service in this case. By mapping a service as a dataflow we can show and described the IT assets which are used for service delivery, and can ascribe to them the role which they play in service delivery.<br/> <br/> Defining services like this allows us to see where each asset fits in the operating landscape, as well as the strategic plan for service delivery. <br/> <br/> So, basically, we see a particular IT service as something provided by a collection of people, process and technology assets which we can document on OBASHI B&amp;IT diagrams. We can show how the service uses these assets by mapping the flow(s) of data through the assets. The resulting data flows describe how the service operates, and the assets required to provide the service. <br/> <br/> Our view, therefore, is that a service isn't a layer, but it's a description of how the elements in the OBASHI layers are used to provision something the business consumes.</span></p>
<p></p>
<p><span>Hope that helps...</span></p>
<p><span>PJW</span></p>