Die Standard-Falle

Standards sind wichtig für das Qualitätsmanagement im Software-Engineering und für den Bau inter­operabler Systeme. Weil sich aber Anwendungen, Technologie und Architekturen verändern, verändern sich auch die Standards. Darum werden die meisten Standards von heute irgendwann zu Legacies werden. Wichtig ist es deshalb, technisch nachhaltige IT-Systeme zu bauen, die einerseits die aktuell gültigen Standards implementieren, die andererseits aber von eben diesen Standards weitgehend unabhängig sind. Das bedeutet im einfachsten Fall, dass wir durch das Ändern einer Zeile in der Konfigurationsdatei das Kommunikationsprotokoll wechseln können, zum Beispiel von SOAP auf RMI. Und es bedeutet in komplexeren Fällen, dass wir ohne grossen Kodierungsaufwand alle derzeit implementierten Standards austauschen können gegen modernere Versionen für denselben Anwendungsbereich.

Voraussetzung dafür ist eine transparente Architektur, die sauber in Schichten und Ebenen trennt, die in den verschiedenen Ebenen aus Komponenten aufgebaut ist und die jeweils inhaltlich wohldefinierte Schnittstellen besitzt. Voraussetzung ist auch, dass die Transparenz-Struktur künftige Änderungen der Standards und Technologien antizipiert. Zwar gibt es auch dann nie eine Garantie, dass ein Re-Engineering einfach sein wird, aber bei technisch nachhaltig konzipierten Systemen ist der Aufwand wesentlich geringer als bei Systemen, die aus dem Glauben heraus entworfen wurden, dass Standards ewig gültig bleiben.

Grundsätzlich empfiehlt es sich, von Standards vorsichtigen Gebrauch zu machen. Wir erleben derzeit, dass auf Teufel komm raus Standards definiert werden nach dem Motto «ich weiss zwar nicht, was ich standardisieren will und wozu das gut sein soll, aber ich muss es möglichst schnell tun, schneller als die anderen». Die so produzierten Standards werden im besten Fall schnell wieder vergessen. Im Normalfall führen sie aber durch Inkonsistenz mit anderen Standards zu einer neuen Heterogenität und Nicht-Interoperabilität. Im schlimmsten Fall giessen sie gar unsinnig teure Architekturen mit hohem operationellen Risiko in Eisen, auf dass noch in Jahrzehnten beim Entwickeln neuer Software darauf Rücksicht genommen werden muss.

Problematisch ist, dass man davon ausgehen kann, dass sich aus der aktuellen Schwemme nicht unbedingt die nützlichsten durchsetzen werden. Standards können insbesondere auch dann schädlich sein, wenn zwar der Standardisierungsprozess vernünftig gestaltet wird und alle relevanten Stakeholderperspektiven und notwendigen Fachperspektiven miteinbezogen werden. Dann nämlich, wenn das Standardisierte gänzlich überflüssig ist oder wenn durch teure Investitionen in die Standardisierung des Falschen bessere Konzepte blockiert werden.
So oder so ist das Resultat der Standard-Leidenschaft vielerortens für die Anwender katastrophal. Zuerst erhöht sich nicht selten durch das Fitmachen für den neuen Standard die Komplexität alter Systeme. Danach müssen Extra-Prozesse definiert werden, um die Informationslücken und Widersprüche zwischen verschiedenen Standards zu überbrücken. Und zuletzt müssen mit dem Standard, der sich überlebt hat, auch grosse Teile der implementierten Applikationssoftware entsorgt werden.
So nützlich Standards auch sind, so teuer können sie uns zu stehen kommen, wenn wir sie nicht technisch nachhaltig einsetzen.