Interviewfragen für Softwarearchitekten, mit ausgearbeiteten Antworten

So nutzt du diese Fragen

Architekturfragen haben selten eine einzige richtige Antwort, also hört der Interviewer darauf, wie du zu deiner kommst. Übe, die Qualitäten zu nennen, auf die du optimierst, bevor du eine Technik nennst. Bring zwei oder drei eigene Entscheidungen mit, auch eine, die sich als falsch erwiesen hat, und was du daraus gelernt hast.

Was ein Softwarearchitekt können muss

• Trade-offs und Qualitäten: Performance, Verfügbarkeit, Sicherheit, Kosten und Änderbarkeit, und wie man jede davon messbar macht.
• Struktur: modulare Monolithen, MicroservicesIn 4 % der Anzeigen für Softwarearchitekt gefragt (Stand 05.11.2026).Wissen, wann sich die Aufteilung eines Systems in Services lohnt und welche Betriebskosten sie bringt, wenn nicht., Events und die EntwurfsmusterIn 2 % der Anzeigen für Softwarearchitekt gefragt (Stand 05.11.2026).Bekannte Lösungen beim Namen nutzen, etwa Adapter, Queues oder Anti-Corruption Layer, und ihre Kosten kennen., die sie verbinden.
• Daten: wem welche Daten gehören, Konsistenz über Services hinweg und Datenbanken wie PostgreSQLIn 8 % der Anzeigen für Softwarearchitekt gefragt (Stand 05.11.2026).Eine relationale Datenbank, die viele Architekten als Standard wählen; Transaktionen, Replikate und Grenzen kennen..
• Plattformen: eine Cloud wie AWSIn 10 % der Anzeigen für Softwarearchitekt gefragt (Stand 05.11.2026).Die Bausteine der Cloud von Amazon, ihre Grenzen und ihr Preis, auf der Ebene ganzer Systeme. oder AzureIn 14 % der Anzeigen für Softwarearchitekt gefragt (Stand 05.11.2026).Die Cloud von Microsoft, in europäischen Unternehmen verbreitet; Landing Zones, Identitäten und verwaltete Dienste., Container und die Kosten dessen, was du wählst.
• Entscheidungen und Menschen: Entscheidungsprotokolle, Diagramme, Governance und Entscheidungen erklärenIn 14 % der Anzeigen für Softwarearchitekt gefragt (Stand 05.11.2026).Eine technische Wahl Menschen erklären, die keine Ingenieure sind, in Begriffen von Risiko, Zeit und Geld. gegenüber Menschen, die keine Ingenieure sind.

Trade-offs, Qualitäten und Struktur

Wie entscheidest du zwischen zwei Architekturoptionen?

Worauf sie achten: dass du nach den Bedürfnissen des Systems entscheidest und sagst, was du aufgibst.

Kurze Antwort: „Ich schreibe die Qualitäten auf, die dieses System am meisten braucht, etwa wie schnell es antworten muss, wie oft es ausfallen darf und wie schnell Teams es ändern müssen, und bewerte jede Option daran. Ich frage auch, wie schwer sich jede Wahl rückgängig machen lässt. Eine Wahl, die sich günstig umkehren lässt, treffe ich schnell; eine teure teste ich zuerst mit einem Prototyp.“

Die ausführliche Antwort: Jede Option gewinnt bei manchen Qualitäten und verliert bei anderen; so zu tun, als sei eine in allem die beste, ist der klassische Fehler. Mach den Trade-off in einer kleinen Tabelle sichtbar: die Optionen, die Qualitäten und eine kurze Notiz zu jeder. Nimm Kosten, die Skills des Teams und die Zeit bis zum Markt dazu, denn sie entscheiden mehr Projekte als die Technik. Halte dann die Entscheidung und den Grund fest, damit die nächste Person weiß, was eine Änderung rechtfertigen würde.

Schwache Antwort: „Ich nehme die modernste Technik.“ Nachfrage: „Das Team bevorzugt die Option, die du schlechter bewertet hast.“ Ist der Abstand klein, wiegen seine Skills und seine Verantwortung vielleicht schwerer; ist er groß, zeig ihm das Szenario, in dem es wehtut.

