Ich bin Ronan und leite die Abteilung für Quantensoftwareentwicklung bei Equal1. Wir entwickeln und bauen vollintegrierte Quantencomputer mit fortschrittlicher Spin-Technologie. Equal1 hat Niederlassungen in Irland, den USA, Kanada, Japan, Rumänien und den Niederlanden, wo ich lebe. Zuvor war ich bei Qblox tätig, einem Unternehmen, das Quantenkontrollsysteme herstellt.
Bei Equal1 konzentriere ich mich auf den Aufbau des Komplettsystems, das unseren Hochleistungs-Quantencomputer RacQ betreibt. Dieses System ist für Tausende von logisch korrigierten Qubits und mehr ausgelegt. Es wird auch als das „Gehirn“ von Quantenprozessoren (QPUs) bezeichnet.
Ich finde meine Arbeit faszinierend, weil ich jeden Tag etwas Neues lerne und mit tollen, kompetenten Kollegen zusammenarbeite. Ich habe diesen Blog gestartet, um meine Erfahrungen zu teilen – natürlich ohne Geheimnisse preiszugeben!
Sie können mir gerne eine E-Mail an ronan Oder vernetzen Sie sich mit mir auf LinkedIn, wenn Sie mehr erfahren möchten!
***Disclaimer: While I work at Equal1 by the day, this blog is a personal project and does not reflect the views of my employer. The thoughts, ramblings, and opinions shared here are mine alone and haven’t been vetted, approved or modified by anyone but myself.
***Bei Qblox war ich als Systemarchitekt tätig. Nachfolgend finden Sie eine Zusammenfassung meiner damaligen Tätigkeit.
Diese Frage wird mir häufig gestellt: Was genau wird von einem Systemarchitekten erwartet? Die Antwort variiert je nach Unternehmen, Land und Branche. Ein Konzept bleibt jedoch konstant: Kommunikation
Ja, die Aufgabe des Architekten besteht darin, komplexe Ideen einfach zu vermitteln – sei es an Entwicklungs- und Ingenieurteams, Führungskräfte oder Kunden. Es beginnt damit, gemeinsam mit dem Kunden und dem Produktteam das Problem zu verstehen. Und genau das ist der spannende Teil der Aufgabe: eine Lösung zu entwickeln, die den Kunden zufriedenstellt!
Darauf folgt die klassische Systemanforderungsanalyse und oft auch eine Prototyping-Phase zum Machbarkeitsnachweis, in der ich in der Regel aktiv mitarbeite. Anschließend folgt die Produktentwicklung, in der ich als technischer Leiter mit interdisziplinären Teams zusammenarbeite, bis das Produkt fertig ist. Abschließend kümmert ich mich um den Kundenservice nach der Markteinführung.
Wie treffe ich eine Architekturentscheidung? Die Rolle des Architekten besteht nicht unbedingt darin, die Entscheidung zu treffen, sondern vielmehr darin, das Problem zu formulieren, indem er die für eine Entscheidung notwendigen Informationen zusammenführt. Zum Beispiel vom Produktteam („*Was kostet die Entwicklung dieses neuen Produkts? Wie lange dauert die Markteinführung?“) oder vom CxO-Team („*Wollen wir in diese neue Technologie investieren? Wie hoch ist der ROI und welche langfristige Strategie verfolgt man?“).
Es geht darum, sachlich und unvoreingenommen die Vor- und Nachteile jeder möglichen Lösung zu recherchieren und zu definieren. Es geht auch darum, Kosten und Nutzen abzuwägen und dabei nicht nur den Implementierungsaufwand, sondern auch die langfristigen Wartungs- und Betriebskosten sowie die kognitive Belastung des Teams zu berücksichtigen.
Noch wichtiger ist jedoch die Aushandlung sozialer Übereinstimmung, denn jede Architekturentscheidung, die Entwickler ablehnen oder Produktmanager nicht verstehen, wird scheitern. Eine Entscheidung zu treffen bedeutet, alle Beteiligten in den Entscheidungsprozess einzubeziehen. Im Produkt- und Geschäftsprozess muss sichergestellt werden, dass die Wahl einen Mehrwert für das Unternehmen bietet. Im Entwicklungsprozess sollte Feedback von erfahrenen Entwicklern eingeholt werden, damit diese die Umsetzung mittragen.
Dies ist eine immer wiederkehrende Frage für alle Unternehmen mit Softwareprodukten: Warum und wann sollten wir refaktorisieren? Häufig wird angenommen, dass es Zeit für eine Refaktorisierung ist, wenn bestehende Produkte langsam und instabil sind und die Behebung der Probleme aufgrund der angehäuften technischen Schulden zu viel Zeit in Anspruch nimmt. Doch die Antwort ist nicht immer die richtige; vielmehr ist es die Aufgabe des Architekten, den sogenannten „Second-System-Effekt“ zu verhindern.
Meine persönliche Philosophie ist es, Entscheidungen, die auf der Basis von day-1 getroffen wurden, anhand des „Zwei-Wege-Tür-Tests“ zu überprüfen: Handelt es sich bei der Refaktorisierung um eine Einbahnstraße (nahezu unmöglich rückgängig zu machen, wie die Wahl eines primären Datenbankparadigmas) oder um eine Zwei-Wege-Tür (die später leicht geändert werden kann, wie die Wahl einer internen Bibliothek)? Einbahnstraßen erfordern eine gründliche Validierung; Zwei-Wege-Türen erfordern Schnelligkeit.
Auf den ersten Blick besteht die Rolle des Systemarchitekten auch darin, sich für die richtige Ingenieurskultur einzusetzen, die sowohl für die Entwicklungsteams (weniger Krisenmanagement) als auch für die Produktteams (schnellere Markteinführung) einen Mehrwert schafft.
Die Grundidee ist zwar, jetzt in den Engineering-/Software-Stack zu investieren, um später in der Entwicklung Zeit zu sparen, die eigentliche Herausforderung besteht jedoch darin, das richtige Gleichgewicht zwischen Investition und Überentwicklung zu finden: die richtigen Werkzeuge und Softwarekomponenten zu entwickeln, um die Produktentwicklung und -wartung zu vereinfachen, anstatt etwas zu überentwickeln, das keinen Mehrwert bietet.
Dies bedeutet auch, dass der Architekt häufig mit den Produkt- und C-Level-Teams kommunizieren muss, um die Arbeit der Teams zu fördern, die ihre Anstrengungen in eine zukunftssichere Entwicklung investieren, anstatt ständig Brände zu löschen.
Irgendwann reicht eine bloße Systemrefaktorisierung nicht mehr aus, denn dann greift das Conwaysche Gesetz: „Jede Organisation, die ein System entwirft, wird ein Design hervorbringen, dessen Struktur eine Kopie der Kommunikationsstruktur der Organisation ist.“
Die Lösung besteht nicht immer in einer Umstrukturierung der Teams, sondern vielmehr darin, die Teamleistung an der Unternehmensorganisation auszurichten, sodass das Ergebnis beider Teams mehr ist als die Summe seiner Einzelteile. Wenn ein Team aufgrund ineffizienter Kommunikationsstrukturen nicht genügend Wertschöpfung generiert, sollte ein System geschaffen werden, in dem die Teamleistung durch bessere Komponenten und API-Versprechen definiert wird, die dem Unternehmen einen höheren Mehrwert bieten. Und wenn das Team keine neuen Komponenten entwickeln kann, sollte die Arbeit in einfachere Komponenten mit direkteren API-Versprechen aufgeteilt werden.
Aber viel wichtiger ist, dass es hier um die soziale Ausrichtung des Teams und der Organisation geht: Stellen Sie sich ein Unternehmen vor, in dem sich das Team selbst verändert, um mehr Wert zu schaffen. Wäre das nicht die ideale Situation?
Wie hat KI meine Arbeitsweise verändert? Sehr stark! So wie Entwickler Vibe-Coding betreiben, müssen Architekten besser darin werden, Vibe-Designs (sowie Vibe-Systemanforderungen) zu schreiben, die direkt in LLMs als Eingabe zur Codeerzeugung verwendet werden können.
KI ist bei der Designiteration äußerst hilfreich, da sie schnell zahlreiche Varianten desselben Designs generieren und so eine zügigere Erkundung verschiedener Optionen ermöglichen kann. Diese Designs lassen sich anschließend schnell prototypisch umsetzen, um ihre Annahmen und die Komplexität der Entwicklung zu überprüfen.
Vor allem aber ist es wichtig zu verstehen, dass KI nicht dazu da ist, Ingenieure zu ersetzen, sondern ihre Fähigkeiten und Kreativität zu erweitern. Sie ist ein Werkzeug zur Verbesserung des Designprozesses und kein Ersatz für ingenieurtechnisches Urteilsvermögen und Fachwissen.
Betrachten Sie beispielsweise das folgende Diagramm: Wie viele LLMs werden Ihnen sagen, dass das Diagramm rechts einen Fehler auf Qubit 3 (Z 2 Z 3 ) zeigt, obwohl es sich tatsächlich um einen byzantinischen Fehler auf Qubit 1 und 2 handelt? (vollständige Erklärungen)
***