Interviewfragen für Enterprise Architects, mit ausgearbeiteten Antworten

So nutzt du diese Fragen

Interviewer für diese Rolle spielen oft die skeptische Führungskraft. Antworte zuerst in der Sprache des Geschäfts, also Geld, Risiko und Zeit, und hol die Frameworks nur dazu, wo sie helfen. Nenne eine echte Landschaft, an der du gearbeitet hast, was du empfohlen hast und was das Geschäft entschieden hat.

Was ein Enterprise Architect können muss

• Die Praxis: Enterprise ArchitectureDie ganze Landschaft aus Systemen, Daten und Prozessen an der Strategie des Geschäfts ausrichten und planen., von der Capability Map bis zu Roadmaps und Reviews.
• Die Sprache: TOGAFMethode und Begriffe von TOGAF nutzen, wo sie helfen, und weglassen, was die Firma nicht braucht. und ArchiMateFähigkeiten, Anwendungen und Technik in ArchiMate modellieren, so dass andere es lesen und weiterverwenden können. oder ein anderes Framework, als Werkzeug, nicht als Ziel.
• Die Ebenen: LösungsdesignLösungsentwürfe lesen und hinterfragen, damit jedes Projekt in die Zielarchitektur passt., CloudDie Cloud-Richtung der Firma festlegen: was umzieht, auf welche Plattformen, nach welchen Regeln., das ERP-System und die Daten, gut genug, um Projekte zu beurteilen.
• Die Menschen: Führungskräfte und FachbereicheVorstand, Fachbereiche und IT-Leitung für eine Roadmap gewinnen, die sie finanzieren und der sie folgen. und der WandelDen Wandel für Menschen und Prozesse planen, den jede neue Landschaft mit sich bringt., den jede Roadmap mit sich bringt.

Die Repository-Werkzeuge stehen in Anzeigen gleichrangig nebeneinander, und keines ist Pflicht: LeanIX, Ardoq, Bizzdesign und MEGA HOPEX halten die Landschaft fest, Archi bearbeitet ArchiMate-Modelle kostenlos. Interviewern ist wichtiger, ob die Leute dem Repository trauen und es nutzen, als welches Werkzeug es ist.

Capabilities, Zielbild und Portfolio

Was ist eine Business Capability, und wie baust du mit dem Geschäft eine Capability Map?

Worauf sie achten: das Rückgrat der meisten Arbeit in der Enterprise Architecture.

Kurze Antwort: „Eine Business Capability, eine fachliche Fähigkeit, ist etwas, das das Geschäft können muss, etwa Preise festlegen oder Kunden aufnehmen, unabhängig davon, wer es tut oder welches System es stützt. Eine Capability Map zeigt sie auf einer Seite in zwei oder drei Ebenen. Ich baue sie in Workshops mit den Fachbereichen, nicht in der IT, und hänge dann die Anwendungen und ihre Probleme daran.“

Die ausführliche Antwort: Fähigkeiten ändern sich langsam, Organisationen oft; deshalb bleibt die Map auch nach einer Umorganisation nützlich.

Schwache Antwort: „Das ist eine Liste unserer Abteilungen.“ Nachfrage: „Zwei Bereiche beanspruchen dieselbe Capability.“ Sag, wie du das klärst.

Wie beschreibst du eine Zielarchitektur und die Roadmap dorthin?

Worauf sie achten: dass du aus einer Strategie Schritte machst.

Kurze Antwort: „Die Zielarchitektur ist die Landschaft, die wir in drei bis fünf Jahren haben wollen, beschrieben nach Capabilities: welche Plattformen, welche Daten, welche Integration und was wegfällt. Die Roadmap ist die Reihenfolge der Änderungen dorthin, jede mit ihrem Business Case, ihren Abhängigkeiten und einem Verantwortlichen, das erste Jahr im Detail und der Rest in Umrissen.“

Die ausführliche Antwort: Ein Zielbild, das niemand finanziert, ist eine Zeichnung; knüpf jeden Schritt an eine Entscheidung über Budget.

Schwache Antwort: „Wir beschreiben den Idealzustand.“ Nachfrage: „Die Strategie hat sich nach sechs Monaten geändert.“ Sag, was du änderst.

Wie bewertest du das Anwendungsportfolio und entscheidest, was abgelöst wird?

Worauf sie achten: eine Bereinigung, die echtes Geld spart.

