IT-Architektur
8 Minuten Lesezeit

Solution Architects coachen: Vom Umsetzer zum Gestalter mit Geschäftsverständnis

Grafik: Entwicklung von Solution Architects vom Liefern auf Zuruf über Geschäftsverständnis zum Gestalten auf Unternehmensebene

Viele Unternehmen haben in den letzten Jahren Solution Architects benannt. Sie sollen Lösungen entwerfen, die fachlich passen, technisch tragen und sich in die IT-Landschaft einfügen. In der Praxis sehe ich oft ein anderes Bild: Die Architekten liefern, was der Fachbereich bestellt, und denken bis zum Rand ihres Projekts. Alle übergreifenden Fragen landen beim Enterprise Architect, der damit zum Engpass wird.

Dahinter stehen zwei Lücken. Die erste liegt im Geschäftsverständnis: Bedarfe werden nicht erkundet, sondern entgegengenommen. Die zweite liegt in der Konzeption: Die Architekten arbeiten im Detail ihres Projekts, aber nicht auf Ebene des Unternehmens. Beide Lücken lassen sich schließen, und zwar nicht mit einem Seminar, sondern mit Coaching an echten Aufgaben.

In diesem Beitrag zeige ich Ihnen, was Solution Architects dabei lernen, wie ein solches Coaching aufgebaut ist und was die Organisation dafür leisten muss. Die Beispiele stammen aus einem Coaching-Mandat, das ich als Projektreferenz beschrieben habe.

‍

1. Warum Solution Architects oft unter ihren Möglichkeiten bleiben

Am fehlenden Fachwissen liegt es selten. Die Ursachen sind meist strukturell:

  • Die Rolle ist eine Nebenrolle: Architektur wird neben dem Tagesgeschäft erledigt. Für Dokumentation, Zielbild und Roadmap bleibt keine Zeit.
  • Liefern auf Zuruf: Die IT setzt um, was bestellt wird. Wird dem Fachbereich eine Lösung vorgegeben, die er nicht mitgestaltet hat, lehnt er sie ab.
  • Erfahrung ist ungleich verteilt: Einige Architekten arbeiten seit Jahren konzeptionell, andere sind neu in der Rolle. Hilfe läuft informell und hängt an Einzelpersonen.
  • Die Architekturlast bleibt oben: Prinzipien, Standards und übergreifende Entscheidungen liegen beim Enterprise Architect. Er wird zum Nadelöhr, die Architekten warten.

‍

2. Erste Säule: Denken wie im Vertrieb

Gute Solution Architects verhalten sich gegenüber dem Fachbereich wie ein guter Vertriebsmitarbeiter gegenüber seinem Kunden. Sie verkaufen nichts, aber sie gehen auf die Menschen zu, verstehen deren Ziele und schlagen erst dann eine Lösung vor. Ich nenne das Vertriebsdenken oder Sales Mindset.

Das Vorgehen folgt drei Schritten:

  1. Wahrnehmen: Die Architekten bauen ein Netzwerk im Fachbereich auf und erkennen Bedarfe, bevor sie als fertige Bestellung ankommen.
  2. Verstehen: Sie fragen nach dem Ziel hinter der Anfrage und nach dem Problem, das gelöst werden soll.
  3. Vorschlagen: Erst dann entwerfen sie eine Lösung, die das Geschäft trägt, weil es sie mitgestaltet hat.

Hilfreich ist eine Struktur aus dem Vertrieb, die Methode MEDDPICC. Sie stellt vor jeder Lösung eine Reihe von Fragen: Welche Kennzahl soll sich verbessern? Wer entscheidet über das Budget? Nach welchen Kriterien und in welchem Ablauf wird entschieden? Welches Problem drückt wirklich? Wer unterstützt das Vorhaben im Fachbereich? Architekten, die diese Fragen beantworten können, entwerfen Lösungen, die angenommen werden.

Jede Entscheidung läuft zudem durch einen einfachen Filter: Steigert sie den Umsatz, oder senkt sie Kosten und Risiken? Was keinen der beiden Effekte hat, wird nicht umgesetzt. Als gemeinsame Sprache mit dem Fachbereich dienen Geschäftsfähigkeiten, auf Englisch Business Capabilities. Sie beschreiben, was ein Unternehmen können muss, unabhängig davon, mit welchem System es das tut.

‍

3. Zweite Säule: Konzeptionell auf Unternehmensebene arbeiten