Was sind Qualitätsmerkmale, und wie machst du sie konkret?

Worauf sie achten: dass aus „schnell“ und „skalierbar“ Zahlen werden, die ein Team testen kann.

Kurze Antwort: „Qualitätsmerkmale, auf Englisch Quality Attributes, sind die Eigenschaften, die ein System neben seinen Features haben muss: Performance, Verfügbarkeit, Sicherheit, Änderbarkeit, Kosten und andere. Ich mache aus jedem ein Szenario mit einem Maß, etwa: Wenn sich der Traffic an einem Aktionstag verdoppelt, antworten neun von zehn Suchen noch innerhalb einer halben Sekunde. Dann lässt sich der Entwurf daran testen.“

Die ausführliche Antwort: Ein Szenario hat eine Quelle, einen Auslöser, den betroffenen Teil des Systems, die erwartete Reaktion und wie sie gemessen wird. Sammle sie mit dem Fachbereich, ordne sie, weil sie miteinander konkurrieren, und halte die wichtigsten sichtbar. ISO 25010, das internationale Modell für Softwarequalität, ist eine nützliche Checkliste, damit nichts Offensichtliches vergessen wird. Prüf die wichtigen automatisch, wo es geht, mit Lasttests oder Alarmen, damit das System sie auch nach dem Release einhält.

Schwache Antwort: „Es muss skalierbar und sicher sein.“ Das sagt jedes System. Nachfrage: „Verfügbarkeit und Kosten ziehen hier in entgegengesetzte Richtungen.“ Zeig, was jede zusätzliche Stufe an Verfügbarkeit kostet, und lass den Fachbereich die Stufe wählen, die er bezahlen will.

Würdest du ein neues Produkt als Monolith oder als Microservices bauen?

Worauf sie achten: dass du die Struktur an das Team und das Problem anpasst, nicht an die Mode.

Kurze Antwort: „Für ein neues Produkt mit einem oder zwei Teams fange ich meist mit einem modularen Monolithen an: eine Anwendung, die als Ganzes ausgeliefert wird, mit klaren Modulen und Grenzen im Inneren. Sie ist einfacher zu bauen, zu testen und zu betreiben. Ein Modul löse ich als eigenen Service heraus, wenn es einen konkreten Grund gibt, etwa ein Team, das eigenständig releasen muss, oder einen Teil mit ganz anderer Last.“

Die ausführliche Antwort, in vier Punkten:

1. Was Microservices bringen. Teams, die unabhängig releasen, Teile, die für sich skalieren, und Ausfälle, die begrenzt bleiben.
2. Was sie kosten. Netzwerkaufrufe, die fehlschlagen können, Daten verteilt auf viele Speicher, Distributed Tracing, mehr Pipelines und Menschen, die die Plattform betreiben. Ein kleines Team zahlt diese Kosten ohne den Nutzen.
3. Zuerst die Grenzen. Schneide entlang der fachlichen Fähigkeiten, etwa Bestellungen, Zahlungen und Lager, nicht entlang technischer Schichten. Eine falsche Grenze in einem Monolithen lässt sich günstig verschieben; zwischen Services ist es teuer.
4. Der Weg zurück. Wurden Services zu früh getrennt, ist es eine berechtigte Entscheidung, einige wieder zusammenzulegen, kein Scheitern.

Schwache Antwort: „Microservices, weil moderne Firmen so arbeiten.“ Nachfrage: „Der Monolith ist auf acht Teams gewachsen, die sich gegenseitig blockieren.“ Such das Modul mit den unabhängigsten Änderungen und den klarsten Daten und löse es zuerst heraus.

Wann ist eventgetriebenes Design die richtige Wahl, und was kostet es?

Worauf sie achten: dass du die Entkopplung kennst und auch die Komplexität, die Events mitbringen.

Kurze Antwort: „Eventgetriebenes Design heißt, Services melden, was passiert ist, etwa ‚Bestellung aufgegeben‘, und andere reagieren in ihrem eigenen Tempo, statt sich direkt aufzurufen. Es passt, wenn viele Teile auf dieselbe Änderung reagieren müssen, wenn der Sender nicht warten soll oder wenn eine Historie der Änderungen nützlich ist. Der Preis: Das System ist nur letztlich konsistent (eventual consistency) und schwerer nachzuvollziehen.“