Kurze Antwort: „Das Anwendungsportfolio ist jede Anwendung, die die Firma betreibt, mit Verantwortlichem, Nutzern, Kosten, technischem Zustand und den Capabilities, die sie stützt. Ich bewerte jede nach fachlichem Wert und technischer Eignung; niedrig bei beidem heißt: Kandidat zum Ablösen, hoher Wert, aber schwache Eignung: Kandidat zum Erneuern. Bereinigen heißt, nach dieser Liste zu handeln, eine Entscheidung nach der anderen.“

Die ausführliche Antwort: Um eine Anwendung abzulösen, müssen ihre Daten und ihre letzten Nutzer umziehen; plane das, sonst lebt das System in einer Ecke weiter.

Schwache Antwort: „Wir führen alle Anwendungen in einer Tabelle.“ Nachfrage: „Jeder Verantwortliche sagt, seine Anwendung sei kritisch.“ Sag, wie du entscheidest.

Wie machst du technische Schulden für die Menschen sichtbar, die die Arbeit finanzieren?

Worauf sie achten: dass du über Technik in der Sprache des Geschäfts sprichst.

Kurze Antwort: „Technische Schulden sind die zusätzlichen Kosten und Risiken, die eine Firma wegen Abkürzungen und alternder Technik trägt. Ich zeige sie nach Capabilities: welche auf Systemen ohne Support stehen, was es kostet, sie zu halten, und welche Störungen oder Verzögerungen sie verursacht haben. Dann schlage ich vor, was zuerst behoben wird und was das freisetzt.“

Die ausführliche Antwort: Führungskräfte entscheiden über Risiko und Geld; eine Liste alter Versionsnummern entscheidet nichts.

Schwache Antwort: „Alles Alte sollte ersetzt werden.“ Nachfrage: „Dieses Jahr ist Budget für eine einzige Behebung da.“ Sag, welche und warum.

Prinzipien, Standards und das Architekturboard

Wie setzt du ein Architekturboard auf, das hilft, statt zu bremsen?

Worauf sie achten: eine Governance, die Teams akzeptieren.

Kurze Antwort: „Ein Architekturboard ist eine regelmäßige Runde, in die Projekte Entscheidungen bringen, die die Landschaft berühren. Ich halte es klein, veröffentliche, was es prüft und warum, antworte innerhalb von Tagen und lasse Teams alles entscheiden, was innerhalb ihrer eigenen Lösung bleibt. Der größte Teil seiner Arbeit ist früher Rat, keine späte Freigabe.“

Die ausführliche Antwort: Miss das Board daran, wie schnell es antwortet und wie oft Projekte von sich aus früh kommen.

Schwache Antwort: „Jedes Projekt braucht unsere Freigabe.“ Nachfrage: „Ein Projekt ist live gegangen, ohne zu fragen.“ Sag, was du tust.

Welche Architekturprinzipien würdest du zuerst schreiben, und wie sorgst du dafür, dass sie halten?

Worauf sie achten: Leitlinien, die echte Fälle entscheiden.

Kurze Antwort: „Wenige Prinzipien, jedes mit dem, was es bedeutet und was es kostet: erst wiederverwenden, dann kaufen, dann selbst bauen; Daten haben einen Eigentümer; Cloud-Dienste vor eigenen Rechenzentren, wo die Regeln es erlauben. Ich schreibe sie mit den Leitungen aus Fachbereichen und IT und verweise in jeder Entscheidung des Boards auf sie, damit die Leute sehen, dass sie genutzt werden.“

Die ausführliche Antwort: Ein Prinzip, gegen das niemand verstoßen kann, ist zu vage; ein gutes sagt manchmal Nein.

Schwache Antwort: „Wir folgen den üblichen Praktiken.“ Nachfrage: „Zwei Prinzipien widersprechen sich in einem Projekt.“ Sag, wie du entscheidest.

Wie legst du Technologiestandards fest, und wie schaffst du sie wieder ab?

Worauf sie achten: dass du die Landschaft einfach hältst, ohne sie einzufrieren.

Kurze Antwort: „Ich führe eine kurze Liste von Standardtechnologien je Bereich, jede markiert als bevorzugt für neue Arbeit, erlaubt oder auslaufend, mit dem Datum, an dem sie abgeschafft wird. Teams können beantragen, etwas Neues auszuprobieren; ein erfolgreicher Versuch kann zum Standard werden.“

Die ausführliche Antwort: Ein Standard ohne Enddatum bleibt für immer; die Liste dessen, was geht, ist so wichtig wie die Liste dessen, was gilt.

