7

OBASHI – Datenflüsse und Services dokumentieren

OBASHI hilft eine standardisierte, detailreiche und einfache Dokumentation der Datenflüsse und Services im Unternehmen zu erstellen. Erfahre in diesem Post wie das funktioniert und welche Regeln zu beachten sind.

Bisher habe ich mit niemanden über OBASHI sprechen können – es scheint niemand zu kennen. Das ist einer der beiden Gründe, warum ich OBASHI als ersten Hilfsmittel aus meinem Werkzeugkasten vorstellen möchte. Der zweite Grund ist, dass OBASHI leicht umzusetzen und vielseitig einsetzbar ist.

Ich bin immer auf der Suche nach Idee, um das Leben rund um die Modellierung von Services in der CMDB zu vereinfachen. Dabei bin ich zufällig auf die OBASHI Webseite gestoßen. Ich weiß gar nicht mehr so recht wie. Das Thema war interessant. Allerdings fand ich im Internet sehr wenig Informationen, so dass ich das APMG Buch gekauft habe. Seitdem ist OBASHI ein wichtiges Arbeitsmittel für mich.

OBASHI – worum geht es?

Im Prinzip ist OBASHI ein Regelwerk, wie die Abhängigkeiten und Datenflüsse zwischen Geschäftsprozessen und IT dargestellt werden. Mit diese Methode versteht man das eigene Geschäft, die Prozesse und IT wesentlich besser. Sie zeigt:

• Wie das Unternehmen arbeitet.
• Wie das Unternehmen durch die IT unterstützt wird.
• Welche IT-Assets dafür notwendig sind.
• Die Abhängigkeiten zwischen den Betriebsmitteln.
• Wie Daten durch das Unternehmen fliesen.
• Wie kritisch IT für das Geschäft ist.
• Welche Auswirkungen ein Fehler in der IT hat.

Was bedeutet OBASHI?

Die Business- & IT-Diagramme und die Data-Flow-Analysis-Views sind nach einer bestimmten Ordnung aufgebaut. Jeder Layer enthält genau definierte Objekte. Diese und die Layer selbst sind durch die Methode vorgegeben. 

 

Dadurch stellt sich ganz automatisch eine immer gleiche Struktur bei der Modellierung ein. Das ist in der Praxis ein ganz wichtiger Punkt. Viel zu häufig finde ich Dokumentationen oder Servicestrukturen, die unterschiedlich aufgebaut sind. Das erleichtert das Lesen und die Wiederverwendung nicht. 

Regeln

Im Prinzip kannst Du mit dieser kurzen Erklärung starten, Business-IT-Diagramme zu erstellen. Es gibt allerdings neun OBASHI-Gesetze und weitere Regeln, die hilfreich sind. Erzeugst Du die Dokumentation und Servicebeschreibung nicht nur für Dich allein, dann sollten alle Beteiligten die grundlegenden Vereinbarungen kennen – das erleichtert vieles.

OBASHI Laws

1. Ein Element kann jede Geschäftsressource oder Anlagegegenstand repräsentieren – egal ob materiell oder immateriell.
2. Ein Element kann nur in dem ihm zugeordneten OBASHI-Layer existieren. Es kann nicht über die Grenzen dieses Layers vergrößert werden.
3. Ein Element kann zu jedem anderen Element in Beziehung stehen.
4. Jedes Element kann über beliebige Attribute näher definiert werden.
5. Die Beziehung zwischen Elementen werden durch eine oder mehrere der sechs Beziehungstypen definiert.
6. Die sechs Beziehunstypen (Relationship Types) sind: Connection, Dependency, Spatial, Set, Layer und Sequential – genaue Erläuterung unter Beziehungstypen
7. Die Beziehungstypen befolgen die OBASHI Beziehungs-Regeln (Releationship Rules).
8. Die OBASHI-Methode erfüllt die Gesetze der Digitalen Dynamic.
9. Jeder Datenfluss kann durch beliebige Attribute näher definiert werden.

Es ist besonders wichtig, die Regel 1 bis 6 zu verinnerlichen. Das hilft beim Modellieren und Dokumentieren sehr. Die Regeln 6, 7, 8 und 9 sind nicht ohne weiteres Wissen umzusetzen. Erklärungen dazu erfolgen sofort.

OBASHI Law of Digital Dynamics

1. Damit ein Datenfluss existierte, muss der Fluss der Daten stattgefunden haben.
2. Ein Datenfluss hat zwei oder mehr beteiligte Elemente.
3. Ein Datenfluss kann aus einem oder mehreren Datenflüssen bestehen.
4. Eine Unterbrechung des Datenfluss bleibt nicht folgenlos.
5. Ein, einem Datenfluss zugehöriger Wert muss über die einzelnen Elemente aufsummiert werden.

Wichtig ist insbesondere Regel 4. Hat die Unterbrechung eines Datenflusses keine Folgen für das Geschäft, so ist er sinnlos und kann abgeschalten werden. 

OBASHI Relationship Types (Beziehungstypen)

Connection: Die Verbindung ist die am häufigsten verwendete Beziehung in einem OBASHI Diagramm. Jedes Element kann eine Verbindung zu einem Element im darüber- oder darunterliegenden Layer haben. Es handelt sich dabei um den Weg des Datenflusses. Die Verbindung ist bi-direktional und kaskadiert zwischen den Elementen. Eine Verbindung kann ebenfalls innerhalb eines Layers existieren. Folgende Übersicht verdeutlicht zwischen Elementen welcher Layer Verbindungen erlaubt sind:

