© Tennessee Witney / 123RF.com

Wer Entscheidungen über neue Produkte oder Projekte fast nur nach Technologie ausrichtet, handelt sich Technology-driven Design ein. Manchmal klappt das sogar, doch es überwiegt die Gefahr der Betriebsblindheit.

Egal, ob KI, Blockchain, Corona-Warn-Apps oder einfach nur die Lieblingstechnologie vom neuen CTO: Allzu oft entscheiden Unternehmen, Behörden oder die Politik nicht danach, was sich langfristig für Anwender oder die Firma auszahlt. Stattdessen basieren ihre Produktstrategien auf Technologien, die gerade hip sind und durch die Medien getrieben werden oder von denen das Management überzeugt ist, dass sie sich als “the next big thing” entpuppen.

Experten nennen das Technology-driven Design (TDD). Dieser Artikel erklärt an mehreren Beispielen, was schieflaufen kann und worauf Sie achten müssen, wenn Sie TDD sinnvoll einsetzen wollen. Das lässt sich durchaus machen – hinter TDD verbirgt sich mehr als nur das berüchtigte Anti-Pattern in der Softwareentwicklung.

KI für alle!

Beispiel Nummer eins: 2023, der Sommer von ChatGPT. Selbstredend möchte die Bundesregierung künstliche Intelligenz in der Verwaltung haben – am besten aber bitte gleich aus Deutschland, wegen der DSGVO und des europäischen Rechtsraums. Das lässt sich absolut nachvollziehen, doch was genau soll das bringen? Böse Zungen meckern, jede Form von Intelligenz bei der Digitalisierung wäre hilfreich, erst recht nach den Fehlschlägen der letzten Jahre.

In der Verwaltung soll das baden-württembergische Startup Aleph Alpha aus Heidelberg ins Spiel kommen, das im Ländle bereits digitale Assistenten für die öffentliche Hand zur Verfügung stellt. Aber wer die Berichte liest [1], kommt zu dem Schluss, dass außer dem Commitment zu künstlicher Intelligenz auf der Basis von Large Language Models (LLM) kaum Greifbares existiert. Man plant einen KI-Assistenten für Textvorlagen und -analysen namens F13. Er wurde für den “internen Gebrauch von Verwaltungsangestellten” entwickelt und basiert auf dem KI-System Luminous von Aleph Alpha (Abbildung 1). F13 darf Menschen keine Entscheidungen abnehmen, sondern soll dabei helfen, “Mail-Flut, Fachkräftemangel und Mitarbeiterfluktuation” zu kompensieren. Damit will man verhindern, dass internes Prozesswissen verloren geht. Das klingt so weit durchaus sinnvoll.

Wie seine Vorbilder aus den USA braucht Aleph Alpha jedoch “noch ein wenig Erziehung” [2]: Mitunter mischen sich frauen- oder ausländerfeindliche Inhalte in die Antworten. Das Problem sei lösbar, verspricht der Hersteller, und im Behördenumfeld käme das nicht vor, weil die Textgrundlage eine andere sei. Ob F13 auch in Behörden unter dem Input-Bias leidet, bleibt abzuwarten.

Schlimmer wiegt, dass laut Bundesrechnungshof kaum jemand beim Einsatz von KI mit sinkenden Kosten rechnet. Zudem habe kaum eine Behörde Strategien und Konzepte im Köcher, heißt es auf Netzpolitik.org, unwirtschaftliche Parallelentwicklungen seien wahrscheinlich. Klar scheint nur: KI soll es sein, denn die Technologie liegt im Trend – Kinderkrankheiten werden sicher noch korrigiert. Kritiker monieren mangelnden Überblick bei den Entscheidern, sprechen von “Wir-jetzt-auch”-Beschlüssen und warnen vor systemimmanenten Schwächen der LLMs.

Abbildung 1: Die deutsche KI Aleph Alpha steckt zwar noch in den Kinderschuhen, soll aber in Behörden zum Einsatz kommen.