Die ausführliche Antwort: Ein Log wie KafkaEin Event-Log, das viele Services in ihrem eigenen Tempo lesen; Reihenfolge, Aufbewahrung und Replay kennen. hält Events vor, damit Consumer in ihrem eigenen Tempo lesen und sie erneut abspielen können; ein Broker wie RabbitMQEin Message Broker für Arbeitsqueues und Befehle zwischen Services. passt zu Arbeitsqueues. Entwirf für Nachrichten, die doppelt oder in falscher Reihenfolge ankommen: Consumer müssen idempotent sein, das heißt, dasselbe Event zweimal zu verarbeiten, schadet nicht. Muss ein Service seine Datenbank ändern und zugleich ein Event veröffentlichen, schreibt das Outbox Pattern beides in einer Transaktion und veröffentlicht danach. Investiere früh in Tracing, sonst kann niemand eine Anfrage durch die Kette verfolgen.

Schwache Antwort: „Events machen alles lose gekoppelt.“ Sie verstecken die Kopplung im Format des Events. Nachfrage: „Ein Team will das Format eines Events ändern, das fünf Services lesen.“ Versioniere das Event, veröffentliche eine Zeit lang beide Versionen und vereinbare ein Datum, an dem die alte ausläuft.

Daten, APIs und Ausfälle

Wem gehören in einem System aus Services welche Daten?

Worauf sie achten: Datenhoheit, der häufigste Grund, warum Entwürfe aus Services scheitern.

Kurze Antwort: „Jedes Stück Daten hat einen Eigentümer, den Service, der für diesen Teil des Geschäfts zuständig ist, und nur dieser Service schreibt es. Andere fragen den Eigentümer über seine API oder halten eine Kopie, die aus seinen Events aktualisiert wird. Zwei Services, die in dieselben Tabellen schreiben, sind keine getrennten Services; sie sind ein Monolith mit Netzwerkaufrufen.“

Die ausführliche Antwort: Zeichne die fachlichen Fähigkeiten und die Daten, die jede für ihre Arbeit braucht. Wo zwei dieselben Daten schreiben wollen, sitzt die Grenze an der falschen Stelle. Kopien sind in Ordnung, wenn alle wissen, welche die Wahrheit ist und wie veraltet eine Kopie sein darf. Berichte, die alles brauchen, lesen aus einem eigenen Analysespeicher, der aus Events gefüllt wird, nicht aus den Datenbanken der Services. Bei personenbezogenen Daten entscheidet die Datenhoheit auch, wer eine Löschanfrage nach der DSGVO (EU) beantwortet.

Schwache Antwort: „Sie teilen sich alle eine Datenbank, also sind die Daten immer konsistent.“ Nachfrage: „Ein Prozess muss Bestellungen und Zahlungen zusammen ändern.“ Nutze eine Saga: eine Folge lokaler Schritte, jeder mit einem Rückgängig-Schritt, falls ein späterer fehlschlägt, statt einer Transaktion über Services hinweg.

Wie entwirfst du eine API, von der viele andere Teams abhängen werden?

Worauf sie achten: Verträge, die halten und sich ändern lassen, ohne Consumer zu brechen.

Kurze Antwort: „Ich entwerfe sie aus den Bedürfnissen der Consumer, nicht aus den Datenbanktabellen, vereinbare den Vertrag schriftlich vor dem Bau und plane für Änderungen: Erweiterungen, die niemanden brechen, Versionierung für die Änderungen, die es tun, und eine Deprecation-Frist mit Terminen. Fehler sagen dem Aufrufer, was schiefging und was er tun soll.“

