Architektur- und Projektmanagement - beide nix gut!

Lüge, Gemeinheit und Niedertracht! «Wir haben doch seit einem halben Jahr die Schnittstelle nicht verändert!» verteidigte sich empört ein Projektpartner, weil ich die wöchentlichen Veränderungen der Schnittstelle «ihrer» Business-Tier zu «unserer» Web-Tier kritisch erwähnt hatte. Tatsächlich veränderten sie an der Schnittstelle regelmässig alles ausser der Java-Klasse. Sie verlegten sogar die Verknüpfung zweier Geschäftsprozesse von der Web-Tier in den allerhintersten Winkel der Business-Tier, mit erheblichen rechtlichen Konsequenzen. Trotzdem, und obwohl es sich um promovierte Informatiker handelte, empfanden sie mein Eintreten für ingenieursmässige Software-Entwicklung und juristische Korrektheit als gemeine Bosheit. Für sie war Architekturdesign die Aufgabe derer, die den Code schreiben, und als Schnittstellen zwischen Entwicklerteams hielten sie Java-Klassen für ausreichend. Das ist typisch für unsere Ausbildungsdefizite in der IT.

Ziel der Informatik-Ausbildung in Lehrgängen, an Fachhochschulen und an Universitäten sollte es sein, die Grundprinzipen einer ingenieursmässigen Software-Entwicklung zu vermitteln, ein pragmatisch methodisches Arbeiten zu lehren, inklusive praxistauglicher formaler Methoden, und den Blick fürs grosse Ganze zu weiten. Insbesondere sollte der Grundstein für eine Kultur des V&V (Verifikation und Validierung) gelegt werden. V&V bedeutet: Was immer man in einem Projekt tut, zuerst sollten die Ziele definiert und am Schluss deren Erfüllung überprüft werden.
Für die Praxis von grosser Bedeutung wäre dabei eine gute Ausbildung im Entwickeln von Architekturen, im Architekturmanagement und im Projektmanagement. Architekturdesign ist der Ort der schweizerischen Kompromisse in der IT. Die unterschiedlichen Fachsichten und Stakeholderinteressen der Geschäfts- und IT-Abteilungen müssen zusammengeführt und die detaillierte Designarbeit muss vorstrukturiert werden. Fehler, die hier gemacht werden, sind teuer und langlebig. Noch teurer sind nicht existierende Architekturen oder detaillierte Architekturen ohne eigentlichen Kern. Schwierig ist die Architekturentwicklung vor allem, weil hier auf abstrakter Ebene etwas entworfen wird, das nicht esoterischer Selbstzweck ist, sondern konkret umgesetzt zu richtigen Lösungen führen muss. Noch schwieriger ist das Managen von Architekturteams, weil es inhaltliche Führung voraussetzt.

Ähnliches gilt für das Projektmanagement. Punkt 1 jedes IT-Projekts sollte die klare Definition einer Top-Down-Sicht auf Ziele, Seiteneffekten und Lebenszyklus-Kosten sein, Punkt 2 der Entwurf eines Risikomanagement-Plans, Punkt 3 die Auswahl eines dem Risiko angepassten Prozessmodels und Punkt 4 der Entwurf eines Qualitätsmanagement-Plans. Erst danach kommt die Ressourcenplanung. Zur Schaffung einer projektinternen Identifikation sollte zudem alles verständlich dokumentiert und kommuniziert werden. Neben dem Überwinden des inneren Schweinehunds liegt auch hier die Hauptschwierigkeit im Umgang mit abstrakten Konstrukten wie dem Risiko-Management, denn das Denken in Risiken ist uns fremd.
Richtig oder falsch – dazwischen liegen in der IT nicht selten Zehnerpotenzen an Zeit und Kosten. Manche Audits sparen in wenigen Stunden Millionen, trotzdem sparen viele Auftraggeber lieber das Audit. Das gesamtwirtschaftliche Potential durch professionelleres Engineering wäre gewaltig, aber dazu müsste man in die Ausbildung investieren.