News, Reviews and Resources for ITSM Professionals.

What exactly is "OBASHI"?

Home » Practices » What exactly is "OBASHI"?

Obama

OBASHI has nothing to do with President Obama!

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.

obashi.jpg

OBASHI Business and IT Diagram

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

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.

Image Credit




9 Responses to " What exactly is "OBASHI"? "

  1. […] dem Konzept des Business-Service-Management und / oder OBASHI lässt sich dieses Thema auch für mittelständische Unternehmen beherrschbar umsetzen. OBASHI […]

  2. Herve MESLIN says:

    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

    • bjake says:

      A response is required here; this is an excellent question!

    • Claire Agutter says:

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

      • Claire Agutter says:

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

  3. […] dem Konzept des Business-Service-Management und / oder OBASHI lässt sich dieses Thema auch für mittelständische Unternehmen beherrschbar umsetzen. OBASHI […]

Product Group Tests

Article by Topic