Damit stehen die Behörden keineswegs allein da: Spätestens, seit Medienberichte über ChatGPT sowohl die Fähigkeiten als auch die Defizite von Large Language Models in das öffentliche Bewusstsein rückten, springen mehr und mehr Firmen auf den KI-Zug auf. Das Label zieht und bringt Marketing-Punkte. Allerdings ist eher selten klar, worin der Nutzen des zu designenden Produkts liegen soll. Technology first, das Produkt kommt dann schon, wenn wir “drin sind” – genau das ist Technology-driven Design. Wer neue Produkte überwiegend anhand von Technologien entwirft, ohne das Problem oder die Lösung zu kennen, für das er entwickelt, betreibt TDD.

Nicht immer ist das unsinnig, manchmal entstehen daraus innovationstreibende Produkte. Technology-driven Design kann – vor allem, wenn der Staat derlei Entscheidungen verkündet – ebenso mit großer Signalwirkung verbunden sein. Am Anfang steht dabei der berechtigte und nachvollziehbare Wunsch, eine neue, meist hippe Technologie einzusetzen. Erst nach dieser Entscheidung sucht man ein Problem, ein Produkt oder eine Lösung: “Wir haben da doch das Framework X gekauft, was können wir jetzt damit programmieren?”

Spahn sucht Konzept

Obwohl das zweite Beispiel schon etwas in die Jahre gekommen ist, sucht es noch immer ein Produkt. Bis dato fehlt eine Anwendung für die Blockchain im Gesundheitswesen. Viele Idealisten sahen sich zwar von den Versprechungen der Technologie enttäuscht, trotzdem reichte der Einfluss der Hypes ohne Use Case bis in die Politik. Dahinter steckt ein weiteres Charakteristikum von TDD: Viel häufiger als Entwicklungsabteilungen bewegen sich Politiker und Manager im TDD-Raum von inhaltsarmen Ankündigungen oder diffuser Anforderungen.

So suchte der damalige Gesundheitsminister Jens Spahn (CDU) 2018 Produkte für den E-Health-Sektor, explizit auf Blockchain-Basis [3] (Abbildung 2). Die Entscheidung für die Technologie fiel zuerst, nach dem Prinzip: Schauen wir mal, was wir damit anfangen können; ob es Sinn ergibt, entscheiden wir später. Bei einem Ideenwettbewerb mag das in Ordnung gehen, der übliche Blockchain-Shitstorm ließ jedoch nicht lange auf sich warten.

Abbildung 2: Gesundheitsminister Jens Spahn forderte 2018 mehr Blockchain-Technologien im Gesundheitssektor – Zweck unbekannt.

Die Entscheidung, die Corona-Warn-App (CWA) auf Bluetooth-Abstandsmessung aufzubauen, fällt ebenfalls unter TDD. Zugegeben, GPS bietet nicht genügend Genauigkeit, und viel von der Debatte ging in der Diskussion um zentrale oder dezentrale Speicherung unter. Obwohl die CWA später durchaus sinnvolle Features bekam, galt die aus virologischer Sicht wünschenswerte Abstandsmessung via Bluetooth niemals als ausreichend genau für effektive Kontaktverfolgung.

Das musste sie auch nicht, denn die am Ende über 200 Millionen Euro teure Technologie gab es schon – festgelegt von der Politik, weil Smartphones ja überall sind. Auf Nachfrage erklärten die entwickelnden Fraunhofer-Experten, sie hätten politischen Vorgaben zu folgen. Die Effizienz der Abstandsmessung und die Plausibilität der Ergebnisse (80 Prozent Trefferquote unter Laborbedingungen) seien nicht Bestandteil der Betrachtungen gewesen [4].

Digitales Klopapier

Die skandalöse, Millionen Euro teure Luca-App für die Covid-Nachverfolgung in der Gastronomie verdeutlicht, wie TDD den Diskurs beeinflusst und Menschenmassen zu mobilisieren vermag. Das müsse mit dem Smartphone doch besser gehen, lautete die Grundthese. Luca war ein Paradebeispiel des TDD aus der Kategorie “Digitales Klopapier”. Bei diesem verbreiteten Sonderfall werden funktionierende analoge Lösungen durch massiven und unnötigen Einsatz von Technik verschlimmbessert. Projektmanager wissen: Wer einen schlechten analogen Prozess digitalisiert, bekommt am Ende einen schlechten digitalen Prozess.

