Bilder sagen mehr als 1000 Worte

Wir leben in einer Welt, in der wir von Bildern förmlich überschwemmt werden. Täglich werden Milliarden von Bildern gemacht, verbreitet und auch konsumiert. Sei es im Internet beim Lesen von Webseiten, beim Streamen von Filmen oder durch das Hochladen von Selfies auf diversen Social Media Plattformen.

Im Gegensatz zu Tieren ist der Mensch das einzige Lebewesen, das aktiv Bilder erschafft und sie gleichzeitig konsumiert. Die frühesten vom Menschen erstellten Bilder sind etwa 73.000 Jahre alt [1]. Handabdrücke und abstrakte Malereien in Höhlen zeigen, dass Bilder schon sehr früh eine wichtige Rolle spielten. Es wird vermutet, dass diese frühen Bilder nicht nur Abbildungen der Realität waren, sondern eine zusätzliche Bedeutung hatten: Sie wurden oft als die dargestellten Objekte oder Wesen selbst wahrgenommen [2].

Der Ursprung der Bilder im Business

Während die Sprache schrittweise vorgehen muss, präsentieren Bilder Informationen simultan und auf einen Blick. Sie erleichtern das Verständnis, die Kommunikation und die Zusammenarbeit, insbesondere wenn es darum geht, die Kluft zwischen Teams und Fachexperten zu überbrücken.

In der heutigen IT-Landschaft spielen Bilder – als visuelle Darstellungen in Form von Diagrammen – eine entscheidende Rolle. Sie können

• Ordnung und Überblick schaffen,
• abstrakte Zusammenhänge verständlich machen,
• Wissen speichern und weitergeben,
• komplexe Aufgaben beherrschbar machen, sowie
• Kommunikation strukturieren und vereinfachen.

Damit der Ersteller des Bildes sicher sein kann, dass der Betrachter das Bild auch wirklich versteht, hat man im Laufe der Zeit unterschiedlichste Notationen entwickelt. In der Vergangenheit wurden unterschiedlichste Sprachen entwickelt. Zum Beispiel zur Dokumentation von Abläufen der Programmablaufplan [3] oder das Nassi-Shneiderman-Diagramm [4]. Oder das Datenflussdiagramm [5] zur Beschreibung von Datenflüssen.

Die älteste Norm, die mir jedenfalls bekannt ist, stammt aus dem Jahr 1966: die DIN-66001 [6]. Sie wurde entwickelt, um die Erstellung von „Sinnbildern“ zu standardisieren. Diese Norm enthält auch heute noch gängige Elemente wie Operation, Verzweigung und Unterprogramm – also Bausteine, die in der Informatik immer noch eine große Rolle spielen.

Abbildung 1: Sinnbilder für Programmabläufe aus DIN-66001

Aber neben diesen eher zeitlosen Darstellungen wurden in dieser Norm auch Elemente definiert, die man nur mehr im Museum antreffen wird (zumindest hoffe ich das).

Abbildung 2: Sinnbilder für Datenflusspläne aus DIN-66001

Aufgrund der zunehmenden Komplexität in der IT, der steigenden Anzahl von Personen, die in oder mit der IT arbeiten, aber auch die Teilnahme von unterschiedlichsten Bereichen, reichten die bestehenden Notationen nicht mehr aus. Sie konnten entweder nicht mehr neue Anforderungen erfüllen, waren nicht mehr aktuell genug oder die Zielgruppe hat sich erweitert.

Es wurden daher neuere und mächtigere Sprachen entwickelt, wobei ich hier wegen der breiten Akzeptanz UML und BPMN erwähnen will, aber mir bewusst ist, dass es noch viele weitere Sprachen gibt.

Die Evolution der Bilder

UML (Unified Modeling Language) und BPMN (Business Process Model and Notation) sind zentrale visuelle Sprachen zur Modellierung von Systemen und Prozessen. UML- und BPMN-Diagramme dienen als gemeinsame Sprache zwischen IT-Experten und Fachexperten und sind etablierte und weit verbreitete Notationen.

UML ist die am weitesten verbreitete Sprache für die Modellierung von Softwaresystemen. Sie erschien bereits in den 1990er-Jahren und wird von der Object Management Group (OMG) [7] gepflegt und ist auch von der International Organization for Standardization [8] standardisiert. Die Erfinder von UML – auch bekannt als die Drei Amigos [9] – wollten dabei nicht nur mehrere bestehende und zum Teil konkurrierende Systeme zu einem einheitlichen Standard zusammenführen, sondern neben der Darstellung in Form von Modellen auch eine grafische Notation auf Teilausschnitte der Modelle ermöglichen.

Hier bietet UML eine Vielzahl von Diagrammen zur Dokumentation, z.B. für Klassen, Aktivitäten, Kommunikation, Sequenzen oder auch Status. Neben diesen gängigen Elementen existieren aber auch weitere wie Namespaces & Packages zum Organisieren oder auch Vorlagen (Templates).

