OBASHI Think

See things clearly

This is my first day as an OBASHI 'thinker'....

I am indeed very keen to embrace the OBASHI model in my organisation, but I feel there is one piece missing in this jigsaw which I need to resolve before moving forward. Coming from an ITIL background, I would have expected a 'Service' layer between the 'Business Process' layer and the 'Application' layer.

What does other OBASHI 'thinkers' think?

How do you deal today with positioning Business Services using the current model?

I have read the "The OBASHI Methodology' book but could not find any clearly articulated ways where Services are defined in OBASHI, even after reading the appendic D 'How OBASHI fits with ITIL'.

 

Best's

Herve

 

 

 

Views: 217

Comment by Paul Wallis on February 27, 2014 at 21:08

Hi Herve,


Welcome to OBASHI Think and thanks for posting the question...

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.”

We believe, that's a bit vague, and it depends on perspective as to what it means and how a service should be described.

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.

From the Utility companies perspective, what's required to understand the service is a lot more detailed.

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&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.

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.  

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…

Consider the OBASHI B&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.

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.  

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&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. 

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.

Hope that helps...

PJW

Comment by Herve Meslin on March 3, 2014 at 6:18

Thanks Paul for your prompt and thorough reply.

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.

Thanks and regards

Herve

Comment by Andrei Hawke on April 24, 2014 at 2:45

Hi Herve

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. 

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. 

 

Andrei

Add a Comment

You need to be a member of OBASHI Think to add comments!

Join OBASHI Think

© 2017   Created by Fergus Cloughley.   Powered by

Badges  |  Report an Issue  |  Terms of Service