Für die Einführung eines zum jeweiligen Unternehmen passenden Modellierungsansatzes sind viele Schritte notwendig, die ich hier skizzieren möchte. Ein notwendiger Anfang ist dabei sicher der Kauf eines Modellierungswerkzeugs und die Einübung in dessen Bedienung. Wenn wir aber von Modellierung sprechen, dann geht es in Wirklichkeit um mehrere Dimensionen: Modellierungssprache, Werkzeug, Methode und zuletzt die Erfahrung im Umgang mit all dem.
Jede dieser Dimensionen ist ein eigenes Thema. Um zu funktionieren müssen letztlich alle Dimensionen wie Zahnräder ineinandergreifen. Dies macht den Anfang für Einsteiger anspruchsvoll, weil gleich drei Dimensionen gleichzeitig zu lernen sind. Die Erfahrung kommt dann praktisch von selbst mit der Praxis. Aus Erfahrung weiß ich, dass nicht jede Person im Team in jeder dieser Dimensionen Expertenstatus erlangen kann. Praktikabler ist es, einen geeigneten Modellierungsansatz für das Unternehmen mit Hilfe eines Experten in einer kleineren Gruppe fortgeschrittenen Modellierer zu erarbeiten. Das Ergebnis dieses ersten Schrittes ist ein Referenzmodell, das sich mit der Zeit weiterentwickelt und als Grundlage für Schulungen und Anpassungen dient.
Mein Tipp aus der Praxis: Wird im Team modelliert, sollte das gesamte Team in all den Dimensionen zumindest auf dem „Advanced Level“ (siehe Grafik) sein. Auch wenn alle Teammitglieder Modellierungs-Experten sind und über langjährige Erfahrung im Umgang mit modellbasierten Ansätzen verfügen, ist es notwendig, sich über die konkrete Vorgehensweise mit dem gewählten Werkzeug Gedanken zu machen. Um den mit der Modellierung zunächst verbunden Mehraufwand zu rechtfertigen, ist es wichtig, die Einführung gut zu planen und die Mitarbeiter gezielt zu unterstützen. Nur so lassen sich die Vorteile der Modellierung schnell und effizient nutzen.
Mögliche Szenarios für die Einführung eines passenden Modellierungsansatzes
1) Einführung ohne Planung
In diesem Szenario findet sich im Unternehmen niemand, der das Thema Modellierung strukturiert angeht, konkrete Ziele definiert und die notwendigen Modellstrukturen und Richtlinien (das Referenzmodell und das Metamodell) erarbeitet. So entwickeln sich nur Insellösungen, die zwar oft gut durchdacht aber miteinander nicht kompatibel sind. Typisch in diesem Szenario ist, dass ein weitgehend unerfahrenes Team mit großen Einsatz viele sehr detaillierte Modelle erstellt, die aus Zeitmangel nicht aktualisiert und damit wertlos werden. Durch die Desorganisation wird die Modellierung als Qual empfunden, niemand kennt sich in den Modellen der anderen aus. Auch wird zu viel Zeit damit verschwendet, für gegebene Probleme ein passendes Modell zu finden.
2) Komplex und ohne Unterstützung
In diesem Szenario wird zwar ein Ziel gesetzt und dieses auch mit konkreten Vorgaben und Regeln versehen. Obwohl also klar vorgegeben ist, wie das Ziel erreicht werden soll – wie hat das Modell auszusehen und wann soll welche Information modelliert werden – ist dieser Prozess aber zum gegebenen Zeitpunkt zu kompliziert aufgesetzt. Die beteiligten Personen haben keine Zeit, sich in die Struktur einzuarbeiten und arbeiten nicht oft genug mit dem Modell, um die einzelnen Arbeitsschritte und Ansätze zu verinnerlichen.
Dieser Ansatz ist ähnlich zum iterativen, mit einem wesentlichen Unterschied. Beim iterativen Ansatz (siehe unten) ist nicht nur das Ziel mit den Regeln vorgegeben, sondern es wird auch ein Belastungstest mit dem Ziel durchgeführt, nötigenfalls den Ansatz bzw. das Werkzeug anzupassen, um ohne großen Aufwand den gewünschten Mehrwert aus den Modellen zu gewinnen.
3) Hauruck-Ansatz
Ein oft zum Scheitern verurteilter Ansatz ist die Suche nach einem umfassenden Master-Ansatz, mit dem alle Probleme gelöst werden sollen. Dazu wird eine kleine Gruppe mit der Ausarbeitung des Ansatzes beauftragt. Aufgrund fehlender Erfahrung und keiner Erprobung in der Praxis wird der gefundene Modellierungsansatz von den Kollegen nicht akzeptiert, weil sie sich nicht wieder finden und bereits eine eigene, für sie praktische Arbeitsweise entwickelt haben.
4) Iterativ
Beim Iterativen Ansatz macht man sich zuvor Gedanken darüber, welches Ziel man erreichen möchte. Dabei unterscheiden wir allerdings in große strategische Ziele und Ziele, die auch innerhalb weniger Monate erreicht werden können. Der iterative Ansatz ist vergleichbar mit dem Ansatz „Komplex ohne Unterstützung“. Der Unterschied liegt in der Konzentration des Modellinhalts auf die allerwichtigsten Fragen, die man mit dem Modell beantworten möchte.
Der Idealfall: Ein Iterativer Einführungsprozess
Ein iterativer Ansatz ist also zu bevorzugen, da man schnell Feedback aus der Praxis erhält und gegebenenfalls den Ansatz adaptieren kann. Um nun die langfristigen strategischen Ziele zu definieren und einen Ansatz für die kurzfristigen Ziele zu erhalten, schlage ich den nachfolgenden Zyklus vor. Dieser Prozess wird im Sinne der Agilität möglichst rasch durchlaufen, um die Lösungsansätze für die gesteckten Ziele praktisch überprüfen zu können. Das verhindert eine Entwicklung in die falsche Richtung, da das Team laufend Feedback gibt und sich in den getroffenen Entscheidungen wiederfindet. Dass der iterative Ansatz also von Beginn an vom Team mitgetragen wird, verbessert sowohl die Akzeptanz als auch die Qualität!
Die ersten Schritte
Zuerst sollten die Mitarbeiter mit der größten Modellierungserfahrung und diejenigen, die wissen, welche Fragen mit dem Modell beantwortet werden sollen, an einem Expertenworkshop teilnehmen. Dieser gibt einen Überblick über alle Modellierungsaspekte und -möglichkeiten. Als Ergebnis erhält man Grundlagen-Wissen, das beim Erstellen des Beispielprojekts hilfreich sein wird.
Basierend auf den gelernten Grundlagen und vermittelten Erfahrungen wird nun ein kleines, überschaubares Projekt erstellt. Dabei werden alle Informationen bespielhaft abgebildet, die mit dem Modell beantwortet werden sollen. Die Erstellung des Beispielprojektes kann von einem Experten begleitet werden (Experten-Review), um eine optimale Abbildung der Informationen in ein Modell zu gewährleisten, ohne dabei zu viel Zeit durch mehrmalige Iterationen zu verlieren. Dabei sollten auch Aspekte wie die Generierung von Dokumenten, Verwaltung von Modellen und Modell-Versionen, Generierung von Code, etc. Berücksichtigung finden.
Als Ergebnis dieser ersten Schritte erhält man ein Beispielmodell (Referenzmodell) und damit das wichtigste Artefakt des Modellierungsansatzes.
Ein Belastungstest gibt Sicherheit
Um die Arbeit mit dem nun gefundenen Modellierungsansatz reibungsloser und flüssiger zu gestalten, wird nun die Arbeitsweise in einer Art Belastungstest überprüft. Dafür wird der Modellierungsansatz in eine etwas erweiterte Runde getragen, um Feedback über die Vorgehensweise zu bekommen bzw. ob bestimmte Informationen fehlen oder die Arbeitsweise als umständlich empfunden wird. Werden bei Erstellung oder Auslesung des vorgeschlagenen Referenzmodells aufwendige Schritte gefunden, lassen sich diese durch eine eigene MDG-Technologie erleichtern. Sie enthält Konfigurationen, die die Arbeit erleichtern bzw. vereinheitlichen. Darüber hinaus lassen sich auch Automatismen und für den eigenen Ansatz erforderliche Funktionen als Erweiterungen (Add-ins) erstellen. Auf der Basis des Referenzmodells sowie des Projekt-Metamodells und der Anpassungen im Werkzeug sollte nun ein Training folgen, in dem genau auf die Bedürfnisse der Gruppe eingegangen wird. Das Training basiert auf dem Referenzmodell und dem daraus abgeleiteten Projekt-Metamodell und fokussiert auf die Bedürfnisse der Gruppe. Diese praktiziert dabei die zuvor erarbeitete und bereits überprüfte Arbeitsweise an konkreten Beispielen aus der Domäne.
Die Basis der Modellierung: Das Referenzmodell
Das Referenzmodell umfasst viele Aspekte. Wie der Name schon sagt, handelt es sich um ein Modell-Repositorium, mit dessen Hilfe ein Verständnis über den gewünschten Modellierungsansatz entsteht und das als Basis für weitere Projekte dient. Das aktuell fertiggestellte Referenzmodell enthält alle notwendigen Konfigurationen und Anpassungen, um das gewünschte Ergebnis zu erreichen.
Der grundlegende Gedanke eines Referenzmodells ist es, die grundsätzlichen Fragen „Wer liest das Modell?“ und „Was soll aus dem Modell gelesen werden?“ für ein kleines, überschaubares Beispiel zu beantworten. Bei der Erstellung dieses Beispielmodells leiten wir folgende Informationen ab:
- Methode: Die Methode legt fest, wann welcher Teil des Modells erstellt wird. Daraus leiten sich die Modellstruktur und die verwendeten Modell-Elemente ab.
- Modellstruktur: Die Modellstruktur gibt den Rahmen vor, in dem das Modell enthalten ist, dient als Orientierung bei der Navigation durch das Modell und ist die Grundlage für die Generierung von Dokumenten.
- Modell-Elemente: Wir verwenden eine oder mehrere Modellierungssprachen, aber selten alle Modell-Elemente aus diesen Sprachen. Es ist wichtig zu definieren, wann welche Modell-Elemente für welchen Zweck verwendet werden und vor allem wie diese verbunden werden dürfen. Basierend auf der Modellstruktur wird definiert, welche Modell-Elemente auf welcher Abstraktionsebene wie miteinander verbunden werden.
Das Projekt-Metamodell
Im nächsten Schritt müssen wir das erstellte Beispielmodell analysieren und verallgemeinern. Wir leiten daraus Regeln ab, mit denen wir ähnliche Modelle wie das Beispielmodell erstellen können. Diese Regeln lassen sich auch wieder als Modell mit zusätzlichen Einschränkungen definieren. So ein Modell heißt Metamodell. Da es ein Metamodell für unser Projekt ist, nennen wir es „Projekt-Metamodell“.
Das Projekt-Metamodell ist also ein Modell, mit dem wir definieren, wie ein Modell aufgebaut sein darf. Das Projekt-Metamodell, das wir erstellen, ist ein Metamodell, in dem beschrieben wird, wie wir mit einer oder mehreren Modellierungssprachen unsere Probleme und Lösungen beschreiben. Der Unterschied zwischen dem Projekt-Metamodell und dem Referenzmodell besteht darin, dass im Referenzmodell ein konkretes Beispiel beschrieben wurde und im Projekt-Metamodell das Schema zum Erstellen eines weiteren Beispiels. Im Referenzmodell haben wir z.B. einen SysML Block mit Namen „Kaffeemaschine“, der einen Zustandsautomaten enthält, der alle möglichen Zustände der Kaffeemaschine aus einer logischen Sicht beschreibt. Im Projekt-Metamodell können wir dann ableiten, dass jeder SysML Block durch einen oder auch mehrere Zustandsautomaten beschrieben werden kann (optional) oder beschrieben werden muss.
Haben wir diese Überlegung für alle Teile des Referenzmodells angestellt und dafür ein Projekt-Metamodell entwickelt, können wir eigentlich schon mit dem nächsten Projekt loslegen. Wir wissen, wann wir welche Informationen mit welchen Modell-Elementen abbilden und aufgrund des beispielhaften Referenzmodells, auf welche Abstraktion mit wie vielen Details modelliert werden soll. Jetzt hängt der Erfolg nur noch davon ab, dass der Ansatz vom ganzen Team verstanden wird und sich alle beteiligten Personen immer an die im Projekt-Metamodell formulierten Regeln halten.
Der Belastungstest
Der Belastungstest ist einer der wichtigsten Schritte im Einführungsprozess eines Modellierungsansatzes. Das erstellte Referenzmodell wird dabei von zukünftig beteiligten Personen auf folgende Punkte überprüft:
- Fragen sind einfach zu beantworten: Alle zuvor definierten Fragestellungen sollten mit dem Modell von allen mit dem Modell arbeitenden Personen einfach beantwortet werden können.
- Es tauchen keine weiteren Fragen auf: Neben den zuvor definierten Fragen können die beteiligten Personen keine weiteren Fragen identifizieren, die mit dem Modell noch beantwortet werden sollten.
- Erstellung und Änderung ist einfach: Die Erstellung neuer Informationen und die Veränderung vorhandener Informationen verursacht keinen großen Aufwand.
Nach erfolgreicher Beendigung des Belastungstests steht uns ein Modellierungsansatz zur Verfügung, der von einem Teil der Mitarbeiter bereits akzeptiert und verstanden wurde und damit produktive Arbeit erlaubt. Durch den Belastungstest haben wir die Ecken und Kanten unseres aktuellen Modellierungsansatzes herausgefunden. Wir wissen nun, was gut funktioniert und wo wir noch nachbessern können.
Um den definierten Modellierungsansatz in die Gruppe, Abteilung, Firma etc. auszurollen, sollte nun ein Schulungskonzept entwickelt werden. Meist reicht es, wenn das Referenzmodell als Beispiel herangezogen wird und die Anpassungen und Automatismen bereits ausgerollt wurden. Viele Beispiele haben mir allerdings gezeigt, dass ein Referenzmodell alleine nicht ausreichend ist. Das Projekt-Metamodell muss vorhanden sein, um alle Regeln zu kennen. Das Referenzmodell dient nur als exemplarisches Beispiel. In der Schulung wird zielgerichtet der bereits erstellte und verifizierte Modellierungsansatz vermittelt, ohne sich mit all den Möglichkeiten und Eventualitäten herumzuschlagen, die eine Modellierungssprache, ein Werkzeug und Methoden mit sich bringen. Der Einstieg in die produktive Arbeit wird dadurch erheblich erleichtert, da die Mitarbeiter nur das lernen, was sie anschließend auch wirklich brauchen. Die Anpassungen stellen darüber hinaus sicher, dass sie nichts falsch machen können.
Kurz zusammengefasst
Zusammenfassend lässt sich sagen, dass der Wechsel vom textbasierten zum modellbasierten Ansatz mit einem gewissen (überschaubaren) Aufwand verbunden ist. Die wichtigste Forderung bei der Einführung von modellbasierten Ansätzen ist das Vorhandensein konkreter und realistischer Zielvorgaben. Nur so lässt sich rasch der Nutzen von Modellen zeigen und eine Verifikation des Ansatzes erstellen. Dabei sind konkrete Fragestellungen zu definieren, die mit dem Modell beantwortet werden sollen. Keine konkreten Zielvorgaben oder zu hoch gesteckte Ziele sind kontraproduktiv und führen in der Regel dazu, dass der Ansatz vom Team nicht mitgetragen wird und früher oder später „stirbt“.
Mit dem einfachen Bild (Diagramm) eines Modells entsteht bereits ein geringfügiger Vorteil zu textbasierten Ansätzen. Die Mächtigkeit modellbasierter Ansätze steckt allerdings primär in der formalen Struktur des Modells. Unterschiedliche Automatismen können auf diese formalen Daten aufsetzen und weitere Artefakte generieren.
Um die Erstellung und Manipulation der Modelle möglichst einfach zu gestalten, sollte die Belastbarkeit des Modellierungsansatzes überprüft werden. Mögliche Fehlerquellen lassen sich durch Assistenten vermeiden, die das Modell automatisch verifizieren und den Nutzer bei der Erstellung unterstützen und führen. Dadurch wird sichergestellt, dass alle Modellierungsregeln befolgt und das Projekt-Metamodell eingehalten wird. Nur so lassen sich alle Automatismen, die ein Modell so wertvoll machen, auch wirklich nützen. eve
Unterstützung zur Erstellung grafischer Modelle bietet die Software Enterprise Architect. Mehr Informationen:
