Panta rhei. Alles ist im Fluss, alles verändert sich. Unaufhaltsam, immer schneller, immer unüberschaubarer. Nicht erst heute. Spätestens seit Erfindung des Rades steht die Menschheit vor der Herausforderung, sich in der Veränderung zurechtzufinden.

Es wachsen die Möglichkeiten, aber auch die Sorgen. Das meint übrigens die Bibel, wenn Adam und Eva nach dem Essen vom verbotenen Baum der Erkenntnis aus dem Paradies (der animalischen Sorglosigkeit) vertrieben werden.

„Früher war die Zukunft auch besser!“, hat der Münchner Erzkomödiant Karl Valentin humorvoll die Tradition jenes Gefühls beschrieben, das schon der alte Cicero mit „O tempora! O mores!“ zum geflügelten Wort machte und das seinen fatalistischen Gipfel im „No future!“ der Punk-Bewegung erreichte.

Aber: That’s life. Love it or hate it, but learn to live with it.

Auch in unserer Zunft, der Software-Entwicklung und ‑Absicherung, merken wir seit einiger Zeit, dass die „Zukunft früher auch besser war“. Grundannahmen ändern sich so massiv, dass ein Festhalten an bewährten Ansätzen alleine nicht mehr trägt, schon weil diese oft an einem nicht mehr zu leugnenden Aspekt scheitern: exponentiell wachsende Komplexität und Dynamik, nicht erst, aber vor allem im Zuge der grassierenden Digitalisierung.

Dieser Artikel soll einige Denkanstöße geben, wie wir mit den Herausforderungen der nächsten Jahre umgehen könnten. Dabei geht es weniger um Patentrezepte, die es per definitionem für eine ungewisse Zukunft nicht geben kann, sondern um eine grundsätzlich andere Haltung, aus der heraus sich dann Handlungstaktiken ableiten lassen.

Heute haben wir eher zu viel Zukunft¹ – und sie kommt zu schnell und zu mächtig; zumindest wenn man auf Sicherheit steht. Was für Ökosysteme und das Klima schon lange gilt, trifft zunehmend auch auf von Menschen erdachte Systeme zu: Die immer komplexer werdende Welt hält uns fast täglich vor Augen, dass wir sie nicht mehr im hergebrachten Sinne beherrschen.

Als Verfechter von Qualitätssicherung (oder auch nur als ethisch gefestigter Mensch) kann einem natürlich bange werden, wenn man sich gewisse technische Entwicklungen und ihre möglichen Folgen vor Augen hält und extrapoliert. Da werden von Hackern die Bremsen von (amerikanischen) Autos während der Fahrt außer Kraft gesetzt. Da werden (oft gegen den Rat von Experten) „smarte“ Ansätze bei kritischen Infrastrukturen, wie z.B. Energienetzen, von der Politik forciert, während gleichzeitig der Cyberwar ausgerufen wird. Da werden teure Löcher in Innenstädte gegraben, um … . Nein, lassen wir diese Baustelle … .

Kürzlich hat uns ausgerechnet ein Stück künstliche Intelligenz (sagen wir lieber: Deep Machine Learning) gleichsam den Spiegel vorgehalten und die conditio humana aufgezeigt: Im Frühjahr 2016 ließ ein bekannter Software-Hersteller einen Social-Bot auf Facebook los, um zu beweisen, dass er nicht nur Betriebssysteme und Büroanwendungen entwickeln kann.

Was als Marketing-Coup gedacht war, wurde von Teilen der Netz-Community so schnell „angelernt“, dass es innerhalb nur eines Tages die vielbeschworene Hasskultur verinnerlicht hatte und mit sexistischen und rassistischen Pöbeleien so auffiel, dass man sich gezwungen sah, das Profil des Bots wieder aus dem Netz zu nehmen. O tempora! O mores!

Auch wenn dieses letzte Beispiel eher zum Schmunzeln anregt (nicht zuletzt, weil es einen Konzern getroffen hat, den man eher mit Marketing als mit Qualitätssicherung assoziiert), so bleibt einem das Lachen doch im Halse stecken. Man fragt sich nicht nur „In was für Zeiten leben wir eigentlich?“, sondern vor allem „Beherrschen wir unsere Systeme noch?“ – oder konsequenter: „Lassen sie sich überhaupt noch beherrschen?“.

„Die ich rief, die Geister, werd ich nun nicht los“. Wie Goethes Zauberlehrling mag sich mitunter mancher Ingenieur vorkommen. Auf der Stuttgarter Fachkonferenz „AutoTest“ wurde kürzlich von einem Crash eines autonomen Google-Cam-Autos berichtet. Bei einem zuvor tausende Male erfolgreich vollzogenen Spurwechsel in der Rush Hour traf es das erste Mal auf einen Linienbus auf der Nachbarspur, der nicht bremste, als es vor ihm in eine Lücke scherte. Man hatte versäumt, der Fahrsteuerung beizubringen, dass bestimmte Fahrer qua Berufsbild zur Kompromisslosigkeit neigen …

¹ In der asynchronen Programmierung gibt es sogar einen generischen Datentyp namens Future, der ermöglicht, Ketten asynchroner Funktionsaufrufe zu bilden, als wenn sie synchron wären. Ein passendes Beispiel, wie die Menschheit es immer wieder schafft, mit geeigneten Abstraktionen eine eigentlich nicht mehr begreifbare Welt zu beherrschen.

Das Beispiel des autonomen Fahrens verdeutlicht einen Paradigmenwechsel, den wir in der realen Welt schon vollzogen haben. Während sich soziale Interaktion früher relativ überschaubar darstellte (es soll ja mal berittene Boten als Kommunikationsmedium gegeben haben), spielt sich heute ein Großteil in den sozialen Medien ab. Ohne dies kulturphilosophisch bewerten zu wollen, muss man festhalten, dass dabei völlig andere Regeln und Effekte auftreten, vor allem eine nicht vorhersagbare Dynamik, siehe das eben erwähnte Bot-Beispiel.

Was wir Menschen erleben, gilt aber zunehmend auch für unsere Software-Systeme. Traditionell waren sie, was man früher „Stubenhocker“ genannt hätte. Auch heute gibt es noch jede Menge Monolithen (egal, ob sie in COBOL, Java oder .NET entwickelt wurden), die am liebsten gar nicht mit der Welt reden und wenn überhaupt, dann nur über sehr eingeschränkte, oft grotesk spartanische Interfaces.

Mancher mag einwenden, dass das nicht stimmt, und auf eine strukturierte Modularisierung oder womöglich sogar auf eine SOA² verweisen. Ja, natürlich haben wir spätestens seit den Anfängen der funktionalen Dekomposition in den 70er Jahren gelernt, IT-Systeme aus immer mehr und kleineren Subsystemen und Komponenten zu bauen. Jedoch: Egal, wie groß es war, am Ende gab es doch bislang immer so etwas wie ein System, das nach dem Erklimmen der rechten Flanke des V‑Modells einem Systemtest unterzogen und abgenommen werden konnte.

Dieses Paradies der Beherrschbarkeit müssen wir verlassen. Heute ist es häufig ein zentraler Gegenstand von Projekten aller Branchen, Systeme so zu bauen, dass sie eben nicht abgeschlossen sind, sondern offen mit anderen Systemen interagieren (selbst mit solchen, die nicht bekannt sind, ja vielleicht noch nicht einmal gebaut wurden). Egal, ob es dabei um das Verfügbarmachen und/oder Nutzen von offenen Services geht, um Erweiterungskonzepte (Wer hätte vor ein paar Jahren an Apps für Autos gedacht?) oder um eine massive Interaktion als Haupteigenschaft (wie beim autonomen Fahren oder bei IoT/Industry 4.0). Unsere Systeme sind Teil eines größeren Systems geworden, das wir nicht mehr testen können, ja das nicht einmal definiert werden kann! Sie begeben sich in Gesellschaft.

² Jener Hype, der grandios gescheitert ist bzw. oft zu einer massiven Verteuerung und Verlangsamung von IT-Projekten geführt hat, obwohl man genau das Gegenteil versprochen hatte. SOA verdeutlicht, was passiert, wenn man zulässt, dass bei etwas im Ansatz richtigen als erstes die Grundprinzipien über Bord geworfen werden (damals war das Ziel die leichtere Einführung, Anpassung und Verknüpfung von Business Services).

Diese völlig neue Qualität von Systeminteraktion bedeutet immanent das Ende der Vollabsicherung. Natürlich würde eine theoretische Vollabsicherung schon am Ressourcenaufwand scheitern. Aber schon ihre Definition ist utopisch: Experten schätzen, dass selbst mit drei Millionen Kilometer Testfahrten zum Sammeln von Testdaten maximal etwa zwei Prozent aller möglichen Szenarien erfassbar sind, auf die ein Auto im Laufe seines „Lebens“ treffen könnte. Vor allem ist diese Quote durch mehr Testkilometer nicht signifikant zu steigern! Wer will angesichts solcher Zahlen vorhersagen können, ob sich ein System in allen Situationen ordnungsgemäß verhält? Und was ist „ordnungsgemäß“ überhaupt?

