Im Informatikstudium bekommt man Abstraktion beigebracht. Man lernt, große Dinge in seine Bestandteile aufzulösen und dann einzeln anzugehen. Das beginnt mit Trivialem wie Quicksort und endet bei der Model Driven Architecture. Und das ist auch gut so. Die Abstraktion ist ganz klar eines der wichtigsten Werkzeuge der modernen Informatik und der modernen Systementwicklung. Was einem allerdings nicht beigebracht wird, ist Maß damit zu halten.

Im Seminarraum meiner damaligen Arbeitsgruppe hing ein handgeschriebenes und ausgeblichenes Schild. Auf dem Stand “Fünf Stunden Perl programmieren ersetzt eine Stunde Nachdenken”. Was zunächst wie die scherzhafte Kritik an einer Programmiersprache aussieht ist bei genauerem Hinsehen viel mehr: es ist die Kritik an einer Verselbstständigung der Abstraktion. Und genau da liegt eine große Schwäche bei vielen Leuten, die eine systematische Ausbildung der Informatik hinter sich haben: die Technologie verkommt zum Selbstzweck. Wer hat nicht schon einmal Quellcode gesehen, der sich in endlosen Klassenhierarchien vererbt oder Datenmodelle, die jedes ach so kleine Datenpäckchen noch externalisieren und ein an sich einfache fachliche Probleme zu Datenmodellen mit dutzenden Entitäten aufblähen?

Fragt man dann nach, warum die Modelle denn so sind wie sie sind, bekommt man meistens “Erweiterbarkeit” an den Kopf geworfen. Oder “Änderbarkeit”. Oder “Vereinfachung”. Spätestens hier wird dann aber auch schon durch das reine Nachfragen selbst dem abstraktesten Architekten klar, dass etwas schief läuft. Diese “Verkomplizierung im Namen der Vereinfachung” oder auch “spekulative Verallgemeinerung” ist eine sehr verbreitete Krankheit in vielen vielen Softwaresystemen. Sie führt zu sehr schwer zu wartenden Quellcodes und deutlichen Mehrkosten bei jeder Art von Veränderung und Erweiterung. Damit erreicht sie dann genau das Gegenteil von dem, was eigentlich beabsichtigt war – und das ist das Tragische daran.

Allerdings befällt dieses Problem nicht nur Software an sich, sondern auch IT-Standards oder auch Entwicklungsprozesse. Dieses “Overengineering” kann man beispielsweise sehr gut bei den WS-*-Standards wie SOAP, WSDL oder auch BPEL beobachten. WSDL ist da ein sehr gutes Beispiel: prinzipiell lässt sich damit jede Art von Schnittstelle auf Basis jeder Art von Technologie beschreiben. Aber wird das auch eingesetzt? Mir ist es nicht gelungen auch nur einen einzigen Fall zu finden, in dem WSDL nicht zur Beschreibung von SOAP-Web-Services auf Basis von HTTP oder SMTP zum Einsatz kam. Die beim Design von WSDL berücksichtigte Unabhängigkeit von jeder Art von Dritttechnologie wird überhaupt nicht genutzt! Allerdings hat sie WSDL sehr viel komplexer gemacht und damit schwerer einzusetzen und damit im Endeffekt teuerer. Dass man bei einer so innovativen Technologie wie Web-Services damit quasi das gesamte Konzept auf die Kippe stellt nur weil man die “ultimativ allgemeine” Lösung finden möchte ist ein Nebeneffekt. Und dass dieser tatsächlich zuschlagen und einen gesamten Standard ins Abseits katapultieren kann, ist am Besipiel von UDDI sehr schön zu beobachten.

Aus meiner Sicht ist ein guter Entwickler und ein guter Architekt nicht nur jemand, der Abstrahieren kann, sondern auch jemand, der die Grenzen der Abstraktion erkennt. Er muss in der Lage sein, fachliche Bedürfnisse gegenüber technischen Möglichkeiten abzuwägen und die “richtige” Lösung zu finden – nicht die technisch perfekteste, sondern die technisch und fachlich eleganteste. Einfach die Lösung, die KISS ist.

Dabei verwundert mich ein wenig, dass ein Problem dieses Kalibers scheinbar in keinem vorherigen QS-Verfahren aufgefallen ist was mich wiederum stark an an den QS-Prozessen der Bankenwirtschaft zweifeln lässt. Bei derlei Mission-Critical-Systemen erwarte ich eine lückenlose QS, die wirksam verhindert, dass in Systemen dieses Kalibers solche schweren Fehler auftreten. Zumindest nicht im Produktivbetrieb.

Noch seltsamer ist allerdings, dass “das Problem” am 1.1. aufgetreten und bereits am 4.1. als “gelöst” bezeichnet wurde. Das bedeutet für mich, dass die “Lösung”, die laut Spiegel in einem “Update der Software der Automaten und Händlerterminals” bestand, wohl kaum durch eine vernünftige QS gelaufen sein kann. Denn abseits jeder Automatisierung und Professionalisierung der QS-Prozesse: eine korrekte QS benötigt Zeit und ich mutmaße, dass es sich hier um kein kleines System handelt, das in wenigen Stunden komplett auf Seiteneffekte abgeklopft werden kann – zumal sich ja bereits gezeigt hat, dass die QS-Prozesse sowieso sichtbare Probleme haben.

Im Schluss bedeutet dass, dass vermutlich eine nicht korrekt getestete Software durch eine neuere Version nicht korrekt getesteter Software ausgetauscht wurde und wir uns alle auf das nächste Problem freuen können.