Immerhin lag beim Thema Kontaktverfolgung in Restaurants bereits vorher ein zu lösendes Problem vor. Doch beim Festlegen auf die Technologien warfen die Technokraten alle Bedenken über Bord. Es war doch klar, dass digital besser ist als analog, egal wie. Der Rest ist Geschichte. Jetzt will man die Datenschutzkatastrophe Luca in ein Bezahlsystem umbauen, eine Art “europäisches Paypal” [5].

Die damals aufgebrachten fünf Blockchains im Backend des digitalen Impfausweises [6] waren ein weiterer klarer Fall von TDD – es musste halt Blockchain sein. Das Beispiel Luca zeigt, wie leicht es oft fällt, mit Technology-driven Design und Buzzwords zweistellige Millionenbeträge aus Steuergeldern als Anschubfinanzierung zu gewinnen. Gutes Marketing schadet nie, wohlüberlegte technische Konzepte für ein Produkt sind dagegen offenbar nicht zwingend erforderlich.

Hype und hyper

Technology-driven Design gibt es nicht nur im Umfeld politischer Entscheidungen und fragwürdiger Ausschreibungen. In Unternehmen, gerade in größeren Firmen und Startups, steht die Technologie anfangs gleichermaßen im Vordergrund. Sätze wie “Wir haben doch das Entwicklungs-Framework für Rust/Ruby/Go/… angeschafft – was machen wir jetzt damit?” fallen häufiger, als man erwarten würde. Zahlreiche Entwickler dürften das Szenario kennen: Der neue CTO hat eine Lieblingstechnologie – die einen finden KI toll, die anderen Blockchain und wieder andere stehen auf moderne Programmiersprachen wie Rust oder Go (vor einigen Jahren war es vielleicht Python, davor Ruby). Die Manager zeigen sich überzeugt, und nicht immer muss es sich als Fehler erweisen, die eigenen Mitarbeiter in neue Richtungen zu stupsen. Bisweilen geht es dabei ja auch um den Know-how-Aufbau.

Trotzdem verleitet der Hype zum Ignorieren offensichtlicher Probleme. Beim Thema KI/LLM liegen die Probleme derzeit eher in der Qualität der Ergebnisse: 5 Prozent Fehlerquote würde man einem Mitarbeiter nie zugestehen, ganz zu schweigen von den 20 Prozent bei der Abstandsmessung der Corona-Warn-App. Aleph Alpha schickt die Frauen zurück in die Küche; in San Francisco streicht die Stadt gerade die Lizenzen für die autonomen Taxis zusammen, weil sie allzu oft den Verkehr stören [7]. ChatGPT erklärt allen, dass Eier schmelzen, weil eine andere KI das mal in ein Quora-Forum eingegeben hatte [8].

Ob sich das verbessern wird, nachdem OpenAI ChatGPT ins Internet entlassen hat, bleibt fraglich. Selbst die Menschheit hat nach Jahrtausenden Begriffe wie “Qualität”, “Wahrheit” und “Relevanz” noch nicht schlussendlich definieren können. Laut seiner Keynote bei der Ars Electronica 2023 [9] fehlt auch Wikipedia-Gründer Jimmy Wales der Glaube, ChatGPT könne dereinst Artikel in der Wikipedia schreiben. Der Fehler in den LLMs liegt im System; wer das nicht glaubt, sollte Kurt Gödels Unvollständigkeitssatz [10] nachlesen.

Open-Source-Legacy-Falle

Im Kontrast dazu ist in einigen Firmen und Konzernen TDD die einzige verfügbare Möglichkeit. Wer Legacy-Code mitschleppt, weil er beispielsweise bei oder für Microsoft oder Atlassian entwickelt, dem ist klar, dass ihn in diesem Ökosystem unabänderlich Azure, Confluence und Konsorten als technologische Basis erwarten. Ebenso können Atlassian, Oracle und andere kaum ihre Technologie-Stacks über Bord werfen.

Technology-driven Design führt angesichts dessen geradewegs in die Legacy-Falle. Diese Nische bespielen Firmen wie Microfocus (früher Suse-Eigentümer) selbstsicher. Allein die Existenz von Produkten wie Visual Cobol (Abbildung 3) spricht Bände [11]. Bei Suse grassierte nach der Übernahme 2014 der Witz, auf der nächsten Hausmesse gäbe es T-Shirts mit dem Aufdruck Wir programmieren die Legacy-Software von morgen. #Microfocus.