Schwache Antwort: „Bei uns ist alles erlaubt.“ Nachfrage: „Ein Team will ein Werkzeug, das nicht auf der Liste steht.“ Sag, was du fragst.

Wie baust du den Business Case für einen Plattformwechsel?

Worauf sie achten: Nutzen in Zahlen, die das Geschäft wiedererkennt.

Kurze Antwort: „Ich vergleiche Nichtstun mit zwei Optionen über fünf Jahre: Kosten für den Wechsel und den Betrieb, Einsparungen durch abgelöste Systeme, beseitigte Risiken und was das Geschäft dann kann, was es heute nicht kann. Ich nenne die Annahmen, zeige die Kosten einer Verzögerung und lasse die Finanzabteilung die Zahlen prüfen.“

Die ausführliche Antwort: Nenne, wer den Nutzen hat und wer die Kosten trägt; sind es verschiedene Bereiche, braucht der Business Case beide.

Schwache Antwort: „Die neue Plattform ist modern.“ Nachfrage: „Die Finanzabteilung halbiert deine Einsparungen.“ Sag, ob der Business Case dann noch trägt.

Wie nutzt du TOGAF und ArchiMate in der Praxis?

Worauf sie achten: Frameworks als Werkzeuge, nicht als Rituale.

Kurze Antwort: „Ich nutze Teile der Methode von TOGAF, etwa die Schritte von einer Vision zu einer Roadmap und die Idee eines Architektur-Repositorys, und lasse weg, was die Firma nicht braucht. ArchiMate ist eine Modellierungssprache für Sichten auf Geschäft, Anwendungen und Technik; ich nutze einen kleinen Teil davon, damit Leser aus dem Geschäft folgen können. Zachman ist eine andere Art, zu ordnen, was beschrieben wird.“

Die ausführliche Antwort: Das Repository, aktuell gehalten in einem Werkzeug wie LeanIX, Ardoq, Bizzdesign, MEGA HOPEX oder Archi, ist mehr wert als jedes einzelne Diagramm.

Schwache Antwort: „Wir folgen TOGAF vollständig.“ Nachfrage: „Die Führung findet die Diagramme zu komplex.“ Sag, was du änderst.

Fusionen, Cloud, Regulierung und Daten

Wie führst du nach einer Fusion die beiden IT-Landschaften zusammen?

Worauf sie achten: ein klassischer Fall, bei dem viel auf dem Spiel steht.

Kurze Antwort: „Zuerst die Entscheidungen des Geschäfts: welche Prozesse, Produkte und Marken weiterlaufen. Dann beide Landschaften auf eine Capability Map, eine Wahl je Capability, also das eine behalten, das andere behalten oder beide ersetzen, und eine Reihenfolge, die den Umsatz schützt, meist mit Vorsicht bei Finanzen und den Systemen für Kunden. Was ab dem ersten Tag gebraucht wird, etwa E-Mail und Reporting, kommt zuerst.“

Die ausführliche Antwort: Entscheide nach Capability und Daten, nicht danach, welche Firma welche gekauft hat; das akzeptieren die Menschen besser.

Schwache Antwort: „Die Systeme des Käufers gewinnen.“ Nachfrage: „Das CRM der kleineren Firma ist klar besser.“ Sag, was du empfiehlst.

Wie prägt Enterprise Architecture den Umzug in die Cloud?

Worauf sie achten: Strategie statt einzelner Migrationen.

Kurze Antwort: „Aus dem Anwendungsportfolio lege ich fest, was umzieht, in welcher Reihenfolge und auf welche Plattformen: ablösen, durch einen Cloud-Dienst ersetzen, umziehen oder behalten. Die Regeln für Daten, Sicherheit und Kosten vereinbare ich mit den Teams, die sie betreiben, und sorge dafür, dass jede Migration ihnen folgt, damit die Firma nicht mit einer neuen Landschaft endet, die so verworren ist wie die alte.“

Die ausführliche Antwort: Eine Cloud-Strategie ist vor allem eine Entscheidung über das Portfolio; die Wahl der Technik folgt daraus.

Schwache Antwort: „Alles geht in die Cloud.“ Nachfrage: „Eine Aufsicht fragt, wie du den Cloud-Anbieter wieder verlassen würdest.“ Sag, was du zeigst.

Wie verändern Regulierung und die Regeln der Aufsichten deine Arbeit als Architekt?