Die Farbe der Verbindung ist Schwarz! OBASHI kennt eine definierte Farbgebung. Diese möchte ich in diesem Artikel vorerst nicht weiter ausführen.

Dependency: Die Abhängigkeit ist gerichtet und kann über mehrere Layer hinweg gezeichnet werden. Sie soll die Abhängigkeit zweier Objekt klar zum Ausdruck bringen und wird als roter Pfeil eingezeichnet:

Layer: Es existiert implizit eine Beziehung zwischen Elementen im gleichen Layer. Mehr dazu in der Relationship-Rule 2

Set: Ein Set ist eine logische Gruppierung von Elementen, die über ein oder mehr Business-IT-Diagramme zusammengefasst werden. Jedes Element kann zu einem Set zusammengefügt werden. Ein Element kann in mehreren Sets genutzt werden. Ansonsten gibt es keine weiteren Regeln.

Ich nutze Sets, um die Komplexität der Darstellungen zu reduzieren. Typische Sets sind: Virtualisierungsumgebung, Backbone-Netzwerk und DMZ – um ein paar Beispiele zu nennen. Der Vorteil ist, dass ich sie einmal dokumentiere und dann wiederverwende.

Sequential: Eine Sequenz besteht aus verbundenen (Connection) oder abhängigen (Dependency) Elementen, die einen Datenfluss modellieren. Es ist eine geordnete Liste von Elementen. Sie stellen immer den Datenfluss vom Erzeuger zum Konsumenten dar.

Spatial: Die wohl gewöhnungsbedürftigste Beziehung ist die räumliche (spatial) Beziehung. Diese wird durch die Angaben über die X- und Y-Achse und spezielle Regeln näher definiert. Genau das macht es so kompliziert.

Die Beziehung ist implizit. Es werden räumliche Beziehungen beschrieben, um beispielsweise auszudrücken, dass eine Element Teil eines anderen ist. Sie sind insoweit wichtig, dass der Leser sich darauf verlassen kann, dass die entsprechenden Beziehungen gemeint sind und nicht ungenaue Zeichnungen:

 

Relationship Rules (Beziehungsregeln)

Einige Beziehungs-Typen ergeben sich einfach aus den Regeln, die für Beziehungen in OBASHI gelten:

1. Ein Element, welches über oder unter einem anderen Element platziert wird, hat eine implizite Beziehung zu diesem.
2. Alle Elemente in einem Layer haben eine implizite Beziehung zu einander.
3. Verbunde Elemente haben eine explizite Beziehung zueinander. Es gelten die Regeln für die Verbindung (Connection).
4. Eine Abhängigkeit (Dependency) ist gerichtet. Das bedeutet, dass wenn Element B von Element A abhängig ist, Element A nicht von Element B abhängig sein muss. Diese Abhängigkeit müsste zusätzlich eingezeichnet werden.
5. Ein Element kann eine oder mehrere Instanzen innerhalb eines Layers haben.
6. Ein Element kann in einem oder mehreren Business-IT-Diagrammen existieren.
7. Ein Datenfluss umfasst zwei oder mehr verbundene oder abhängige Elemente.
8. Ein Datenfluss kann einen oder mehrere Datenflüsse enthalten. Dies ermöglicht eine Hierarchie von Datenflüssen.
9. Ein Datenfluss kann mehrere Business-IT-Diagramme umfassen.
10. Beziehungen zwischen den Elementen sind über alle Business-IT-Diagramme persistent.

Unter Umständen schrecken Dich die vielen Regeln ab. Lass Dich bitte davon nicht verwirren, sondern zeichne einfach Deine ersten Business-IT-Diagramme. Du wirst sehen, dass geht einfach und bringt eine sehr große Klarheit in die Dokumentation. 

Hier ein Beispiel für ein einfaches Business-IT-Diagramm:

Ich kann OBASHI wirklich nur empfehlen. Es erleichtert mir die Arbeit sehr und hilft meinen Kunden die Dinge auch nach dem Projekt zu verstehen. 

Jetzt kommt sicher die Frage nach geeigneten Softwarelösungen, oder? Naja, es ist eine Methode und ein Hilfsmittel. Damit sollte es unabhängig von einer Software funktionieren. Das B&IT-Digramm über diesem Abschnitt ist mit Visio gezeichnet. Das ist für die Dokumentation ok, für Analysezwecke ungeeignet.

Jede Software, die es erlaubt Abhängigkeiten für die Servicemodellierung zu definieren, sollte geeignet sein. Ich selbst nutze natürlich das Werkzeug, welches mein Team bei SHD entwickelt: SM-VIEW. Das ist auch kein OBASHI-Werkzeug, sondern bietet die Möglichkeit Services grafisch zu modellieren und Live-Status zu hinterlegen. Das ist Visio in Wiederverwendung und Analysefunktion weit überlegen. 

Weitere Ressourcen:

OBASHI Webseite: http://www.obashi.co.uk/

Einführungsvideo: https://www.youtube.com/watch?v=iwjGE2IlNvY

offizielles APMG Buch: http://www.apmg-businessbooks.com/productInfo.aspx?prodid=1155

englische Mindmap zu OBASHI: http://www.mindmeister.com/de/357727077/obashi-methodology-study-guide-mind-map