15 Jahre lang Systeme gebaut, die funktionieren müssen

Kurzfassung

Ich bin Senior AI Product Architect und habe 15 Jahre als Plattformarchitekt und externer Tech-Lead bei Siemens, Deutsche Telekom, Mercedes-Benz und anderen verbracht. Heute liegt mein Fokus auf der Konzeption und Lieferung von produktionsreifen KI-Systemen für Enterprise-Teams: von der Use-Case-Identifikation und PoC-Entwicklung über die Datenpipeline, Modellauswahl und Governance, mit Blick auf die Anforderungen des EU AI Act. Die Entscheidungen, die bestimmen, ob Ihr KI-System in die Produktion geht und dort bleibt, oder in einer Staging-Umgebung auf eine Freigabe wartet, die vielleicht nie kommt.

Mein Fokus liegt auf Enterprise-KI-Produkten und internen KI-Systemen, die von der Pilotphase in den Produktionsbetrieb müssen, nicht unter Demo-Bedingungen.

Meine Arbeit erstreckt sich auf Automotive, Telekommunikation, Smart Energy, Fertigung und Fahrerschulung. Der gemeinsame Nenner: grosse Organisationen mit komplexen Plattformen, die liefern müssen, ohne das zu beschädigen, was bereits funktioniert.

Ich bin in Deutschland ansässig. Ich habe meine Karriere bei Hewlett-Packard und frog begonnen, beides amerikanische Unternehmen, und habe während meiner gesamten Karriere mit verteilten Teams in den USA, Europa und Indien zusammengearbeitet. Ich bin vor Ort, wenn die Arbeit es erfordert, ob in Europa, den USA oder anderswo.

Was ich gelernt habe

Die meisten Architekturprobleme sind keine Technologieprobleme. Sie sind Zuständigkeitsprobleme. Unklare Modulgrenzen, gemeinsame Abhängigkeiten, die niemand warten will, Build-Systeme, die Teams bestrafen, wenn sie unabhängig deployen. Die Zuständigkeiten klären, und die Architektur folgt.

KI bringt in Enterprise-Kontexten echte Hebelwirkung in etwa drei Bereichen: wo Urteilsentscheidungen bislang zu teuer waren, um sie in grossem Massstab zu treffen; wo Muster in Daten stecken, die Menschen im Arbeitsgedächtnis nicht halten können; und wo Teams Entwicklungszyklen beschleunigen, die diszipliniert damit umgehen, was sie einem Modell überlassen und was sie selbst prüfen. Zuverlässig keine Hebelwirkung bringt KI dort, wo die Antwort einem Regulierer gegenüber erklärbar sein muss, wo die Trainingsdaten eine Welt widerspiegeln, die nicht mehr existiert, oder wo das Team nicht die Kapazität hat, das Gebaute zu warten. Das Urteil, das dabei gefragt ist, ist dasselbe wie bei jeder anderen Architekturentscheidung: den Unterschied zu kennen zwischen einem Problem, das dieses Werkzeug wirklich löst, und einem Problem, das nur so aussieht, bis es das nicht mehr tut.

Die wertvollste Fähigkeit, die ich mitbringe, ist nicht die Wahl zwischen Frameworks oder der Entwurf einer Microfrontend-Shell. Es ist: in eine Plattform mit 200 aktiven Mitwirkenden einzusteigen, den Reibungspunkt innerhalb einer Woche zu verstehen und Entscheidungen zu treffen, die sechs Monate später noch standhalten.

Ich spreche dieselbe Sprache wie UX-Designer, Produktmanager und Ingenieure. Das ist selten und es ist wichtig. Die meisten Architekturprobleme liegen an den Nahtstellen zwischen diesen Disziplinen. Wer in allen drei zuhause ist, kann Lücken überbrücken, die andere nicht einmal sehen.

Ich habe genug falsche Entscheidungen getroffen, um den Unterschied zwischen einer Überzeugung und einer Vermutung zu kennen. Wenn ich sicher bin, sage ich es. Wenn nicht, sage ich das auch.

Wie ich hierher gekommen bin

Ich habe mit einer Berufsausbildung als Fachinformatiker bei Hewlett-Packard begonnen, dann Digitale Medien an der Hochschule Furtwangen studiert. Meine ersten Berufsjahre verbrachte ich bei frog (globale Design-Beratung), Jung von Matt/Neckar (kreatives Studio) und Intuity Media Lab (Innovationsstudio), wo ich Plattformen und native interaktive Prototypen (iOS, Android, Web) für Kunden wie Walt Disney Parks, Crytek, Walter AG und Mercedes-Benz aufgebaut habe. Diese drei Unternehmen haben mein kritisches Denken, meine fächerübergreifende Zusammenarbeit und mein Hands-on-Vorgehen geprägt.

Ich bin unabhängig geworden, weil die Probleme, die ich am besten löse, dort liegen, wo UX auf Produkt und Engineering trifft. Die Architekturentscheidungen, die die User Experience beeinflussen. Die technischen Einschränkungen, die die Produktstrategie formen. Die Build-Systeme, die die Teamgeschwindigkeit bestimmen. Diese Probleme überschreiten Organisationsgrenzen. Sie von innen eines Teams zu lösen, reicht nicht. Man braucht jemanden, der über alle hinweg arbeiten kann.