Wenn man diesen Gedanken aber konsequent weiterentwickelt, gelangt man zu folgendem Schluss: Wir müssen die Art und Weise, wie wir Systeme entwickeln und ihre Qualität sichern, grundsätzlich überdenken. Wir können sie nicht länger nur wie ein abgeschlossenes Werkstück betrachten, das man in einem definierten handwerklichen Prozess fertig – stellen und mit der Schieblehre auf zuvor definierte Qualitätskriterien überprüfen kann.³

Stattdessen sind unsere zukünftigen Systeme eher unseren Kindern gleich: Nachdem wir sie erzogen und lebensfähig gemacht, ihnen also gute Wurzeln gegeben haben, werden sie flügge – oder wir schubsen sie aus dem Nest. Wir entlassen sie nolens volens in eine Zukunft, die wir liebevoll und aufmerksam begleiten mögen, die wir aber weder vorab kennen noch wirklich beeinflussen können. Wir können ihnen nur unsere Erfahrungen und Werte mitgeben.

Wenn wir lernten, Systeme so zu entwickeln wie unseren Nachwuchs – angefangen bei der Liebe und dem Verantwortungsgefühl – hätten wir einen großen Schritt gemacht; nicht nur als Software-Experten, sondern als Menschheit. Denn unverkennbar befinden wir uns an der Schwelle dessen, was vor einigen Jahrzehnten noch (meist düstere) Science-Fiction war: Maschinen nehmen zunehmend eigenmächtig am Leben teil und organisieren diese Teilhabe untereinander. Und damit das nicht in Schreckensszenarien endet, müssen wir sie nach unseren ethischen Maßstäben „erziehen“.

Das fängt bei der von Isaac Asimov in seinen „Roboter-Gesetzen“ vorgeschlagenen Forderung an, in künstlicher Intelligenz ganz tief zu verwurzeln, dass eine Maschine unter keinen Umständen einen Menschen aktiv verletzen oder töten darf. Analog dem Art.1 GG, an den wir als Menschen gebunden sein und in dessen Ethos wir unsere Kinder erziehen sollten. Umgekehrt – so wie wir uns von unseren Kindern mitunter zu Recht anhören müssen „Davon verstehst Du nichts“ – muss es vielleicht sogar bei der Forderung enden, dass Menschen die Entscheidungen von Maschinen nicht „verschlimmbessern“ dürfen, weil sie ihnen auffassungsmäßig nicht gewachsen sind.⁴

Jedem, der am Entwurf von Systemen beteiligt ist, sei vor diesem Hintergrund folgende Tugenden empfohlen: Vertrauen, Respekt und Demut. Besonders dieser letzte, leider etwas aus der Mode gekommene Begriff verdeutlicht, worum es geht: Teil eines Größeren zu sein, das man weder begreifen noch kontrollieren kann, zu dem man aber konstruktiv seinen Teil beizutragen hat.

³ Bitte das nicht falsch verstehen. Handwerkliche Qualität ist nicht nur nicht unwichtig geworden, sie wird zukünftig noch wichtiger (s. folgende Ausführungen). Aber sie kann nur noch ein Teil der Absicherung sein, für die größeren Aspekte braucht es andere Ansätze.

⁴ Die Kollision zweier Flugzeuge im Luftraum über dem Bodensee vor einigen Jahren ging auf menschliches Versagen zurück. Zunächst hätten die Flugzeuge gar nicht so dicht aneinander gelotst werden dürfen. Das eigentliche Problem war aber folgendes: Die Autopiloten der Flugzeuge hatten untereinander ein Ausweichmanöver verabredet, das die Distanz zwischen ihnen maximieren sollte. Der Pilot der daraufhin absinkenden Maschine hat dieses Manöver, das er womöglich nicht schnell genug als solches verstanden hat, korrigiert und damit genau in die andere Maschine gelenkt!

Es gibt nichts Tödlicheres als das Leben. Eltern wissen das, weil sie in ständiger Sorge um ihre Kinder leben. Trotzdem hören wir ja nicht auf, Kinder zu erziehen und auch loszulassen. Kontrolliertes Risiko könnte man jenen Erziehungsansatz nennen, der Kindern ermöglicht, eigene Fehler zu machen und daraus zu lernen. Eine endgültige Sicherheit kann es nicht geben, man kann sich nur gegen unnötige Risiken wappnen.