Abbildung 3: Beispiel von DurationConstraints und TimeContraints im UML Sequenzdiagramm [10]

Als eine weitere Beschreibungssprache bietet BPMN eine standardisierte Notation zur Modellierung von Geschäftsprozessen und erleichtert das Verständnis und die Analyse komplexer Workflows. BPMN wurde von IBM-Mitarbeiter Stephen A. White in 2004 entwickelt und erlangte 2006 den Status eines Standards durch die OMG.

Das Hauptaugenmerk von BPMN ist dabei die Darstellung von Prozessen. Sie erfolgt als Business Process Diagram, die der einfachen grundlegenden Struktur folgt:

• Knoten bilden Aktivitäten, Verzweigungen oder Events ab und diese werden mittels Kanten verbunden. Im nachfolgenden Beispiel sind zum Beispiel einfach Aktivitäten „Pack goods“ oder „Ship Goods“. Komplizierte Aktivitäten mit mehreren Schritten wie „Process Order“ werden als Subprozesse festgehalten.
• Diese Knoten und Kanten werden in Bereiche zusammengefasst und werden einem Akteur zugeordnet. Diese Bereiche heißen dann Swimlane.
• Mehrere Swimlanes ergeben einen Pool, wobei ein Pool dann einem System oder einer organisatorischen Einheit zugeordnet sein kann.

Die Business Process Diagrams (BPD) werden dabei von links nach rechts gelesen und entsprechen damit der zeitlichen Abfolge der Aktivitäten, Prozesse oder Ereignisse.

Abbildung 4: Beispiel für BPMN mit Message Flows connecting to Flow Objects with two Pools [11]

UML und BPMN sind aber keine Konkurrenten, auch wenn man das vermuten könnte, sondern sie ergänzen sich. BPMN beschreibt dabei den Geschäftsprozess (WAS soll passieren?) und UML beschreibt hier die Umsetzung (WIE wird es implementiert?). UML kann somit genutzt werden, um die technischen Details für die Implementierung dieser Prozesse zu definieren.

Die (mögliche) Mächtigkeit der Bilder

Heute werden UML und BPMN oft „nur“ zur Darstellung verwendet, und für den Anwender zählt meist nur die grafische Darstellung, das zugrunde liegende abstrakte Modell ist jedoch zweitrangig. Dadurch werden potentielle Vorteile nicht genutzt, die Anwendung wird auf reines „Zeichnen“ statt auf „Modellieren“ reduziert

Die weiteren Möglichkeiten von diesen Beschreibungssprachen wären z.B. folgende:

• Der Austausch zwischen unterschiedlichen Werkzeugen zur Weiterverwendung,
• Modell Driven Architecture [12] zur Generierung von Artefakten basierend auf dem Modell,
• Optimierung von Prozessen,
• automatische Validierung mit Tools wie Enterprise Architect [13] oder
• automatische Ausführung mittels BPEL [14] oder durch Business Orchestration durch Camunda [15].

Ungeachtet dessen helfen aber beide Sprachen bei der Spezifikation, Konstruktion, Dokumentation und Visualisierung von Software und anderen Systemen. Zudem können die Modelle von allen Stakeholdern in gleicher Weise verwendet werden, wenn auch der Grad und Zweck der Verwendung unterschiedlich sein kann.

Die Produzenten und Konsumenten der Bilder

Fachexperten können UML und BPMN je nach persönlicher Kenntnis verwenden. Die Grundelemente sind dabei schnell erlernbar und die Kombination dieser einfachen Elemente ermöglicht nach kurzer Erklärung die Erstellung und Dokumentation komplexerer Zusammenhänge. Aber auch wenn hier die Erstellung von Diagrammen durch Fachexperten nicht unbedingt im Vordergrund steht, so erlangt ein Fachexperte schnell grundlegendes Leseverständnis und dies fördert den Informationsaustausch.

Business Analysten können z.B. mit Hilfe von Use Case Diagrammen die Interaktionen zwischen Akteuren (Benutzern oder anderen Systemen) und dem System darstellen und dies hilft, die Systemfunktionalitäten zu überblicken, Anforderungen zu dokumentieren und diese mit Fachexperten abzustimmen. Business Analysten können einzelne Schritte eines Prozesses dokumentieren, Entscheidungswege darstellen und Ineffizienzen oder Verbesserungspotenziale identifizieren.

Softwarearchitekten können Diagramme verwenden, um Systemdesigns nicht-technischen Stakeholdern zu präsentieren und sicherzustellen, dass die vorgeschlagene Lösung mit den Geschäftsanforderungen übereinstimmt und die Architektur diese unterstützt.