Die ausführliche Antwort: REST-APIsIn 8 % der Anzeigen für Softwarearchitekt gefragt (Stand 05.11.2026).APIs entwerfen, von denen andere Teams abhängen: klare Ressourcen, Versionierung und Fehler, die sagen, was schiefging. passen zu Ressourcen mit klarer Identität; GraphQLIn 5 % der Anzeigen für Softwarearchitekt gefragt (Stand 05.11.2026).Ein API-Stil, bei dem der Client genau die Felder anfragt, die er braucht; nützlich für viele Frontends. passt zu vielen Frontends, die jeweils andere Felder brauchen; Events passen zu Benachrichtigungen. Egal welcher Stil: Veröffentliche eine Spezifikation, teste in der Pipeline dagegen und miss, wer was aufruft, damit du weißt, wen eine Änderung trifft. Setz Grenzen für Rate und Größe von Anfang an; sie später einzuführen, bricht Aufrufer.

Schwache Antwort: „Wir ändern sie, wenn wir es brauchen.“ Nachfrage: „Ein großer Kunde hängt an einem Feld, das du entfernen musst.“ Behalte es, markiere es als deprecated, hilf ihm beim Umstieg und entferne es erst nach dem vereinbarten Datum.

Wie entwirfst du ein System, das weiterläuft, wenn Teile davon ausfallen?

Worauf sie achten: Verfügbarkeit als Qualität des Entwurfs, eingebaut statt erhofft.

Kurze Antwort: „Ich gehe davon aus, dass jeder Aufruf über das Netz langsam sein oder fehlschlagen kann. Jeder Aufruf bekommt ein Timeout und begrenzte Wiederholungen mit Pause, ein Circuit Breaker hört auf, einen Service aufzurufen, der immer wieder ausfällt, und jedes Feature hat einen Fallback, etwa zwischengespeicherte Preise anzeigen. Kritische Teile laufen in mehr als einer Zone, und wir testen Ausfälle mit Absicht.“

Die ausführliche Antwort: Leg zuerst fest, wie verfügbar jeder Teil sein muss: Der Checkout braucht vielleicht weit mehr als das Feld mit Empfehlungen. Trenne Teile so, dass eine langsame Abhängigkeit nicht alle Threads oder Verbindungen aufbrauchen kann, eine Idee namens Bulkheads. Queues fangen Spitzen ab. Beobachte die Zeichen, die Nutzer spüren, etwa Fehlerraten und Antwortzeiten, mit Alarmen. Übe: Schalte in einer Testumgebung eine Abhängigkeit ab und sieh, was Nutzer sehen würden.

Schwache Antwort: „Der Cloud-Anbieter garantiert die Verfügbarkeit.“ Er garantiert seinen Teil, nicht deinen Entwurf. Nachfrage: „Wiederholungen haben einen Ausfall verschlimmert.“ Wiederholungen ohne Grenzen und Pausen vervielfachen die Last auf einem angeschlagenen Service; nimm Backoff dazu, ein Budget für Wiederholungen und einen Circuit Breaker.

Entscheidungen auf Papier, Kosten und Altsysteme

Wie hältst du Architekturentscheidungen fest?

Worauf sie achten: dass Entscheidungen und ihre Gründe es überleben, wenn Menschen gehen.

Kurze Antwort: „Mit Architecture Decision Records, kurz ADRs: eine Seite pro wichtiger Entscheidung, mit dem Kontext, den Optionen, der Entscheidung und den Folgen, die wir akzeptieren. Sie liegen neben dem Code, werden wie Code geprüft und nachträglich nie geändert; ein neuer ADR ersetzt einen alten.“

Die ausführliche Antwort: Der Wert eines ADR ist das Warum. Ein Jahr später fragt jemand, warum das System hier eine Queue nutzt; der Eintrag sagt, was damals bekannt war und was heute eine Änderung rechtfertigen würde. Halte sie kurz, höchstens eine Seite, und schreib sie, wenn die Entscheidung fällt, nicht am Ende des Projekts. Nicht jede Wahl braucht einen: Schreib sie für Entscheidungen, die teuer umzukehren sind oder von denen andere Teams abhängen.

Schwache Antwort: „Die Entscheidungen stehen im Protokoll der Besprechung.“ Nachfrage: „Niemand liest sie.“ Verlinke sie aus dem Code und den Diagrammen und verweise in Design-Reviews auf sie, bis die Leute es tun.

