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.

Seit Mitte des Jahres ist codecentric Mitglied im Java Community Process, um die Expertise der Mitarbeiter in den Entstehungsprozess der Java-Erweiterungen einfliessen lassen zu können. Seit heute hat codecentric zudem den Spec Lead für zwei Java Specification Requests übernommen:

• JSR 89: OSS Service Activation API
• JSR 264: Order Management API

Neben der Wartung der JSRs 89 und 264 setzt codecentric seine Leitrolle auf dem Gebiet des Order Managements in der Telekommunikation weiter fort: Die Spezifikation wird momentan ausserhalb des JCPs im Rahmen des Telemanagement Forum Interface Programs (TIP) fortgesetzt. Das TIP Ordering & Activation Team baut unter anderem auf den Ergebnissen von JSR 89 & 264 auf, und wird eine der ersten TIP Spezifikationen zum Ergebnis haben, das auf dem neuen, harmonisiertem Interface Framework beruht, das vom O&A Team maßgeblich mitgestaltet werden wird.

Das war die Botschaft des Abends. Am 6. Dezember begingen die codecentric Mitarbeiter zusammen mit ihren Partnern die codecentric Weihnachtsfeier. Das Fest verlief wie üblich in einer familiären Atmosphäre, bot vorzügliches Essen und ein sehr nettes Ambiente. Das Highlight des Abends waren die Newcomer- Reden, die bis früh in die Morgenstunden für viel Spaß gesorgt haben.

[Show as slideshow]

Sechs glückliche Mitarbeiter der codecentric GmbH besuchen zur Zeit die Devoxx (ehemals JavaPolis) in Antwerpen, Belgien. Bei Vorträgen wie Spring 3 (RESTful Spring MVC, Expression language), Java7 (dynamische Sprachen, concurrency/parallelism, mehr neue I/O Methoden (NIO), kleinere Sprachänderungen (wie der multiple-catch Block)), Modularisierung (OSGi, Project Jigsaw (wahrscheinlich Bestandteil von Java7), Spring Source dm Server) ist sicher, dass für jeden etwas dabei ist und viel Wissen transferiert wird.

Das Highlight des ersten Konferenztages war jedoch der Sieg des codecentric Teams beim JBoss Kicker Tunier. Als Gewinn gab es T-Shirts und ein Foto mit den JBoss Mitarbeiterinnen. Die Gesichter sagen alles:

Wenn wir eine Definition für einen Begriff suchen oder Erklärungen zu einem Thema, wo schauen wir dann nach? Richtig, in Wikipedia! Und wir wissen, dass die gesammelten Informationen nach dem Prinzip der offenen Community zusammengetragen worden sind, dass also jeder, der Ahnung von einem Thema hat, alle Experten dieser Welt ihr Wissen dort verewigen können und so dem nicht ganz so wissenden Rest der Welt zur Verfügung stellen können.

Wir verlassen uns mittlerweile so sehr auf die Informationen in Wikipedia, dass wir uns häufig gar nicht mehr die Mühe machen, alternative Quellen zu prüfen. Und wenn irgendwo eine Definition aus Wikipedia zitiert wird, nehmen wir sie als richtig hin.

Dazu das folgende Erlebnis, das ich dieses Jahr auf der Enterprise Architecture Conference in London hatte:

Auf besagter Konferenz hat John Zachman in einer Keynote die neue Version seines Frameworks vorgestellt. Dazu hat er an jeden Keynote-Teilnehmer ein Blatt ausgeteilt, das eine schön aufbereitete Darstellung seines Frameworks zeigte. Bevor er aber begann, die Neuerungen seines Frameworks zu erklären, hat er uns Teilnehmer auf zwei kurze Artikel aufmerksam gemacht, die auf der Rückseite des Blattes abgedruckt waren.

Er erzählte dazu sinngemäß übersetzt: “Diese beiden Artikel erläutern in Kürze mein Framework. Der Grund, warum ich sie hier habe abdrucken lassen, ist Wikipedia. Ich hatte vor einiger Zeit aus Neugierde nachgelesen, was in Wikipedia über mein Framework geschrieben steht. Dabei ist mir aufgefallen, dass der Artikel in Wikipedia einige falsche Aussagen enthielt. Also habe ich die fehlerhaften Aussagen in dem Artikel korrigiert. Dank des offenen Konzepts von Wikipedia ist das ja kein Problem. Kurze Zeit später erhielt ich die Rückmeldung von Wikipedia, dass meine Änderungen gelöscht worden seien, da sie nicht korrekt wären. Ich schrieb sinngemäß zurück: ‚Hallo, ich bin John Zachman. Wenn ich nicht wissen soll, was im Kontext meines Frameworks richtig ist, wer dann?‘ Aber es hat nichts geholfen. Wikipedia hat darauf bestanden, dass meine Aussagen zu meinem Framework falsch seien. Aus diesem Grund sah ich mich gezwungen, diese beiden Artikel zu schreiben, in denen dargestellt ist, wie ich mir mein Framework vorstelle, wenn ich das schon nicht in Wikipedia machen kann.”

Natürlich hatte John Zachman mit dieser Anekdote die Lacher auf seiner Seite und da er die gute Ausgangsstimmung in seiner Keynote aufrecht halten konnte, war es auch für alle Anwesenden eine tolle Keynote, bei der wir übrigens auch eine Menge über die neue Version seines Frameworks und die dahinterliegenden Ideen und Konzepte gelernt haben.

Was sagt einem diese Geschichte aber in Bezug auf Wikipedia? Ich weiß nicht, was da im Detail passiert ist, wer genau die Änderungen von John Zachman in Wikipedia rückgängig gemacht hat und habe auch nicht weiter nachgefragt. Was einem die Anekdote von John Zachman aber gut vor Augen führt ist, dass auch Wikipedia nicht unfehlbar ist. Auch hinter Wikipedia stehen Menschen, und Menschen haben Schwächen und machen Fehler – Fehler, die sich letztlich auch in den Inhalten von Wikipedia wiederfinden.

Für mich war es ganz hilfreich, mit dieser Geschichte mal wieder daran erinnert zu werden, dass auch Wikipedia nicht unfehlbar ist. Natürlich wissen wir das eigentlich auch alle, nur vergessen wir es zwischendurch immer mal wieder.

Wikipedia ist eine hervorragende Informationsquelle und es ist aus meiner Sicht nach wie vor beeindruckend, wie über das offene Konzept von Wikipedia über so kurze Zeit so viel qualitativ hochwertiges Wissen zusammengetragen werden konnten. Dennoch sollten wir Wikipedia nicht mit der “Wahrheit an sich” verwechseln, sondern es wie mit jeder anderen guten Informationsquelle auch halten: Wir können Wikipedia als erste Quelle für eine Informationsrecherche nutzen; dann sollten wir aber wie bei jeder guten Recherche mehrere weitere Quellen zur Gegenprüfung heranziehen, um das Fehlerrisiko zu minimieren und die Belastbarkeit unserer Informationen sicherzustellen.

Denn: Wikipedia hat eben nur fast immer recht.

Die eismann GmbH hat ein innovatives Konzept entwickelt, um neue Kunden zu gewinnen und fand in der codecentric GmbH den kompetenten Partner zur Umsetzung.

Auf Basis dieses Konzeptes hat codecentric für eismann die Integrierte Neukunden Anwendung (INA) entwickelt, mit der eismann fast zwei Jahre früher als gedacht, ihre ehrgeizigen Ziele erreicht und sogar übertroffen hat.

Lesen sie mehr: eismann Success Story