Die zweite Fähigkeit richtet den Blick nach oben. Solution Architects sollen nicht nur ihr Projekt lösen, sondern das Unternehmen als Ganzes mitdenken. Dazu gehören vier Bausteine:

  • Prinzipien als feste Leitplanken: So viel Standard wie nötig, so wenig wie möglich. Wenige, klare Prinzipien je Bereich, etwa für IT, Produktions-IT und KI, schaffen Freiheit innerhalb fester Grenzen.
  • Zielbild und Roadmap statt Bestandsaufnahme: Die Architekten beschreiben nicht nur, was heute existiert, sondern entwerfen, wohin sich ihr Bereich entwickeln soll.
  • Denken in Alternativen: Jede Empfehlung zeigt, welche Alternativen geprüft wurden und welche Folgen eine Entscheidung hat.
  • Klare Aufgabenteilung: Eine Delegationsmatrix legt fest, welche Architekturfragen vom Enterprise Architect zu den Solution Architects wandern. Die Architekten erarbeiten, der Enterprise Architect entscheidet und gibt frei.

Methodisch nutze ich die Substanz von TOGAF, einem verbreiteten Methodenrahmen für Unternehmensarchitektur, aber keinen vollständigen TOGAF-Kurs. Die Architekten lernen genau die Bausteine, die sie für ihre aktuelle Aufgabe brauchen.

‍

4. Wie das Coaching aufgebaut ist

Architektur lässt sich nicht vortragen, sie muss geübt werden. Deshalb folgt das Coaching fünf Grundsätzen:

  1. Werkstatt statt Schulung: Die Architekten arbeiten an echten Themen aus ihrem Alltag, etwa an einem Release-Standard oder an einer anstehenden Plattformentscheidung. Was sie erarbeiten, wird direkt angewendet.
  2. Feste Termine in kleinen Gruppen: Die Architekten treffen sich in einer festen Gemeinschaft, etwa alle zwei Wochen, und arbeiten in Gruppen von rund fünf Personen. Jede Gruppe hat einen Auftrag, einen Termin und ein Review.
  3. Kurze Impulse: Jeder Termin beginnt mit einem Impuls von etwa 20 Minuten, zum Beispiel zu Prinzipien, Zielbildern oder Architektursichten.
  4. Feedback auf die Denkweise: Im Review geht es nicht um Formatierung, sondern um Abstraktion, Alternativen und Konsequenzen.
  5. Übung im Gespräch: Die Architekten begleiten Interviews mit dem Fachbereich und führen sie Schritt für Schritt selbst.

Praxis-Tipp: Coaches aus dem eigenen Team aufbauen

Benennen Sie früh zwei bis drei Architekten als interne Coaches, ausgewählt nach Potenzial, Methodik und Kommunikation. Sie moderieren zunächst gemeinsam mit dem externen Begleiter und übernehmen dann die Führung. Mit Vertretungsregeln und einem einfachen Materialkoffer trägt sich das Format selbst. Das Ziel ist Eigenständigkeit, nicht dauerhafte externe Unterstützung. Ein Nebeneffekt: Prinzipien, Standards und Review-Protokolle werden zum Einarbeitungspaket. Neue Architekten sind in Wochen arbeitsfähig, nicht erst nach Monaten.

‍

5. Praxisbeispiel: Eine Werkstatt-Sitzung

Wie eine Werkstatt abläuft, zeigt ein typischer Termin. Auf der Tagesordnung steht eine Frage aus dem Alltag: Nach welchen Regeln sollen neue Funktionen künftig in die zentrale ERP-Plattform eingespielt werden?

Impuls (20 Minuten): Zu Beginn stelle ich kurz vor, wie ein Architekturprinzip aufgebaut ist: Aussage, Begründung und Konsequenzen. Dazu zeige ich ein gelungenes und ein schwaches Beispiel aus anderen Unternehmen.

Gruppenarbeit (60 Minuten): Eine Gruppe aus fünf Architekten erarbeitet einen Entwurf. Vorab hat sie mit dem Fachbereich geklärt, was dieser von einem Release erwartet: Planbarkeit, kurze Wartezeiten und keine Störungen im Monatsabschluss. Daraus leitet sie zwei Alternativen ab, etwa feste Release-Fenster oder kleinere, häufigere Einspielungen.

Review (30 Minuten): Eine zweite Gruppe prüft den Entwurf. Die Fragen zielen auf die Denkweise: Ist die Regel allgemein genug, um auch für andere Plattformen zu gelten? Welche Alternative wurde verworfen und warum? Was bedeutet die Regel für laufende Projekte?

Ergebnis: Die Gruppe überarbeitet ihren Entwurf bis zum nächsten Termin. Danach entscheidet der Enterprise Architect und gibt die Regel frei. Das Review-Protokoll wandert in den Methodenbaukasten und dient neuen Architekten später als Beispiel.