Wie dokumentierst du eine Architektur so, dass Menschen sie wirklich nutzen?

Worauf sie achten: Diagramme für die Leser, nicht für den Architekten.

Kurze Antwort: „Ich nutze das C4-Modell: vier Ebenen von Diagrammen, vom Kontext, dem System mit seinen Nutzern und Nachbarn, zu den Containern, den auslieferbaren Teilen, zu den Komponenten in einem Container und nur selten bis zum Code. Die meisten Leser brauchen die ersten beiden. Jedes Diagramm hat einen Titel, eine Legende und ein Datum und liegt beim Code.“

Die ausführliche Antwort: Ein Diagramm beantwortet einem Leser eine Frage: Eine Managerin will wissen, was das System tut und wer es nutzt; ein neuer Engineer will wissen, wo er eine Änderung macht. Zeichne für diese Frage und lass den Rest weg. Halte Diagramme in einem Format, das sich prüfen und versionieren lässt, und ändere sie in derselben Änderung wie das System. Nimm die Entscheidungsprotokolle und die Qualitätsszenarien dazu, und du hast das meiste, was ein Team braucht. Im deutschsprachigen Raum ist dafür auch arc42 verbreitet, eine Vorlage für die Dokumentation von Softwarearchitekturen.

Schwache Antwort: ein riesiges Diagramm mit jedem Kasten und jeder Linie der Firma. Nachfrage: „Die Diagramme sind veraltet.“ Lösch die, die niemand nutzt, erzeuge, was geht, aus dem laufenden System und mach die Aktualisierung zum Teil der Definition of Done.

Wie bringst du Kosten in Architekturentscheidungen ein?

Worauf sie achten: dass Kosten ein Qualitätsmerkmal sind wie die anderen, entworfen und gemessen.

Kurze Antwort: „Ich schätze die laufenden Kosten jeder Option bei der heutigen Last und bei der Last, die wir erwarten, nicht nur die Kosten für den Bau. In der Cloud entscheidet der Entwurf über die Rechnung: Server, die immer laufen, oder Bezahlung nach Nutzung, Daten, die zwischen Regionen wandern, Managed Services oder eigene. Ich mache die Kosten je Team oder Produkt sichtbar, damit die Menschen, die entscheiden, auch die Rechnung sehen.“

Die ausführliche Antwort: Kosten verstecken sich im Traffic zwischen Zonen und Regionen, in Logs, die niemand liest, in Testumgebungen, die weiterlaufen, und in überdimensionierten Datenbanken. Versieh jede Ressource mit einem Eigentümer. Managed Services kosten pro Einheit mehr, sparen aber Personal; rechne beides. Schau dir die großen Posten jedes Quartal neu an, weil sich Last und Preise ändern. Manchmal ist der günstigste Entwurf der, der sich am einfachsten betreiben lässt.

Schwache Antwort: „Um die Cloud-Rechnung kümmert sich die Finanzabteilung.“ Nachfrage: „Die Rechnung hat sich nach einem Release verdoppelt.“ Finde heraus, welcher Service und welcher Posten gewachsen ist, vergleiche mit dem Traffic und schau zuerst auf Datenübertragung und Logging.

Wie würdest du ein großes Altsystem migrieren, ohne das Geschäft anzuhalten?

Worauf sie achten: einen sicheren Plan in Schritten für die häufigste Architektenaufgabe überhaupt.

Kurze Antwort: „Schritt für Schritt, nie in einer großen Umstellung. Ich setze eine Fassade vor das alte System und verlagere dann eine Fähigkeit nach der anderen in das neue dahinter; der Traffic geht an den neuen Teil, sobald er bereit ist. Das nennt man das Strangler Fig Pattern. Jeder Schritt ist klein genug, um ihn rückgängig zu machen, und das alte System schrumpft, bis es sich abschalten lässt.“

Die ausführliche Antwort, in fünf Schritten:

