Konzeptionell ist ein Computersystem in Schichten aufgebaut. Extrem stark vereinfacht, sind auf der untersten Ebene die Naturwissenschaften und natürlich an vorderster Front die Elektrotechnik zu Hause, die das technische Meisterwerk vollbringt, elektrische Ströme zu bändigen und in logische Flüsse zu lenken. Auf diesem elektrotechnischen Fundament setzt ein kleines, hardwarenahes System auf, das die verschiedenen elektrotechnischen Schaltungen miteinander in Verbindung bringt, überwacht und steuert. Darauf baut dann wieder die nächste Schicht auf, mit deren Hilfe versucht wird, die verschiedensten Variationen zu verallgemeinern und eine einheitliche Zugänglichkeit zu diesen zu schaffen. Es wäre wohl keinesfalls wirtschaftlich für jedes Computersystem eine eigene Softwarelandschaft entwickeln zu müssen.
Über dieser verallgemeinernden Schicht ist dann das Revier des Betriebssystems. Dieses ist die zentrale Trennschicht zwischen der physischen Natur des Computers und den Anwendungsprogrammen, bzw. den Benutzer*innen. Heutige Betriebssysteme sind in ihrem Inneren ebenfalls sehr stark in Schichten gebaut und abstrahieren mit jeder Schicht die darunter liegenden technischen Details. Größere Anwendungsprogramme folgen ebenfalls meistens einem solchen Schichtmodell und teilen ihre eigene Funktionalität in Abstraktionsebenen.
Diese Konstruktionsweise ist sinnvoll, bzw. Abstraktionsreduktionen heute absolut notwendig. Mit jeder Schicht sollten die speziellen Eigenheiten der darunter liegenden Schichten verdeckt werden, sodass Komplexität gekapselt und eingegrenzt wird. Auf dem Boden einer hohen Schicht sollten technische Details aus tief darunter liegenden Schichten verborgen bleiben. Auf diese Art und Weise können die hochkomplexen Sachverhalte in den heute anzutreffenden Größenordnungen Schicht für Schicht bewältigt werden. Wird auf einer unteren Ebene ein Sachverhalt geändert, kann die darüber liegende Schicht diesen Sachverhalt abfangen, sodass eine kleine Änderung auf einer unteren Ebene nicht lawinenartig, gravierende Änderungsmaßnahmen nach sich ziehen müssen. Ebenso können so auf den oberen Ebenen Anpassungen durchgeführt werden, ohne mit der Komplexität der Gesamtheit des Systems belastet zu sein.
So elegant und notwendig diese Art der Konstruktion auch ist, in der Realität sind Isolation und Abstraktion der Schichten unvollständig und das Schichtenkonzept mit Schwächen verbunden. Dies tritt insbesondere im Falle von Abweichungen vom einwandfreien Betrieb ans Tageslicht. Hier tauchen häufig zwei Phänomene auf, die zwei problematische Seiten dieses Schichtaufbaues aufzeigen. Im ersten Fall wird ein Fehler in einer tiefen Schicht durch höhere Schichten hindurch bis an die Oberfläche propagiert, sodass Benutzer*innen mit Fehlermeldungen konfrontiert werden, die sich außerhalb ihrer Sphäre und Kenntnis befinden. Die Komplexität der Technik wird plötzlich durch alle Schichten durchgereicht. Solche Fehlermeldung sind außerhalb des Kenntniskontextes eines Anwendungsprogramms und damit völlig deplatziert. Sie kommen de facto aus einer anderen Welt. Ein Filtern an den Schichtgrenzen ist jedoch ebenfalls untauglich. Ein in tieferen Schichten aufkommendes Problem wird durch höhere Schichten gefiltert und die technischen Ursachen verborgen. Bei den Benutzer*innen kommt ausschließlich die ebenfalls höchst aussagelose Information der Fehlfunktion an, ohne irgendeine verwertbare Information zur Begründung oder möglichen Maßnahmen beizufügen. Eine strikte Trennung der Schichten kann also genauso zu Problemen führen, wie ein Durchreichen der technischen Details.
Analoges zu Fehlermeldungen gilt im Bereich der Konfiguration der Systeme. Auch hier sind die Schichten entweder stark durchlässig, sodass auf einer sehr hohen, abstrakten Stufe Detailkenntnisse über hochspezifische Aspekte der tieferen Ebenen notwendig sind und umgekehrt auf hoher Ebene eine Unmöglichkeit von notwendigen Anpassungen in tieferen Ebenen besteht.
Die Lösung dieses Sachverhaltes liegt in der strikten Übersetzung aller Fehlersituationen und Konfigurationsoptionen an den jeweiligen Schichtgrenzen. Beim Übergang von einer Schicht zur nächsten muss die Sprache, das Vokabular und die abstrahierte Denkweise der jeweiligen Schicht angepasst werden. Und dies in beide Richtungen. Fehler, die in der Tiefe auftreten, müssen so zu klaren Aussagen und Handlungsanweisungen auf hoher Ebene führen. Aktionen und Konfigurationen, die auf hoher Ebene in der Gedankenwelt der hohen Abstraktion getroffen werden, müssen Schritt für Schritt bis ins technische Detail in den unteren Stufen projiziert werden. Die notwendige Expertise vorausgesetzt, muss dieses Hinauf- oder Hinunterpropagieren nachvollziehbar und mitverfolgbar sein. Ebenso wenig wie im Alltag Benutzer*innen mit hochkomplexen Sachverhalten konfrontiert werden sollen, dürfen Expert*innen nicht mit vereinfachten Darstellungen eingeschränkt werden.
Die Komplexität der Technik darf nicht beliebig bis zu den Benutzer*innen durchgereicht werden. Die Konfrontation mit technischen Details ist wenig zielführend. Sachverhalte müssen von Stufe zu Stufe übersetzt werden und mit Handlungsanweisungen versehen werden. Expert*innen müssen die Stufen im Bezug auf einen Sachverhalt entlanggehen können, um in die Tiefe des Systems vordringen zu können.
Sowohl das Fehlermanagement in Computersystemen, als auch deren Konfigurationsbereich bedürfen einer Überarbeitung und neuer Konzepte, da diese in der heutigen Konstruktionsform des Schichtenmodells nicht adäquat gelöst sind.
0 Kommentare