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.
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.
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.
For this method to work, some rules must be followed:
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.
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.
We now know the types with which elements can be connected within an OBASHI diagram. However, these connections follow a set of unique rules:
Even though these rules seem highly complicated at first glance, most comprehension problems dissolve once the first OBASHI diagrams have been made.
Not only OBASHI follows clear rules. Data flows are also subject to certain laws that should be observed when developing OBASHI diagrams.
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.