Abbildung 3: Kein Witz, sondern viel nachgefragt: Mit Visual Cobol kombiniert der Legacy-Experte Microfocus digitales Altertum mit “modernen” Frameworks für Anfänger. Das soll Firmen helfen, die in der Legacy-Falle alter Technologien steckengeblieben sind.

Die Aussage, man mache das jetzt alles in Open Source, lässt sich genauso als Technology-driven Design interpretieren. Das trifft vor allem dann ins Schwarze, wenn abseits der Ansage nichts Gehaltvolles zu finden ist. Eine Bundesregierung, die zunächst im Koalitionsvertrag großen Wert auf freie Software legt, dann aber zurückrudert und am Ende Milliarden (Abbildung 4) an Oracle überweist [12], macht sich zumindest verdächtig, Entscheidungen nicht nach Kriterien der Nachhaltigkeit zu treffen. Ja, Open Source kann als Technologietreiber funktionieren, muss es aber nicht. Unbestritten sind jedoch die Vorteile – vom Rad, das man nicht mehr neu erfinden muss, bis hin zu Einsparungen und Gewinnen an Sicherheit, Transparenz und mehr.

Abbildung 4: 3,9 Milliarden Euro gibt der Bund für eine Oracle-basierte Verwaltungs-Cloud aus. Kritiker greifen die Entscheidung an und wollen wissen, wie es zur Auswahl dieser Technologie kam.

Anwenderzentriert

Ganz abgesehen davon, welche Technologie man betrachtet oder welche das Management bevorzugt, darf TDD niemals die gewünschten Anwender aus dem Blick verlieren. Sie müssen das Produkt brauchen, haben wollen und schließlich benutzen. Niemandem ist gedient, wenn noch so perfekte Produkte in Schönheit sterben – die IT-Geschichte ist bereits voll davon. Bei Kryptowährungen wie Bitcoin hatte man die Transaktionskosten nicht auf dem Radar. Luca verpeilte die Zusammenarbeit mit den Gesundheitsämtern, die wegen der App-Daten mehr statt weniger Arbeit hatten. Die Betriebsblindheit wirkt systemimmanent.

Wer frei von Hypes entscheiden will, welche Technologie die richtige für das eigene Problem ist, sollte anders vorgehen. Der klassische Ansatz erscheint vielleicht langweiliger, hat sich aber bewährt und ist meist nachhaltiger: Zunächst identifizieren Sie das zu lösende Problem. Daraufhin folgt die Marktanalyse mit Fragen wie “Gibt es da schon was?” und “Wie machen das andere?”.

Frühestens an diesem Punkt ist es sinnvoll, sich mit der Technologie (Programmiersprache, Cloud-Stack etc.) auseinanderzusetzen. Wer sich vor den technischen Details auf die strukturelle Meta-Ebene begibt, kann später außerdem einfacher den Technologie-Stack austauschen. Hilfestellungen für das sinnvolle Strukturieren einer Abteilung, die unabhängig Entscheidungsgrundlagen erarbeiten soll, gibt es wie Sand am Meer. Zum Beispiel helfen agile Methoden dabei, nicht auf tote Pferde zu setzen.

Fazit: Scheuklappen weg

Es ist essenziell, stets Alternativen im Auge zu behalten. Dabei lohnt es sich, nicht nur auf die Erfolgreichen unter den Marktteilnehmer zu achten: Gerade von den Verlierern lässt sich oft weit mehr lernen (Survivorship Bias [13]).

Im agilen Umfeld helfen Methoden wie negative Dokumentation: Teams, die festhalten, warum sie Entscheidungen gegen Technologien oder Tools treffen, sparen sich anhaltende Grundsatzdiskussionen. Gleichzeitig können sie jederzeit in kurzen, informierten Meetings die getroffenen Entscheidungen hinterfragen, wenn neue Entwicklungen (an-)kommen. Eine kurze Liste, etwa im Gitlab-Repo, mit dem Titel “Wir haben bei den Doku-Skripten nicht auf Python gesetzt, weil: …” genügt vollkommen.

Das Wichtigste ist aber wie immer, informiert zu bleiben. Wer sich allzu früh auf eine Technologie festlegt, setzt seiner Firma unnötige Scheuklappen auf, die vielleicht den Blick auf Gelegenheiten abseits der Roadmap verbauen. (csi)