1. Verstehen. Erfasse, was das Altsystem wirklich tut, auch die Regeln, die nie jemand aufgeschrieben hat. Sprich mit den Menschen, die es betreiben, und lies die Daten, nicht nur die Dokumente.
2. Die erste Scheibe wählen. Eine Fähigkeit, die wertvoll, recht eigenständig und nicht die riskanteste ist, damit das Team an ihr lernt.
3. Umleiten. Eine Fassade oder die API-Schicht schickt Anfragen für diese Fähigkeit an den neuen Code und den Rest an das alte System.
4. Die Daten abgleichen. Eine Zeit lang brauchen beide Seiten die Daten; leg für jedes Element fest, welche Seite die Wahrheit ist, und halte die andere im Gleichschritt, oft mit Events.
5. Abschalten. Schalte jeden alten Teil ab, sobald ihn nichts mehr nutzt, sonst bezahlt die Firma für immer zwei Systeme.

Schwache Antwort: „Von Grund auf neu schreiben und an einem Wochenende umstellen.“ Große Neuentwicklungen werden zu spät fertig und übersehen versteckte Regeln. Nachfrage: „Der Fachbereich will während der Migration neue Features.“ Bau sie im neuen System, das zieht die Migration nach vorn, statt sie zu bremsen.

Governance und Menschen außerhalb der Entwicklung

Wie setzt du Architektur-Governance auf, ohne Teams zu bremsen?

Worauf sie achten: Leitplanken, die ein System stimmig halten, während Teams schnell vorankommen.

Kurze Antwort: „Ich halte die Regeln wenige und klar: die Entscheidungen, denen jedes Team folgen muss, etwa wie sich Services authentifizieren und wem Daten gehören, und Freiheit für den Rest. Wo es geht, werden die Regeln automatisch in der Delivery-PipelineIn 23 % der Anzeigen für Softwarearchitekt gefragt (Stand 05.11.2026).Auslieferungspipelines, die kleine, häufige und umkehrbare Releases möglich machen; die Architektur hängt von ihnen ab. geprüft, damit niemand auf eine Sitzung wartet. Review-Boards schauen nur auf die Entscheidungen, die teuer umzukehren sind oder viele Teams betreffen.“

Die ausführliche Antwort: Governance scheitert auf zwei Arten: keine Regeln, und das System zerfällt in viele unverträgliche Teile; zu viele Regeln, und Teams umgehen sie. Veröffentliche Prinzipien mit Beispielen, eine kurze Liste freigegebener Techniken mit einem Weg, neue vorzuschlagen, und Fitness Functions: automatische Prüfungen, dass eine Qualität noch gilt, etwa dass kein Service die Datenbank eines anderen aufruft. Miss die Lead Time; bremst die Governance die Releases, repariere die Governance.

Schwache Antwort: „Jeder Entwurf geht ins Architektur-Board.“ Nachfrage: „Ein Team hat den Standard ignoriert und ausgeliefert.“ Finde heraus, warum; passte der Standard nicht, ändere ihn; passte er, hilf dem Team, es zu beheben, und mach die Prüfung automatisch.

Wie erklärst du eine Architekturentscheidung Menschen, die keine Ingenieure sind?

Worauf sie achten: dass Menschen aus dem Geschäft dir folgen und mit dir entscheiden können.

Kurze Antwort: „Ich fange bei dem an, was ihnen wichtig ist: Zeit, Geld, Risiko und Kunden. Statt ‚Wir teilen den Monolithen auf‘ sage ich ‚Releases kommen künftig wöchentlich statt monatlich, und ein Ausfall der Suche hält den Checkout nicht mehr an; es kostet zwei Teams ein Quartal‘. Ein einfaches Bild, die Optionen mit ihren Folgen und eine klare Empfehlung.“

Die ausführliche Antwort: Nicht-Techniker brauchen nicht die Technik; sie brauchen die Folgen und die Wahl. Nutze ihre Wörter und ihre Zahlen. Biete zwei oder drei Optionen an, auch die, nichts zu tun, mit dem, was jede kostet und riskiert. Sag, wo du unsicher bist. Schick danach eine kurze schriftliche Zusammenfassung, damit die Entscheidung in einer Sprache festgehalten ist, der sie zugestimmt haben.

