OBASHI – The connection of business processes and IT

Bild von Pattrick Bluhm Pattrick Bluhm
Mar 8, 2022 8:49:00 AM | Reading Time: 4 Min.

Recording and modelling services regularly presents companies with a challenge. The big problem: there is no uniform concept! Every employee has a different view of the services and their components. Often, only those components are listed in the service that are essential for the employee. Accordingly, each service is structured differently. Each staff member has his or her own way of describing them and structuring their content. This often results in comprehension problems for the other “readers”.

The goal must therefore be to use a standard with which a multitude of services can be modelled and presented in a way that is understandable and transparent for all involved.

OBASHI as a solution to the problem

At first you will think: “OBASHI? Is that a new Japanese management method”. However, OBASHI could not be more British. But what is this concept all about? And how does this method help you to better understand the data flows in your company?

OBASHI is a method for modelling services. More precisely, this method helps you to represent the data flows between business processes and IT. OBASHI is little known in this country, but is used internationally across all industries.

In this method, services are represented in 6 levels. This approach ensures that employees actively deal with the services and know the necessary components. The clear structure of this model also makes services comprehensible for everyone involved.

obashi-en

Each level in OBASHI addresses an area of the service tree. It quickly becomes clear that not only services are modelled here, but that this information can also be used in everyday life. For example, if a server fails, it is immediately apparent which services are affected. The responsible persons are thus quickly informed. Prioritising tasks and, if necessary, bridging services until the server is fully restored is easy to implement.

IT executives in particular often find it difficult to make clear how important IT really is for the company. Budget cuts and hours of meetings to explain expenses or defend them are something you will encounter in most companies. By modelling with the OBASHI method, you have a visualised view of all business processes in the company. At any time you have the possibility to show how the company works and what is needed for it.

OBASHI Rules

For this method to work, some rules must be followed:

An element represents exactly one (physical or virtual) resource.
An element can only exist in one layer and cannot be enlarged over several layers.
Each element can be described by freely selectable attributes.
Each element can be related to any other element.
Each element has a colour defined by the OBASHI standard. Colours that are not part of the standard must be explicitly explained in a legend.
These relationships are defined by one (or more) of six types.
These relationship types are:
a) Connection
b) Dependency
c) Spatial (spatial relationship)
d) Set (grouping)
e) Layer (relationship in the same layer)
f) Sequential (data flow connection)
The relationship types follow certain rules (relationship rules).
OBASHI fulfils the data flow rules.
Each data flow can be described in more detail by freely selectable characteristics.

In fact, the OBASHI standard prescribes a well-defined colour for each element type (e.g. #abdebe for the infrastructure layer and #d5b7e1 for the ownership layer). These colours are to be used in each diagram. Any colours that do not follow the standard must be explained in an attached legend.

In this lineup, we encounter some things that we may not understand immediately. What is a spatial relationship? What is it about relationship rules? And what are data flow rules? In the following, we clarify these terms.

OBASHI relationship types

As already mentioned, elements can be linked in different ways. The simple connection and the dependency are still easy to understand here. The connection is the most common way in which one element can be linked to another. The other element is then one level higher or one level lower. Dependency, on the other hand, can exist across multiple levels. Finally, invoicing (layer B) is directly dependent on the functioning of the corresponding server (layer H) with the CRM system.

A layer type relationship exists when two elements in the same layer are linked.
A group of elements (set) is used when several elements logically belong together. This is the case, for example, with virtual machines: physical server, operating system, VM software, guest system, etc. .

A sequence is always used when the data flow from the data creator to the data receiver is to be represented.

It gets a bit more complicated when talking about spatial relationships. This type of relationship is used to describe an affiliation of one element to another. If element A is a part of element B, it is a spatial relationship. This relationship type is probably the most complex in the OBASHI world.

OBASHI relations must be regulated

We now know the types with which elements can be connected within an OBASHI diagram. However, these connections follow a set of unique rules:

The elements within a layer are implicitly related to each other.
If an element is above or below another element, an implicit relationship exists.
Connected elements have an explicit relationship to each other.
Dependency is always directed (invoicing is dependent on CRM, but CRM is not dependent on invoicing).
An element can occur in one or more sets.
Elements can have one or more instances in a layer.
Data flows always contain two or more elements that are connected or dependent on each other.
A data flow can contain (one or more) data flows. Thus, the mapping of data flow hierarchies is possible.
A data flow can contain several sets.
Relationships between elements are permanent.

Even though these rules seem highly complicated at first glance, most comprehension problems dissolve once the first OBASHI diagrams have been made.

OBASHI and the data flow rules

Not only OBASHI follows clear rules. Data flows are also subject to certain laws that should be observed when developing OBASHI diagrams.

A data flow can only exist if data has actually flowed.
At least two elements are always involved in a data flow.
A data flow can contain further data flows.
If a data flow is interrupted, this must have a consequence.

At first glance, these points are self-evident and seem banal. In fact, however, they hold potential. For example, if a data flow has been defined between two elements, but no data is transferred at all, then no data flow exists.

Please pay particular attention to point 4: If a data flow is interrupted, there must be a noticeable consequence. If the interruption has no consequences, switch off the data flow directly. Because then it is then irrelevant for your company.