Der Doppelsinn der Transparenz

Transparenz bedeutet in der Informatik das Gegenteil von dem, was man im Alltag darunter versteht, nämlich «Information Hiding» – das geschickte Verstecken von überflüssiger Information. Das Beispiel Internet-Surfen zeigt, dass
Informatikverständnis und Alltagsverständnis von Transparenz zwar entgegengesetzt, aber doch zwei Seiten der selben Medaille sind: Informationstransparenz im Alltagssinn verlangt einen möglichst uneingeschränkten Informationszugriff, was im WWW voraussetzt, dass die technischen Details des Zugriffs wie Protokolle und Routen vor dem Benutzer verborgen werden, weil ansonsten nur eine kleine Minderheit von Freaks das WWW nutzen könnte.

Für grosse Anwendungssysteme ist ein wohlüberlegtes Transparenzmanagement der zwingend erforderliche Schlüssel zum erfolgreichen Umgang mit der hohen Komplexität. Praxisnäher gesagt: Viele Informatikprojekte scheitern am ungenügenden Transparenzmanagement, oder sie leiden jahrelang daran. Wichtige Strukturinformationen werden verborgen und gehen vergessen – in automatisch generierten Dokumentationen, in pseudoelegantem Code und in den Köpfen der Entwickler – mit Detailinformationen wird dafür gewuchert. Manager werden zum Beispiel von Entwicklern in Detaildiskussionen verstrickt, bis sie vor lauter Bäumen den Wald nicht mehr sehen oder bis sie sich auf so hohe Abstraktionsebenen flüchten, dass sie von dem, was wirklich implementiert wird, nichts mehr mitbekommen. In beiden Fällen geht die Projektkontrolle verloren, weil man Projekte nur von einer mittleren Abstraktionsebene führen kann, die zugleich nahe genug bei der konkreten Implementierung und bei der Geschäftssicht der Anwender ist. Auch auf technischer Ebene ergeben sich oft Probleme, weil ein Teil des
Systems zu wenig oder zu viel von den anderen weiss oder wissen müsste, so dass etwa gewachsene Strukturen zu gefährlich komplexen Abhängigkeiten führen, oder umgekehrt ein völlig transparenter Zugriff auf eine fremde Komponente Leistungseinbrüche verursacht.

Gutes Transparenzmanagement hat zwei Aufgaben: erstens allen am Bau oder an der Nutzung des Systems Beteiligten eine passende, «richtig transparente» Sicht auf das System zu ermöglichen, mit den und nur mit den Informationen, die sie jeweils benötigen. Zweitens muss es das Zusammenspiel der Sichten kontrollieren, so dass dieses keine Widersprüche aufweist und alle relevanten Aspekte abdeckt. Die bisher existierenden Instrumente – zum Beispiel das SOA/POA-Architekturkonzept, das RM-ODP-Vorgehenskonzept, Patterns und Anti-Patterns oder auch Hardcore-Zustandsmaschinen – sind nützlich, aber nicht ausreichend, und individuell in Firmen entwickelte Frameworks finden nicht immer ausreichend Akzeptanz. Doch je komplexer die Systeme werden, je dringender notwendig eine echte Orientierung der IT am Business wird, je wichtiger das Arbeiten in multidisziplinären Entwicklerteams wird, in denen beispielsweise auch IT-ausgebildete Juristen und Ökonomen aktiv mitarbeiten, desto grösser und unüberwindlicher werden die Herausforderungen an das Transparenzmanagement, und desto schwerer wiegt das Defizit an validiertem Engineering-Wissen. Es besteht darum Bedarf nach Grundlagenforschung. In der Praxis sind Glück, Verstand und intellektuelle Disziplin auf Seiten der Projektmanager gefragt. Zuerst aber müssten wir uns alle der kritischen Bedeutung des technischen Transparenzmanagements bewusst werden, denn mit Alltagskonzepten alleine bekommt man kein komplexes Anwendungssystem in den Griff.