TOGAF in der Praxis

Keine Kommentare

Mittlerweile kenne ich TOGAF seit einigen Jahren, habe aber nie die Gelegenheit gefunden, es in seinem vollen Umfang in einem Kundenprojekt anzuwenden. In jeder konkreten Projektsituation erschien TOGAF mit all seinen Phasen und Ergebnisartefakten jedes Mal einfach zu umfangreich, um es zu nutzen. Mich beschlich immer die Sorge, meine Kunden zu verschrecken, wenn ich anfangen würde, mit ihnen über mehr als ein Dutzend Phasen und Unterphasen sowie jede Menge zu erstellender Ergebnisartefakte zu diskutieren. Daher habe ich in meinen Projekten üblicherweise „leichtgewichtigere“ Architekturmanagement-Frameworks eingesetzt, die nur wenige Phasen und Artefakte umfassten und gut auf die Anforderungen meiner Kunden passten.

Vor einigen Wochen hatte ich dann die Gelegenheit, die Open Group Konferenz in München zu besuchen, eine der größten Zusammenkünfte von TOGAF-Experten weltweit. Ich war sehr gespannt, mit diesen Experten über ihre Erfahrungen zu sprechen. Hatte ich in der Vergangenheit nur die falschen Projekte für einen Einsatz von TOGAF? Hatte ich irgendeinen wichtigen Punkt übersehen? Oder würden sie mir von den gleichen Erfahrungen berichten, die ich gemacht hatte?

Beim Besuch diverser Projekterfahrungsberichte und in der Diskussion mit anderen Leuten auf der Konferenz habe ich dann immer die gleichen Antworten erhalten: Niemand hat TOGAF in seiner „Reinform“ eingesetzt. Alle haben TOGAF auf Basis der jeweiligen Kundenanforderungen angepasst, was in der Regel eine Vereinfachung bedeutet hat: Phasen wurden zusammengefasst, weggelassen oder umbenannt. Ebenso wurden Ergebnisartefakte vereinfacht, ganz weggelassen oder umbenannt. In einem Fall ist das Framework auf vier Phasen eingedampft worden und niemand hat in dem Projekt den Begriff „TOGAF“ erwähnt, um möglichen Diskussionen über die Komplexität des Architektur-Frameworks mit dem Kunden aus dem Weg zu gehen.

Auf der anderen Seite waren sich alle einig, dass TOGAF ein wirklich gutes Framework ist, das sehr gut geeignet ist, um sich einen Überblick über die Erfordernisse von Architekturlebenszyklus-Management zu verschaffen und um mit einem beliebigen nichttrivialen Architekturunterfangen zu beginnen. Auf der anderen Seite muss das Framework im Kontext eines konkreten Projektes üblicherweise auf die Projekterfordernisse hin angepasst bzw. vereinfacht werden – falls notwendig, auch radikal.

Dieses Feedback fand ich sehr interessant, insbesondere da es in gewisser Weise meine frühere Vorgehensweise bekräftigt hat: Passe nicht den Kunden auf die Anforderungen des Frameworks an, sondern wähle und passe das Framework auf die Erfordernisse des Kunden an. Und ein Framework von der Komplexität eines TOGAF ist für die meisten Kunden und Projekte in der Regel gut und gern eine Größenordnung zu umfangreich. Deshalb muss man das Framework in den allermeisten Fällen vereinfachen, damit es den Erfordernissen des Kunden genügt. Natürlich gibt es auch Projekte, die TOGAF in seiner ganzen uneingeschränkten Schönheit erfordern, aber aufgrund der Größenordnung, die diese Projekte dann haben, sind diese naturgemäß eher dünn gesät.

Nebenbei bemerkt ist das eine Erfahrung, die ich mit den meisten nichttrivialen Methoden und Frameworks – auch in anderen Bereichen – gemacht habe: Die meisten geben einem einen guten Überblick, welche Aspekte man bedenken sollte, wenn man sich mit dem entsprechenden, von der Methode bzw. dem Framework behandelten Thema auseinandersetzt, aber man verwendet sie relativ selten in ihrer ursprünglichen Form. Meistens muss man sie anpassen, d.h. vereinfachen und modifizieren, damit sie für den jeweiligen Kunden und Projekt funktionieren.

Denn: Das Ziel ist das Erzeugen von Business Value und nicht das Etablieren von Methoden und Frameworks –  diese sind nur Mittel zum Zweck.

Uwe Friedrichsen

Uwe Friedrichsen ist ein langjähriger Reisender in der IT-Welt. Als Fellow der codecentric AG ist er stets auf der Suche nach innovativen Ideen und Konzepten. Seine aktuellen Schwerpunktthemen sind Skalierbarkeit, Resilience und die IT von (über)morgen. Er teilt und diskutiert seine Ideen regelmäßig auf Konferenzen, als Autor von Artikeln, Blog Posts, Tweets und natürlich gerne auch im direkten Gespräch.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.