Worauf sie achten: dass du weißt, dass die Landschaft auch von außen gelesen wird.

Kurze Antwort: „In regulierten Firmen wollen Aufsichten sehen, dass kritische Funktionen und die Systeme und Dienstleister dahinter bekannt und getestet sind und sich wiederherstellen lassen. Regulierung wie der DORA der EU für Finanzfirmen macht aus der Architekturübersicht einen Nachweis. Ich halte diese Übersicht aktuell und kläre mit Risikomanagement und Compliance, was jede Regel verlangt.“

Die ausführliche Antwort: Jedes Land hat seine eigene Aufsicht und eigene Regeln; die Rechts- und Compliance-Teams der Firma legen sie aus, der Architekt macht sie in der Landschaft sichtbar.

Schwache Antwort: „Um Regulierung kümmert sich Compliance.“ Nachfrage: „Die Aufsicht fragt, welche Systeme den Zahlungsverkehr stützen.“ Sag, wie schnell du antwortest.

Wie würdest du den Einsatz von KI und Daten in der ganzen Landschaft steuern?

Worauf sie achten: die strategischen Fragen von heute.

Kurze Antwort: „Ich erfasse, wo KI einer Capability dienen könnte und welche Daten sie bräuchte, prüfe, ob diese Daten Verantwortliche haben und verlässlich sind, und lege einige Plattformen fest, damit nicht jedes Team seine eigene kauft. Den Einsatz von KI nehme ich in die Sicht auf Risiken auf, mit Regeln dafür, was automatisiert werden darf und wo ein Mensch entscheiden muss.“

Die ausführliche Antwort: KI-Projekte scheitern öfter an den Daten als an den Modellen; Data GovernanceWissen, wie Daten verantwortet und gesteuert werden, damit die Daten über alle Systeme verlässlich bleiben. ist Teil der Antwort.

Schwache Antwort: „Jeder Bereich probiert seine eigenen KI-Werkzeuge aus.“ Nachfrage: „Fünf Bereiche haben fünf KI-Produkte gekauft.“ Sag, was du tust.

Wie zeigst du den Wert der Enterprise Architecture Menschen, die daran zweifeln?

Worauf sie achten: eine Praxis, die sich ihren Platz verdient.

Kurze Antwort: „Mit Ergebnissen, die sie wiedererkennen: abgelöste Systeme und ihre Kosten, eine Fusion, die schneller fertig war, eine Frage der Aufsicht, an einem Tag beantwortet. Ich berichte jedes Jahr einige solcher Zahlen und mache die Architekten früh in Projekten nützlich, damit man den Wert spürt, bevor er berichtet wird.“

Die ausführliche Antwort: Eine Praxis, die nur Dokumente erzeugt, wird in der nächsten Budgetrunde gekürzt; eine, die Geld spart, nicht.

Schwache Antwort: „Architektur ist langfristig wichtig.“ Nachfrage: „Der CFO will das Team halbieren.“ Sag, was du zeigst.

Runden für Senior-Rollen

Wie würdest du als Senior Enterprise Architect einen Domain Architect zum Enterprise Architect entwickeln?

Worauf sie achten: dass du die Praxis über Menschen aufbaust.

Kurze Antwort: „Ich gebe einem Domain Architect eine Frage über mehrere Domänen, etwa die Kundendaten, die drei Bereiche nutzen, mit meinem Review, dann einen Platz im Architekturboard und eine eigene Roadmap. Ich coache die Gespräche mit der Führung, denn die sind meist das Neue.“

Die ausführliche Antwort: Ein Senior oder Lead Enterprise Architect wird an der Praxis um ihn herum gemessen: an ihrem Vertrauen, ihrem Tempo und den Menschen, die sie entwickelt.

Schwache Antwort: „Die lernen durch Zuschauen.“ Nachfrage: „Dein bester Domain Architect will Spezialist bleiben.“ Sag, wie du ihn hältst.

Dein Lebenslauf für diese Fragen

Jeder Job in deinem Lebenslauf lädt zu den Fragen oben ein: welche Landschaft, welche Roadmap, welches Board und was es verändert hat. Gib jeder dieser Geschichten eine Zeile, so geschrieben, dass ein Chief Architect mehr hören will:

Leg deinen Lebenslauf mit der kostenlosen Punkteprüfung neben einen Job als Enterprise Architect, den du willst; den Bereich, den sie als dünn findet, übst du zuerst, mit einer Landschaft, die du aus dem Kopf zeichnen kannst.