Was bedeutet das, auf unsere Systeme übertragen? Als im Frühjahr der erste Todesfall durch autonomes Fahren gemeldet wurde, bei dem ein begeisterter Tesla-Fahrer unter einen querfahrenden weißen Laster geriet, der von seinem System als Wolke missinterpretiert wurde, war der Aufschrei groß, inklusive jener Stimmen, die es „ja schon immer gesagt“ haben.

Psychologisch ist das verständlich, da ein Tabu gebrochen wurde, indem ein Mensch ums Leben kam, nachdem er dieses einer Software anvertraut hatte.

Aber unabhängig davon, wie man persönlich zum autonomen Fahren steht, muss man nüchtern konstatieren, dass weltweit täglich hunderte Menschen bei ähnlichen Unfällen sterben, weil sie oder andere Menschen einen Fehler gemacht haben.

Und jetzt wird es bitter für Freunde einer Vollabsicherung: Wenn (und dieser Trend scheint nicht aufzuhalten zu sein) wir uns durch Maschinen wirklich so massiv entlasten wollen, dass sie sogar unsere Entscheidungen treffen, müssen wir zugestehen, dass diese letztendlich vom Menschen gemachten Maschinen auch fatale Fehler machen werden (und dürfen), so bitter das im Einzelfall auch ist. Entscheidend sind unser verantwortungsvoller Umgang mit der Technologie und die gezielte Rückführung solcher Erfahrungen in diese hinein. Wäre es nicht toll, wenn Systeme solche Erfahrungen untereinander weitergäben, wie es die Menschen seit Urzeiten am Lagerfeuer gemacht haben?

Jeder vermeidbare Schaden ist einer zu viel, gewiss. Aber eine fehlerfreie Welt ist Utopie. Und deshalb zählt am Ende die ganz einfache statistische Frage, ob in Summe die Maschinen eine geringere Fehlerquote haben als Menschen. Ein Verteufeln aufgrund einzelner Fehler ist weder hilfreich noch sollte es eine sinnvolle Technologie verhindern. Auch durch Gurte sind schon Menschen gestorben, weil sie sich z.B. nicht schnell genug aus einem brennenden Auto befreien konnten. Trotzdem würde niemand den überragenden Sicherheitseffekt von Rückhaltesystemen in Frage stellen. Vielleicht denken wir in einigen Jahrzehnten so auch über autonomes Fahren, wenn wir unser Unbehagen abgelegt haben.

Was allerdings gegeben sein muss: Maschinen dürfen Menschen nicht unnötig in Gefahr bringen – sei es durch eine zu große Fehlerquote (dann darf die Maschine schlichtweg nicht an Menschenstelle Entscheidungen treffen, sondern bestenfalls assistieren, so wie es die Stufen auf dem Weg zum autonomen Fahren ja auch vorsehen), sei es durch fahrlässiges Handeln. Selbstverständlich wäre es in keiner Weise hinnehmbar, wenn z.B. autonome Fahrzeuge so etwas wie jene verbotenen Straßenrennen veranstalten würden, bei denen regelmäßig Menschen zu Schaden kommen und bei denen wir uns fragen, was bei der Erziehung der Fahrer schief gelaufen ist. Was uns wieder zum Kernpunkt führt:

Maschinen sollten und können Regeln konsequenter befolgen als Menschen. Und letztendlich dienen ja z.B. Verkehrsregeln einem: der gegenseitigen Rücksichtnahme und Risikominimierung. Wäre das nicht ein lohnendes Entwurfsziel?

Fahrschülern werden aus gutem Grund die Prinzipien defensiven und vorausschauenden Fahrens eingebimst. Und an diesen Prinzipien sollten wir auch unsere Systeme ausrichten. Nicht nur die zum autonomen Fahren, sondern wir sollten es zum allgemeinen Prinzip unseres Entwurfs machen, um übergreifenden Systemverbünden ein möglichst geschmeidiges und fehlerarmes Funktionieren zu ermöglichen.

Das könnte ein defensives System analog zu einem defensiven Fahrer kennzeichnen:

Es beachtet die zum Gemeinwohl konstruierten Regeln insbesondere anderen Systemen (Mensch und Umwelt sind in diesem Sinne auch Systeme) gegenüber.
Es rechnet umgekehrt damit, dass andere sich gegebenenfalls nicht an diese Regeln halten oder schlichtweg Fehler machen, und besitzt deshalb Taktiken zur Folgefehlervermeidung (das betrifft zum einen Fehler im eigentlichen Sinne, zum anderen Schutz gegen Schadsoftware).
Es ist in der Lage, ein nicht ganz konformes Verhalten anderer zu tolerieren, um den gesamten Prozess nicht zu blockieren.⁵
Es verhält sich auch in Stresssituationen regelkonform (im Extremfall dadurch, dass es eher den Dienst einstellt, als Regeln zu verletzen, deren Einhaltung es nicht mehr garantieren kann.⁶ ).