Nach einigen Sitzungen übernimmt ein interner Coach die Moderation. Ich bereite die Termine mit ihm vor und gebe im Anschluss Rückmeldung, bis er sie eigenständig führt.

‍

6. Was die Organisation dafür leisten muss

Coaching allein reicht nicht. Damit es wirkt, braucht es vier Voraussetzungen:

  • Feste Kapazität: Die Führungskräfte geben die Architekten für die Termine frei und tragen die Teilnahme als verbindlich mit, etwa mit einem festen Anteil der Arbeitszeit.
  • Ein klares Mandat: Die Rolle wird in einem Rollenprofil beschrieben, das festlegt, was die Architekten entscheiden, prüfen oder nur sehen.
  • Sichtbarer Nutzen: Die Leitung möchte wissen, was der Aufwand bringt. Legen Sie Ziele und Liefergegenstände fest und weisen Sie die Wirkung nach.
  • Bewusster Umgang mit Verantwortung: Wenn Architekten mehr gestalten, verschieben sich Rollen. Der Fachbereich wird vom Auftraggeber zum Mitgestalter, der Architekt vom Umsetzer zum Partner. Sprechen Sie das offen an.

‍

7. Was sich danach verändert

Wenn beide Säulen greifen, verändert sich die Zusammenarbeit spürbar:

  • Der Fachbereich gestaltet Lösungen mit und trägt sie mit, statt sie abzulehnen.
  • Architekturfragen werden dort geklärt, wo das Wissen liegt. Der Enterprise Architect wird entlastet und kann sich auf strategische Themen konzentrieren.
  • Gemeinsame Prinzipien sorgen für einheitliche Entscheidungen über Projekte und Bereiche hinweg.
  • Neue Architekten finden schneller in ihre Rolle.

Wie ich Unternehmen dabei begleite, beschreibe ich im Leistungsfeld Enterprise & IT Architecture.

‍

Häufige Fragen zum Coaching von Solution Architects

1. Ist das ein Training oder eine Beratung?
Beides nicht im klassischen Sinn. Die Architekten erarbeiten die Ergebnisse selbst, an echten Aufgaben. Ich gebe Struktur, Impulse und Feedback und übergebe die Begleitung schrittweise an interne Coaches.

2. Wie lange dauert es?
Die Aufbauphase umfasst in der Regel rund drei Monate. Danach führen die internen Coaches das Format fort, auf Wunsch mit einigen Wochen punktueller Begleitung.

3. Müssen Architekten dazu eine Vertriebsausbildung machen?
Nein. Es geht nicht ums Verkaufen, sondern um eine Haltung: zuerst zuhören und verstehen, dann vorschlagen. Die Methode aus dem Vertrieb gibt dabei nur eine Struktur für die richtigen Fragen.

‍

Fazit: Architektur wird befähigt, nicht geliefert

Solution Architects werden zu Gestaltern, wenn sie zwei Fähigkeiten verbinden: das Geschäft zu verstehen und auf Ebene des Unternehmens zu denken. Beides lernen sie nicht im Seminar, sondern in einer Werkstatt an echten Aufgaben, mit festen Terminen, klarem Mandat und Feedback auf die Denkweise. Wer früh interne Coaches aufbaut, schafft eine Fähigkeit, die bleibt.
Sind Sie bereit, Ihre Architekten zu Gestaltern zu entwickeln?
  • Klären Sie das Mandat: Was entscheiden die Architekten, was der Enterprise Architect?
  • Sichern Sie feste Kapazität für die Architekturrolle.
  • Starten Sie mit echten Themen statt mit einem Kurs.
Wenn Sie dabei Unterstützung wünschen, lassen Sie es mich gerne wissen. Im Architektur-Klarheitsgespräch klären wir in 30 Minuten, wo Ihre Architekten heute stehen und welcher nächste Schritt für Sie sinnvoll ist.

‍

Portrait von Sebastian Kretzschmar

Herzlich willkommen auf meinem Blog!

Ich modernisiere IT-Systeme und führe Transformationen zum Erfolg.
Direkt, fokussiert, ohne unnötige Umwege.

Seit Jahren begleite ich Unternehmen bei IT-Systemintegration und -Transformation. Ich verstehe Technik aber vor allem verstehe ich die Menschen, die damit arbeiten.

IT-Projekte greifen massiv in bestehende Arbeitsweisen ein. Genau da scheitern sie oft. Meine Stärke? Ich kenne die Praxis.

Ich weiß, was wirklich gebraucht wird. Lassen Sie uns sprechen. Effiziente IT-Transformation beginnt hier.

Mehr erfahren