Solution Architect
Der Solution Architect verantwortet die technische Gesamtlösung eines Vorhabens.
Er denkt nicht nur in Komponenten – sondern in End-to-End-Wirkung.
Er verbindet:
Business-Ziel → Architektur → Integration → Umsetzungsrealität
1. Kurzdefinition
Ein Solution Architect gestaltet die End-to-End-Lösung über mehrere Systeme hinweg.
Er verantwortet:
- Systemgrenzen
- Integrationen
- Abhängigkeiten
- technische Machbarkeit
- Risiko-Transparenz
Er ist Brücke zwischen Strategie und Architektur.
2. Kernverantwortung
Der Solution Architect beantwortet:
- Wie sieht die Gesamtlösung aus?
- Welche Systeme sind betroffen?
- Wo entstehen Integrationsrisiken?
- Welche Abhängigkeiten sind kritisch?
- Ist die Lösung realistisch umsetzbar?
Er denkt horizontal – nicht nur vertikal.
3. Was macht ein Solution Architect konkret?
3.1 End-to-End-Sicht herstellen
- Komponentenlandschaft analysieren
- Schnittstellen definieren
- Datenflüsse entwerfen
- Integrationsmuster wählen
- Legacy-Integration bewerten
3.2 Requirements in Architektur übersetzen
- Funktionale und nicht-funktionale Anforderungen einordnen
- Business-Ziele priorisieren
- Realisierbarkeit bewerten
- Architekturvarianten vergleichen
Er denkt in Lösungsoptionen – nicht nur in Features.
3.3 Trade-offs transparent machen
- Time-to-Market vs. Stabilität
- Kosten vs. Skalierbarkeit
- Build vs. Buy
- Integration vs. Eigenentwicklung
Er liefert Entscheidungsgrundlagen – keine Wunschlösungen.
3.4 Abhängigkeiten steuern
- Teamübergreifende Schnittstellen
- Plattform-Abhängigkeiten
- Externe Anbieter
- regulatorische Anforderungen
Komplexität wird explizit – nicht implizit.
4. Abgrenzung zu anderen Rollen
Solution Architect vs. Software Architect
| Software Architect | Solution Architect |
|---|---|
| Systeminterne Integrität | Systemübergreifende Kohärenz |
| Tiefe technische Prinzipien | Breite Integrationssicht |
| Struktur eines Systems | Struktur mehrerer Systeme |
| Domänengrenzen | Systemlandschaft |
Der Software Architect schützt ein System.
Der Solution Architect orchestriert mehrere.
Solution Architect vs. Enterprise Architect
| Enterprise Architect | Solution Architect |
|---|---|
| Strategische IT-Landschaft | Konkretes Lösungsdesign |
| Portfolio-Ebene | Projekt-/Vorhaben-Ebene |
| Langfristige Roadmaps | Konkrete Integrationsarchitektur |
Enterprise denkt strategisch. Solution denkt konkret.
5. Was ein Solution Architect nicht ist
❌ Kein Projektmanager
❌ Kein Feature-Implementierer
❌ Kein reiner Diagramm-Produzent
❌ Kein reiner Governance-Rolleninhaber
Er trägt Lösungsverantwortung – nicht Terminverantwortung.
6. Solution Architect im Qualitätskontext
Stufe 1:
- selten notwendig
Stufe 2:
- sinnvoll bei mehreren Integrationen
Stufe 3:
- systemübergreifende Stabilität wird kritisch
Stufe 4:
- regulatorische Integrationsanforderungen
- formale Dokumentation
Stufe 5:
- vollständige Traceability über Systemgrenzen
- Auditierbare Integrationsentscheidungen
Je komplexer die Landschaft, desto wichtiger die Rolle.
7. Typische Anti-Patterns
- Integrationen ohne Ownership
- Big Bang Integrationen
- Abhängigkeiten ohne Priorisierung
- Architektur ohne Business-Abgleich
- Lösung nur aus Technologie-Sicht
Komplexität ohne Koordination führt zu Systembruch.
8. Erfolgsindikatoren
Ein Solution Architect ist wirksam, wenn:
- Integrationen stabil laufen
- Abhängigkeiten transparent sind
- Risiken früh adressiert werden
- Business und Technik synchron bleiben
- Lösungen realistisch implementierbar sind
9. Kurzcheck
- Habe ich Überblick über alle betroffenen Systeme?
- Erkenne ich Integrationsrisiken früh?
- Liefere ich klare Architekturvarianten?
- Mache ich Trade-offs transparent?
- Schaffe ich End-to-End-Verständnis?
Wenn ja, erfüllst du die Rolle.
Kernaussage
Der Solution Architect schützt nicht nur Struktur.
Er schützt die Kohärenz der Gesamtlösung.
Ohne ihn entstehen Integrationsinseln – und Komplexität wird unsichtbar, bis sie eskaliert.