Der Transfer des „defensiven Fahrens“ ist also gar nicht so schwer, die konkrete Umsetzung dann vielleicht schon eher – aber dafür sind wir alle ja Experten oder kennen welche. In vielen Umfeldern, gerade von Großprojekten, wird das vor allem eine organisatorische Herausforderung sein, man denke an Conway’s Law.

Im Folgenden nur einige Anregungen, wo die digitale Reise hingehen könnte:

Microservices als der State of the Art des „Teile und herrsche“ sind besonders durch die „Shared- Nothing“-Architektur ideal für den Entwurf „sozialer“ Systeme.
Konzisere, formale Systembeschreibungen wie Zustandsmodelle, DSLs und natürlich die bereits existierenden Schnittstellen-Standards, wie z.B AUTOSAR, müssen konsistenter und konsequenter genutzt werden.
Hochintegrierte Entwicklungsverfahren, wie z.B. Behavior Driven Design, die Medienbrüche vermeiden und früh eine hohe Automatisierungsquote erzielen.
Robustheitstests, deren Ziel es ist, nachzuweisen, dass der Service in allen denkbaren Konstellationen seinen Qualitätsanforderungen genügt.
Machine Learning in der Qualitätssicherung (z.B. in Hinblick auf Planung enger Testressourcen, aber auch auf inhaltliche Qualität).
Betriebskäfige, die (analog zu den Käfigen von Industrierobotern) den eigentlichen Service zur Laufzeit einbetten, um Schaden zu verhindern, Annahmen zu verifizieren u.ä..

Diese Liste ließe sich beliebig fortsetzen und vertiefen, was hier aber aus Platzgründen entfallen muss. Wir freuen uns auf Erfahrungs- und Ideentausch, aber natürlich auch auf Zusammenarbeit bei solchen Themen.

⁵ Dieser Punkt bezieht sich im Straßenverkehr z.B. darauf, jemanden einscheren zu lassen, der sich falsch eingeordnet hat, da man schließlich nicht wissen kann, ob er nur einen Fehler gemacht hat oder sich bewusst einen Vorteil verschafft. Bei Systemen wäre darunter z.B. eine liberale Schnittstellenimplementierung zu verstehen, die kleinere Fehler akzeptiert oder gar kompensiert (wenn z.B. nur die PLZ, aber nicht der Ortsname angegeben ist).

⁶ Viele Assistenzsysteme stellen z.B. ihren Service angekündigt ein, wenn man ihn sich gerade besonders wünschen würde: Z.B. wenn bei schwerem Schneefall die Datenqualität von optischen oder Radarsensoren nicht mehr ausreicht. Im Gegensatz zu einem Menschen sollte sich ein System nicht überschätzen.

Der bewusst etwas kontroverse Artikel sollte aufzeigen, dass wir uns von der Vollabsicherung vergangener Tage verabschieden müssen, weil in Zeiten der Digitalisierung, des autonomen Fahrens und des IoT ein Großteil des Verhaltens zwischen den Systemen stattfindet, wo er kaum zu beschreiben, vorherzusehen und abzusichern ist. Als Experten für Qualitätssicherung sollten wir deshalb aber nicht den Kopf in den Sand stecken, sondern auf ein Umdenken hinwirken.

Je unmöglicher wegen der Komplexität eine Absicherung im Großen wird, desto wichtiger wird sie im Kleinen. Das ist vor allem auch eine Frage des Entwurfs und der Entwicklungsmethodik. Wir plädieren dafür, den Systementwurf in Richtung „defensive Systeme“ zu entwickeln, die sich analog zum defensiven Fahren so verhalten, dass das unüberschaubare Gesamtsystem möglichst reibungs- und fehlerlos funktionieren kann.

In einer Zeit, da die klassische Qualitätssicherung an Komplexitätsgrenzen zu scheitern droht, ist es an uns Experten vom ASQF, unsere Kunden zu neuer Qualität zu führen. Das ist unser Apfelbäumchen in einer kaum noch beherrschbaren Welt.

No risk, no fun(ction), no future! (Wie) lassen sich software-basierte Systeme in einer komplexer werdenden Welt noch beherrschen?

No future?

Soziale Systeme

Roots to grow and wings to fly