Schwache Antwort: eine Folie voller Kästen und Abkürzungen. Nachfrage: „Der CFO fragt, warum es so viel kostet.“ Zerleg die Kosten in das, was sie kaufen, und zeig die Kosten, es nicht zu tun, etwa Ausfälle oder langsamere Releases.

Principal, Enterprise und Chief Architect

Diese Fragen kommen für Rollen als Senior und Principal Architect, Enterprise Architect und Chief Architect und auf dem Weg zum CTO.

Wie führst du als Principal Architect viele Teams, die du nicht leitest?

Worauf sie achten: Einfluss ohne Weisungsbefugnis, der Kern der Arbeit als Senior-Architekt.

Kurze Antwort: „Über eine gemeinsame Richtung, an der die Teams mitgeschrieben haben, kurze Prinzipien, die sie allein anwenden können, und indem ich nützlich bin: Ich prüfe ihre schwierigsten Entwürfe, räume Hindernisse aus dem Weg und baue die gemeinsamen Teile, die niemandem gehören. Ich verbringe Zeit mit den Teams, nicht nur in Boards. Wenn ich Nein sagen muss, erkläre ich den Grund und biete einen anderen Weg an.“

Die ausführliche Antwort: Ein Principal Architect gewinnt Vertrauen mit guten Entscheidungen und behält es, indem er zuhört. Schreib eine Zielarchitektur für das nächste Jahr oder die nächsten zwei, mit den Schritten dorthin, und schau sie jedes Quartal neu an. Entwickle andere Architekten und Senior Engineers, damit Entscheidungen nicht auf dich warten. Miss das Ergebnis in den Begriffen der Teams: weniger Blockaden zwischen Teams, schnellere Releases, weniger Incidents.

Schwache Antwort: „Die Teams müssen der Architektur folgen.“ Nachfrage: „Zwei erfahrene Teams sind mit deiner Richtung nicht einverstanden.“ Hol sie in einen Raum, vergleiche die Optionen an den vereinbarten Qualitäten und entscheide; halte die Entscheidung in jedem Fall fest.

Wie verbindest du als Enterprise oder Chief Architect die Technik mit der Strategie des Geschäfts?

Worauf sie achten: an der Spitze der Leiter einen Technikplan, den die Geschäftsleitung als ihren eigenen trägt.

Kurze Antwort: „Ich gehe von der Strategie aus und stelle die fachlichen Fähigkeiten, die sie braucht, etwa online in neuen Ländern verkaufen, den Systemen gegenüber, die sie heute stützen. Die Lücken und Risiken werden zu einer Roadmap aus wenigen großen Schritten, jeder mit Kosten und einem Nutzen, den die Geschäftsleitung versteht. Ich gehe sie jedes Quartal mit ihr durch.“

Die ausführliche Antwort: Ein Enterprise Architect schaut über alle Systeme: welche bleiben, ersetzt, zusammengelegt oder abgeschaltet werden und wo doppelte Systeme Geld kosten. Frameworks wie TOGAF geben eine gemeinsame Methode; eine Capability Map, eine Landkarte der fachlichen Fähigkeiten, gibt ein gemeinsames Bild. Der Chief Architect legt außerdem die Standards und die Architekturpraxis fest und arbeitet mit dem CTO an Make or Buy, Lieferanten und technischen Risiken. Vor allem muss der Plan etwas sein, das das Geschäft finanziert, kein Dokument im Regal.

Schwache Antwort: „Ich sorge dafür, dass alle Projekte unseren Standards folgen.“ Nachfrage: „Die Geschäftsleitung will das IT-Budget kürzen.“ Zeig, welche Systeme abgeschaltet oder zusammengelegt werden könnten und welches Risiko jede Kürzung hinzufügen würde.

Dein Lebenslauf für diese Fragen

Ein Architekten-Interview prüft jede Entscheidung, die in deinem Lebenslauf steht; schreib also die Zeilen, die die Antworten oben vorbereiten. Setz jede unter den Job, in dem du es getan hast:

Wenn du deinen Lebenslauf an einem echten Job als Softwarearchitekt bewertest, siehst du, welche Entscheidungen diesem Arbeitgeber wichtig sind und wo deinen Zeilen noch Belege fehlen.