A year ago, asking the question “what is OBASHI®?” might have got you some interesting answers. A sneeze, a martial art, and rather brilliantly ‘OBAMA bashing’ are all suggestions we’ve had.
In the last 12 months, however, I’ve seen a turnaround. OBASHI is getting recognised for what it is – a simple, easy to adopt methodology that maps dataflow through a business and supports meaningful conversations about investment, improvement, and business outcomes.
I’m also really happy to see that this recognition is coming from the folk in ITSM who actually work with the business. Consultants, outsourcers and business relationship managers are all starting to realize how OBASHI can help the business/IT conversation move forward.
Background to OBASHI
“A process cannot be understood by stopping it. Understanding must move with the flow of the process, must join it and flow with it”. Frank Herbert
The OBASHI methodology allows organisations to clearly understand what is involved in supporting their business processes. Simple, powerful information can be used to support business decisions, financial decisions and strategic planning.
OBASHI creates visual maps of businesses and parts of businesses. The maps are simple, visual references that can be understood by staff at all levels. The maps help businesses to understand:
- How the business works
- What assets and components make the business work and support its business processes
- What inter-dependencies exist between assets
- How data flows around the business
OBASHI produces Business and IT diagrams (BIT diagrams) that are used to map business processes (see image below).
The OBASHI layers of ownership, business process, application, system, hardware and infrastructure show the business process and the IT that underpins it.
OBASHI’s origins
“When we try to pick out anything by itself, we find it hitched to everything else in the universe”. John Muir
The OBASHI methodology was originally developed in 2001 by Fergus Cloughley and Paul Wallis. It was inspired by the computer models used within manufacturing and process industries to control and simulate the operation of infrastructure and plants.
The costs and values of manufacturing flows can be mapped, allowing the assets that support them to be optimised in a way that encourages maximum business profitability.
OBASHI develops and builds on the existing methods for costing and valuing the flow of data in the process control industry, and applies it to the flow of data in all sectors – including IT.
OBASHI is used to “help business professionals easily understand the ‘dollar per second’ value of dataflow that supports their business services and processes, in a simple and meaningful way. OBASHI is the basis on which they can make better informed and more accurate strategic, operational, tactical and technical decisions.”
Context
OBASHI is an interesting methodology because it applies to all types, sizes and sectors of organisation. It’s not targeted at a particular audience or area like ITIL® and PRINCE2®, and can be easily understood by business or IT focused staff.
For me, the value that OBASHI brings is in the way it enables business and IT conversation. ITIL (maybe because of its name) can be perceived as being ‘IT focused’ – OBASHI is open to anyone. I feel that treating the business and IT as separate entities is a big mistake for the modern organisation – IT runs through and enables every business action and business process.
Building up a library of dataflows mapped using OBASHI helps business and IT staff to have conversations together about risk, impact, investment, strategy and growth.
Who is using OBASHI?
Early adopters of OBASHI include one of the world’s leading Formula 1 motorsport teams and the UK’s Civil Nuclear Constabulary, but perhaps one of the most interesting users of OBASHI is the global Legal Entity Identifier (LEI) project.
At the behest of G20 group of nations and the Financial Stability Board, the Global LEI project has been created to proceed with development of a unique identification system for parties to financial transactions. For the past 12 months over 100 institutions from around the world have been working together on the project.
The largest financial project in the world, the Legal Entity Identifier, is a fundamental requirement if the process of addressing the systemic risks that caused the 2008 financial crisis is to have the best chance of success. The LEI will also help participants and regulators to analyse, quantify and understand systematic and operational risk across banking and other industries.
Operating in an environment where regulators and financial institutions operate within and across different jurisdictional boundaries, each with their own unique requirements, OBASHI provides:
- A Governance framework language for LEI policy and system design
- A Programme Management tool to help national, regional and political variations, both technically and operationally
- A practical, easy to create model of all the relationships and dependencies between all the business and technology components of the global LEI system
OBASHI is being used to create and maintain clarity in the LEI project – a ‘Common Language’ for technical and non-technical people, from diverse nationalities and business cultures, to understand and communicate about the project. With OBASHI the stakeholders can see how people, process and technology will be required to fit together to make the Global LEI Systems operate, this is helping them make the best-informed decisions.
When the LEI system is up and running it will be used to identify any and every participant, in any and every financial transaction globally.
Set this into a global operational context of thousands of implementations, each jurisdiction conforming to regional legal and regulatory requirements, capturing data in multiple languages and scripts, and all of that being used to update data in every other local LEI system and you start to appreciate the scale of the project.
Although the LEI project takes complexity to the next level, it’s easy to see that most businesses are becoming increasingly connected and complexity rises accordingly. Creating clarity and being able to communicate clearly will become ever more important. This is where OBASHI is very useful.
Resources
To learn more about OBASHI, you can visit the official OBASHI website, where you will find some excellent case studies and presentations that you can tailor to your organisation. Additional resource can also be found on the training website. The OBASHI training scheme is run by APMG International, and Foundation training is available both in the classroom and online.
You can view the list of OBASHI training providers online and also read up about the formal certification.
OBASHI® is a registered trademark in the United Kingdom and other countries
ITIL is a registered trademark of Axelos Ltd
PRINCE2 is a registered trademark of Axelos Ltd
A second blog will follow on where and how OBASHI fits in with other IT frameworks, standards, and methodologies, as well as taking a look at why an organisation might use OBASHI.
This article was written by Claire Agutter, Director and Head of Online Training, IT Training Zone Ltd with contribution from Fergus Cloughley, Director and CEO, OBASHI Ltd.
Hi Claire,
I remember you from the time I passed my ITIL expert exam sometimes in 2010…
Here is a question I posed to Paul Wallis (OBASHI ltd), which I’d like to share with you and have your views coming from an ITIL perspective:
“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 appendix D ‘How OBASHI fits with ITIL’.”
The point of the matter is that the hierarchy (stack) defined in ITIL (Service Design fig 3.7 page 46) is:
1) Business Unit (Ownership)
2) Business Process
3) Business services
4) Infrastructure (includes hardware/application/network..)
All can be mapped to the OBASHI model except….the Service layer that is not there. I trust that a ‘service layer’ in the OBASHI model would help immensely in promoting/ selling/ implementing ITSM or simply increasing ITSM maturity where definition of Service is KEY, and a powerful graphical representation (where OBASHI is very good at) would considerably help selling the ITSM values/benefit.
I am in the ‘business’ of defining services, and talking with busy people with ‘limited’ time so I need a way to illustrate graphically where Services sit with an End to End representation of all the underpinning IT components required to deliver that service. Having to go through a ‘story’ down the line of the Dataflow Analysis View (DAV) is interesting, valuable, and required but by then I would have ‘lost’ the audience. Nothing beats a picture (= 1000 words?). Hope this makes senses
What do you think?
Note: I would be very interested to know how you are progressing with
your second blog (…will follow on where and how OBASHI fits in with other IT frameworks, standards, and methodologies, as well as taking a look at why an organisation might use OBASHI).
Thanks in anticipation
Best’s
Herve
A response is required here; this is an excellent question!
Will do. Just pinged Claire. thankyou
Hi All
We didn’t ignore this, but I had a conversation with Herve via email instead 🙂
We had a great discussion in the linkedin group OBASHI too which I’d recommend you join.
Fergus Cloughley, OBASHI author said:
“Paul posted this recently, in reply to the ’How does ITIL services fit in with OBASHI’ 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.”
And I said “It’s an interesting question that you pose about OBASHI and IT services,
and I agree from an ITIL perspective it does feel like there is a layer
missing, connecting the relevant IT service to the business process it
supports.
However, in a way the OBASHI view makes sense to me based on
conversations I’ve had recently about the future of IT. Individual
business departments are buying their own IT services and infrastructure
(often referred to as ‘shadow IT’) and services are made up of multiple
supplier solutions (see the SIAM thinking that is emerging).
From this perspective, IT services don’t exist as a silo that supports
the whole business – instead each business process is directly supported
by IT infrastructure, as the business process itself relies so heavily
on IT. In other words, the IT service and the business process are
indistinguishable.
What businesses I’ve spoken to recently are concerned with is the
business process, not the IT service. They want to know about how to
invest in, protect and enhance the business process including
underpinning IT, which is the level of granularity that OBASHI provides.
These are just my thoughts – I’ve also posted your question on the
linkedin OBASHI group, so you may want to join that and see if there are
any responses.”
Thanks Claire, much appreciated.