Softwareentwickler können mithilfe von Diagrammen abgestimmte Anforderungen bei der Implementierung mit weniger Rückfragen selbständiger umsetzen. Neben der rein textuellen Information in User Storys können hier Diagramme den notwendigen Überblick über Prozesse und Abläufe bei Schnittstellen zwischen Systemen oder auch relevante Details wie Statusdiagramme oder Datenmodelle liefern. Diese Ergänzungen ermöglichen Entwickler selbständig und ohne (oder mit weniger) Rückfragen die geplanten Arbeiten zu erledigen.

Sicherheitsbeauftragte wie CISOs oder Security Engineers könnten Diagramme auf verschiedene Weise verwenden, um die Informationssicherheit zu visualisieren, zu planen und zu verwalten. Ein CISO kann Diagramme verwenden, um komplexe Sicherheitskonzepte und Sachverhalte verständlich zu erklären und die Notwendigkeit von Investitionen in die Sicherheit zu verdeutlichen.

Die Gefahr bei Bildern

Neben all den Vorteilen sollen auch mögliche Nachteile und Einschränkungen nicht unerwähnt bleiben:

• Diagramme können die für komplexe logische Beziehungen erforderliche Präzision und Detailtiefe vermissen lassen. UML- und BPMN-Diagramme erfassen möglicherweise nicht alle Nuancen eines Systems oder Prozesses, wenn sie zu stark vereinfacht werden.
• Eine übermäßige Abhängigkeit von visuellen Elementen kann zu übermäßigen Vereinfachungen führen. Komplexe Probleme werden möglicherweise auf leicht verdauliche, aber letztendlich unzureichende Diagramme reduziert.
• Auch kann durch die übermäßige Verwendung der Fähigkeiten der Werkzeuge ein umgekehrter Effekt erzeugt werden, nämlich die Schaffung von Distanz zum Fachexperten. Man sollte nicht alle Möglichkeiten von UML oder BPMN ausschöpfen, denn dadurch wird der fachliche Jargon übergeführt in eine neue Sprache – dem Jargon von UML und BPMN.
• Das Erstellen und Pflegen detaillierter UML- und BPMN-Diagramme kann zeitaufwendig sein, insbesondere bei großen und komplexen Systemen. Wenn der Aufwand den Nutzen überwiegt, ist es möglicherweise keine lohnende Investition.
• Eine übermäßige Abhängigkeit von Werkzeugen kann eine Abhängigkeit von bestimmter Software erzeugen und potenziell die Flexibilität und Zusammenarbeit behindern, wenn Beteiligte andere Werkzeuge verwenden oder einfachere Methoden bevorzugen. Oder finanzielle Aspekte wie Anschaffungs- und Lizenzkosten eine breite Verwendung verhindert.

Und zu guter Letzt können Texte oder Sprache in zahlreichen Kontexten etwas transportieren, was mit Bildern nur sehr mühsam, wenn überhaupt, transportiert werden kann.

Fazit

Visuelle Darstellungen sind in der IT unverzichtbar. UML und BPMN bieten wertvolle Werkzeuge, um komplexe Sachverhalte zu modellieren und die Kommunikation zwischen technischen Teams und Fachbereichen zu verbessern.

Doch die Macht der Bilder birgt auch Gefahren. Bilder können verkürzen und verknappen. Daher ist es entscheidend, visuelle Modelle in Verbindung mit textuellen Dokumentationen und mündlicher Kommunikation zu verwenden, um ein umfassendes Verständnis des Systems sicherzustellen.

Durch einen bewussten und kritischen Einsatz von Bildern können IT-Projekte erfolgreicher gestaltet und die Zusammenarbeit mit allen Stakeholdern optimiert werden. Es ist jedoch wichtig, sich der potenziellen Nachteile bewusst zu sein und visuelle Modelle durch andere Kommunikationsformen zu ergänzen, um ein umfassendes Verständnis zu gewährleisten.

Hinweise:

Wenn Sie sich für weitere Informationen und Perspektiven zu Modellierung, Business Analyse, Cloud-Technologien oder Quantum Computing interessieren, dann lohnt sich mit Sicherheit ein Blick auf den Blog von Gottfried Szing: https://kjoo.be.

[1] ARD alpha: Die ältesten Wandbilder der Welt
[2] Britannica: Cave Art
[3] Wikipedia: Programmablaufplan
[4] Wikipedia: Nassi-Shneidermann-Diagramm
[5] Wikepedia: Datenflussdiagramm
[6] Informationsverarbeitung Sinnbilder für Datenfluss- und Programmablaufpläne
[7] Object Management Group (OMG)
[8] International Organization for Standardization (ISO)
[9] Three Amigos
[10] Beispiel für Sequenzdiagramm aus der UML
[11] Beispiel aus der BPMN-Norm
[12] OMG: The Architecture of Choice for a Changing World
[13] Enterprise Architect
[14] BPEL
[15] Camunda

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. 

Gottfried Szing hat zwei weitere Beiträge im t2informatik Blog veröffentlicht: