«Ihm sein Tool» oder wie der Sparx Enterprise Architect salonfähig wurde

Für die Dokumentation von IT-Projekten ist der Enterprise Architect von Sparx in unserem Unternehmen kaum mehr wegzudenken. Ich beschreibe in diesem Artikel einige Meilensteine auf dem Weg, den ein Tool gegangen ist, das in vielen Unternehmen auf der Liste beschaffter Anwendungen steht und über die Zeit eine zentrale Rolle in der Abwicklung von IT-Projekten eingenommen hat.

Heute – Einsatz über die gesamte Projektdauer

Bereits in der Angebotserstellung werden grundlegende Architekturansichten (Kontext-, Laufzeit-, Baustein und Verteilungssicht) im Enterprise Architect (EA) erstellt.

Während der Durchführung werden Modelle erweitert und verfeinert, sodass sie dem Stand der Umsetzung entsprechen. Natürlich lässt sich nicht jede Information im EA festhalten und wir generieren auch keine komplexen Dokumentationen aus den Modellen. Vielmehr erstellen wir verschiedene Dokumente «händisch» und halten «kurzlebige» Beschreibungen im Wiki fest.

Was wir aber machen, ist, dass wir diese verschiedenen Informationsquellen mit den Modellen im Enterprise Architect verbinden (über Hyperlinks) und sie so in einen Zusammenhang bringen. Über das Modell lassen sich die wesentlichen Informationen zum Projekt/Produkt auffinden.

Wir verwenden Projekt-Templates, die den grundlegenden Aufbau beschreiben und verschiedene Beispiel-Diagramme beinhalten, die in der Regel einfach adaptiert werden können.

Es gibt eine Projekteinstiegsseite, die über die Projektziele informiert und Links auf wichtige Diagramme in externen Dokumenten beinhaltet.

Weiter achten wir darauf, Diagramme untereinander zu verlinken, sodass die Navigation nicht über den Projekt-Browser erfolgen muss. Dies vereinfacht die «Bedienung» sehr. Zusätzlich legen wir vordefinierte Suchen als Hyperlinks an, um weniger geübten Benutzern den Umgang damit zu vereinfachen.

Ich denke, mit Fug und Recht behaupten zu können, dass diese EA-Modelle einen echten Mehrwert darstellen. Jedoch muss ich an dieser Stelle auch festhalten, dass es einige Zeit in Anspruch genommen hat, den aktuellen Stand zu erreichen und Akzeptanz für das Tool und die Methodik bei den Mitarbeitern zu schaffen.

Ein neues Tool

Ich setze den EA mittlerweile seit mehr als 10 Jahren ein. Kennengelernt habe ich das Tool durch einen Mitarbeiter, der wiederum im Rahmen einer Weiterbildung damit in Kontakt gekommen ist. Bei meinem damaligen Arbeitgeber, einem kleineren Softwarehersteller, hatte ich die Verantwortung für ein mittleres Team von Softwareentwicklern. Immer wieder sah ich mich in Diskussionen über Vorgehensmodelle in der Projektabwicklung verstrickt. Das stete Argumentieren über Sinn und Unsinn von Spezifikationen, die Zweckmässigkeit von Design- und Analysebestrebungen oder über die Erstellung von Produktdokumentationen empfand ich mit der Zeit als müssig.

Als «Anhänger» RUP-artiger Vorgehensmodelle konnte ich das Bestreben, möglichst schnell am Code zu sein, nicht so ganz nachvollziehen und fragte mich öfters, warum meine Mitarbeiter nicht willens waren, mit Modellen zu arbeiten. Der relativ geringe Preis überzeugte mich dann, den EA zu beschaffen, in der Hoffnung, ein «Zückerchen» für das Verbessern der Dokumentation zu geben. Die Anwendung überliess ich weitgehend den Mitarbeitern. Selber zeichnete ich primär Domänen- und Datenmodelle und verwendete diese dann in den Dokumenten.

«Ihm sein Tool»

Bei meinem aktuellen Arbeitgeber nutzte ich den EA zu Beginn für Reverse-Engineering oder zur Transformation von Datenmodellen. Domänen- und UseCase-Modelle kamen hinzu. Später begann ich, auch Systemkontext, Laufzeit und Verteildiagramme zu erstellen und diese in Dokumenten zu verwenden. Vorgesetzte und Mitarbeiter wurden auf Darstellungen aufmerksam, baten mich, ihnen den Enterprise Architect zu zeigen und probierten teilweise, selber damit zu arbeiten. In den meisten Fällen aber führten die Bestrebungen nicht weit, manchmal sah ich mich mit der Frage konfrontiert: «Du hast doch da so ein Tool, könntest du nicht …?» Öfter kamen aber auch frustrierte Bemerkungen, dass das Werkzeug nur schwer zu gebrauchen sei, dass es vor Funktionalität nur so überquelle und man überhaupt nicht wisse, wie und wo einsteigen. Und so wurde der Enterprise Architect bald zu «Ihm sein Tool», ein Opportunisten-Tool, mit dem ich fast als einziger arbeitete.

Die Wende

Erst die Aufgabe, ein grösseres Projekt gesamthaft zu dokumentieren, brachte die nötige Veränderung. Vom Umfang her kaum mehr in Word-Dokumenten zu beschreiben, wurde mit dem Kunden vereinbart, die Dokumentation auf Basis von Enterprise Architect zu erstellen. D.h. nicht einfach ein paar Diagramme zu zeichnen, sondern diese eben in Kontext zu bringen, weiterführende Informationen in das Modell einzubringen und alles auf ein breiteres Zielpublikum abzustimmen. Das Ergebnis motivierte dazu, solche Dokumentationen generell für komplexe und umfangreiche Projekte zu erstellen.

Ausbildung first

Damit einhergehend muss das Werkzeug aber von allen Mitarbeitern eingesetzt werden können und es braucht ein Committment zum Tool. Durch den blossen «Zwang», damit zu arbeiten, wird keine gute Dokumentation entstehen. Gute Beispielprojekte helfen zwar, eine Vorstellung vom Ergebnis zu haben, der Einstieg muss dem Mitarbeiter aber leichtgemacht werden. D.h. Mitarbeiter sollten sich nicht im Selbststudium durchkämpfen müssen oder auf Arbeitskollegen angewiesen sein, die einem den einen oder anderen Tipp geben. Mein aktueller Arbeitgeber hat in der Folge Mitarbeiter, die mit den Enterprise Architect arbeiten sollten, gezielt ausgebildet. Gezielt heisst, das Werkzeug im Rahmen einer Schulungsveranstaltung kennenlernen, Zeit haben, die Features auszuprobieren und Feinheiten vermittelt bekommen. Es bedeutet weiter, zu wissen, welche Diagrammtypen für bestimmte Themen zu erstellen sind, sich Gedanken zum Zielpublikum und dessen Wissen und Anforderungen zu machen. Es bedeutet auch, in der Organisation einen Prozess durchzumachen und schrittweise eine neue Dokumentationsform anzunehmen und diese abzugrenzen.

Fazit

Dokumentieren mit einem Modellierungswerkzeug lohnt sich. Mit «dokumentieren» meine ich mehr, als nur Zeichnungen mit dem Tool zu erstellen. Es hat sich bewährt, im Projektteam eine Person zu haben, die sich ganz besonders der Dokumentation annimmt und «Spass» an einem gut dokumentierten System hat. Eine Person, die ab und an Modelle überprüft, Links auf externe Dokumente und Diagramme testet und beschreibende Inhalte mit anderen Quellen vergleicht und aktualisiert. Eine gut gepflegte Dokumentation schützt vor Know-how-Verlust, schafft Vertrauen und erleichtert die Arbeit. Diese Punkte haben wir mit dem Enterprise Architect erreicht und das Werkzeug wird heute gerne und erfolgreich eingesetzt.