Vorlage für die Stellenbeschreibung Solutions Architect - Leitfaden 2026

Von Kevin Kim · Aktualisiert am 9. September 2026

Schreiben Sie eine Stelle als "Solutions Architect" aus, erhalten Sie drei Arten von Bewerbern: einen Pre-Sales-Engineer eines Anbieters, der die Woche mit Kundengesprächen verbringt, einen Delivery-Berater, der baut, was der Deal versprochen hat, und einen internen Architekten, der noch nie einen Sales-Zyklus erlebt hat. Alle drei tragen denselben Titel, und eine Anzeige, die nicht sagt, welchen sie sucht, zieht alle drei an und lehnt dann zwei aus Gründen ab, die nie in der Anzeige standen. Zu den Grundlagen einer Anzeige, die gut filtert, lesen Sie unseren Leitfaden zu Best Practices für Stellenbeschreibungen.

Auch die Bundesdaten zu Gehältern helfen hier nicht weiter, weil sie den Titel gar nicht kennen. Das lohnt sich zuerst anzuschauen.

Wichtige Eckpunkte

• "Solutions Architect" sind mindestens drei verschiedene Jobs: Pre-Sales auf Anbieterseite, Delivery bzw. Professional Services und interne Unternehmensarchitektur, jeweils mit anderer Führungskraft, anderer Anreizstruktur und anderer Arbeitswoche.
• Das U.S. Bureau of Labor Statistics kennt keine Berufsgruppe "Solutions Architect": Zwei veröffentlichte Reihen grenzen die Rolle aus entgegengesetzten Richtungen ein und landen in derselben Gegend.
• Diese beiden Reihen konvergieren im mittleren Bereich von $130.000: ein vertretbarer nationaler Schwerpunkt, auch wenn keine der beiden tatsächlich der Job ist.
• Die eigentliche Streuung entsteht durch den Verantwortungsbereich, nicht nur durch die Seniorität: Ein Pre-Sales-Architekt auf Anbieterseite bei einem Enterprise-SaaS-Unternehmen kann mehr verdienen als ein interner Architekt mit doppelt so langer Berufserfahrung.
• Eine Anzeige, die die drei Varianten verwischt, zieht Kandidaten an, die in entgegengesetzten Richtungen falsch sind: Ein vertriebsscheuer interner Architekt und ein schreibtischscheuer Pre-Sales-Spezialist bewerben sich beide, und keiner passt.
• Der Wert einer Zertifizierung hängt ganz davon ab, welchen der drei Jobs Sie besetzen: Ein Architekt auf Anbieterseite, der Cloud-Software verkauft, erhält echte Signalwirkung von einer Cloud-Zertifizierung; ein interner Enterprise Architect profitiert mehr von TOGAF.

Warum diese Rolle wichtig ist

Solutions Architecture liegt dort, wo die Technologieentscheidungen eines Unternehmens entweder auf dessen Umsatz oder auf dessen Betrieb treffen, je nachdem, welche Variante des Jobs gemeint ist. Diese Mehrdeutigkeit ist die größte Ursache für Fehlbesetzungen bei Solutions Architects, denn Personalverantwortlicher und Kandidat können mit jeweils einem anderen Job im Kopf ins Interview gehen und die Diskrepanz erst in Woche drei bemerken.

Die Anforderungen an einen sauber definierten Verantwortungsbereich sind mit den Systemen gewachsen, um die herum diese Architekten entwerfen. Die Ausgaben für Cloud-Infrastruktur im Unternehmensbereich erreichten im zweiten Quartal 2026 $143,4 Milliarden, mehr als $43 Milliarden über dem Vorjahr und damit die höchste Wachstumsrate seit acht Jahren, laut Synergy Research Group (veröffentlicht am 30. Juli 2026). Jeder dieser Dollar wird gegen einen Entwurf ausgegeben, den jemand freigegeben hat, sei es, um einen Deal abzuschließen, eine Implementierung auszuliefern oder den internen Stack eines Unternehmens zusammenzuhalten.

Drei Jobs, ein Titel

• Solutions Architect auf Anbieterseite bzw. im Pre-Sales: Einem Vertriebsteam zugeordnet, entwirft die Implementierung des potenziellen Kunden während des Deal-Zyklus und trägt oft eine quotennahe Zielgröße, auch ohne den Abschluss selbst zu verantworten. Die Arbeit ähnelt eher der eines Solutions Engineer oder Sales Engineer als der eines Software Architect, und bei vielen Anbietern werden die Titel für dieselbe Position austauschbar verwendet.
• Solutions Architect im Delivery bzw. in den Professional Services: Entwirft und beaufsichtigt den Aufbau für einen namentlich bekannten Kunden nach Vertragsabschluss und übergibt dann an das Implementierungsteam oder bleibt dabei. Diese Person berichtet an eine Führungskraft aus Services oder Delivery, nicht aus dem Vertrieb, und wird an Go-live-Terminen und Kundenzufriedenheit gemessen, nicht an Bookings.
• Interner Enterprise Solutions Architect: Entwirft, wie Systeme innerhalb eines Unternehmens zusammenspielen, also Integrationsmuster, Datenfluss zwischen Plattformen und Build-versus-Buy-Entscheidungen. Das ist die Variante, die den meisten Menschen bei "Architekt" zuerst einfällt, und die, die am häufigsten mit einem Software Architect oder Data Architect verwechselt wird.

Ziehen Sie die Grenze in der Anzeige selbst. Eine Anzeige auf Anbieterseite, die wie eine interne Architekturrolle klingt, schreckt starke Pre-Sales-Kandidaten ab, die keinen Schreibtischjob wollen, und eine interne Rolle im Vertriebsjargon zieht Kandidaten an, die sich beim ersten Mal sträuben, wenn ihnen niemand eine Quote in die Hand drückt. Ein spezialisierter Verwandter, den man kennen sollte: der AI Solutions Architect, eine vierte Scoping-Dimension, die auf jede der drei Varianten aufgesetzt wird, ein auf KI und ML spezialisierter Ausschnitt aus Pre-Sales, Delivery oder interner Arbeit und kein vierter Job.

Wo der Solutions Architect endet und die Nachbartitel beginnen

Zwei Grenzen richten den größten Schaden an, wenn sie verschwimmen. Die erste verläuft zwischen Solutions Architect und Solutions Engineer bzw. Sales Engineer, wo der Unterschied oft nur darin besteht, wie viel Entwurfsarbeit die Person verantwortet statt unterstützt, und kleinere Unternehmen ziehen die Linie selten zweimal gleich. Die zweite verläuft zwischen Solutions Architect auf Anbieterseite und internem Enterprise Solutions Architect: verschiedene Jobs mit demselben Titel und sonst fast nichts Gemeinsamem.

Das Scope-Problem, und warum der Bundesmedian es nicht löst

Das BLS veröffentlicht keine Berufsgruppe "Solutions Architect". Zwei veröffentlichte Reihen grenzen die Rolle ein, und nützlich ist gerade, dass sie konvergieren.

Computer Network Architects (Berufscode 15-1241) weist für Mai 2025 ein mittleres Jahresgehalt von $134.050 aus, bei 181.800 Stellen und einem prognostizierten Beschäftigungswachstum von 8 Prozent von 2025 bis 2035, was das BLS als deutlich schneller als der Durchschnitt aller Berufe bezeichnet. Das BLS nennt für den Einstieg in diesen Beruf typischerweise 5 Jahre oder mehr Berufserfahrung.

Software Developers, als Detailberuf getrennt von der breiteren Gruppe aus Software Developers, Quality-Assurance-Analysten und Testern ausgewiesen, zeigt einen Median von $135.980 bei 1.717.800 Stellen und einem prognostizierten Wachstum von 10 Prozent von 2025 bis 2035. Ein Hinweis zu dieser Seite: Sie veröffentlicht neben den separaten Detailwerten auch einen Gruppenmedian für alle drei Berufe zusammen, $134.040 bei 1.905.400 Stellen. Der hier genannte Median von $135.980 gehört speziell zur Stellenzahl der Software Developers von 1.717.800, nicht zur Gruppensumme, und beide dürfen nie vermischt werden.

Keine der beiden Reihen ist der Job. Ein Solutions Architect ist kein Network Architect, und die meisten Solutions Architects schreiben nicht in Vollzeit Produktionscode wie ein Software Developer. Aber beide liegen innerhalb von $2.000 beieinander im mittleren Bereich von $130.000, und das ist ein vertretbarer nationaler Schwerpunkt für einen erfahrenen Solutions Architect, bevor der Verantwortungsbereich die Zahl in die eine oder andere Richtung verschiebt.

Primäre Vorlage für die Stellenbeschreibung

Über die Rolle

Wir suchen einen Solutions Architect, der das technische Design für [die Kunden-Deals, die unser Vertriebsteam abschließt / die Implementierungen, die unser Delivery-Team verantwortet / das Zusammenspiel unserer internen Systeme] verantwortet (wählen Sie die Variante, die zu dieser Stelle passt; alle drei gleichzeitig auszuschreiben zieht die falschen Kandidaten an). Sie sind die technische Stimme in [Deal-Gesprächen und Proof-of-Concept-Arbeit / Implementierungs-Kickoffs / Architektur-Reviews und teamübergreifenden Designentscheidungen].

Sie berichten an [den VP of Sales Engineering / den Director of Professional Services / den CTO] und arbeiten eng mit einem Technical Product Manager, API-Entwicklern und DevOps-Engineers zusammen, um aus einem Entwurf etwas zu machen, das live geht.

Die ideale Person hat Systeme für Kunden oder interne Stakeholder in vergleichbarer Größenordnung entworfen, kann einem nicht technischen Käufer oder einer Führungskraft einen Zielkonflikt erklären, ohne die technischen Zuhörer im Raum zu verlieren, und hat eine konkrete Geschichte über eine Lösung, die den Kontakt mit der Produktion nicht überstanden hat, samt dem, was sie danach geändert hat.

Hauptaufgaben

• Lösungsdesign: Geschäfts- oder Kundenanforderungen in eine konkrete technische Architektur übersetzen, einschließlich Systemgrenzen, Integrationspunkten und der Zielkonflikte hinter jeder Entscheidung.
• Übersetzung für Stakeholder: Denselben Entwurf auf zwei Ebenen präsentieren: im technischen Detail, das die Entwicklung braucht, und als das Geschäftsergebnis, auf das eine Führungskraft oder ein Käufer reagiert.
• Funktionsübergreifende Koordination: Über Vertrieb, Delivery, Produkt und Engineering hinweg arbeiten, je nachdem, welche Kombination zu dieser Stelle passt, damit Entwurf und Zusage im Einklang bleiben.
• Dokumentation: Architekturdiagramme, Entscheidungsprotokolle und Implementierungspläne erstellen, nach denen jemand anderes als Sie arbeiten kann.
• Technische Risikobewertung: Aufzeigen, was an einem vorgeschlagenen Entwurf schiefgehen kann, bevor es zu einem Produktionsvorfall oder einem gebrochenen Kundenversprechen wird.
• Leitung von Proof of Concepts: Technische Validierungen zuschneiden und durchführen, die eine bestimmte Frage beantworten, keine offene Exploration.
• Standards und Muster: Wiederverwendbare Architekturmuster beisteuern, damit der nächste Entwurf nicht bei null beginnt.
• Bewertung von Anbietern und Plattformen: Neue Tools oder Services an den tatsächlichen Anforderungen des zu entwerfenden Systems messen.
• Mentoring: Weniger erfahrene Engineers in Design-Reviews einbinden und die Begründung hinter einer Entscheidung erklären, nicht nur die Entscheidung selbst.
• Eskalationsstelle: Die Person sein, die das Team anruft, wenn eine Designannahme in der Praxis bricht.

Anforderungen

Zwingende Qualifikationen:

• 5+ Jahre Erfahrung in einer technischen Rolle mit direkter Verantwortung für Systemdesign
• Ein Portfolio an Lösungen, die für reale Rahmenbedingungen entworfen wurden, also Kunden-Deals, interne Migrationen oder Plattformaufbauten, keine Übungsaufgaben
• Fähigkeit, technische Zielkonflikte sowohl Engineers als auch nicht technischen Entscheidungsträgern zu präsentieren
• Praktische Tiefe in mindestens einer großen Cloud-Plattform (AWS, Azure oder Google Cloud)
• Erfahrung darin, unter Zeitdruck einen Proof of Concept oder eine technische Validierung zuzuschneiden und durchzuführen

Wünschenswerte Qualifikationen:

• Direkte Erfahrung in genau der Variante dieser Rolle, also Pre-Sales, Delivery oder intern, nicht nur in angrenzender Architekturarbeit
• Eine für Ihren primären Stack relevante Cloud-Zertifizierung
• Erfahrung mit API-Design und Integrationsmustern über Systeme von Drittanbietern hinweg
• Frühere quotennahe oder kundennahe Erfahrung, speziell für Rollen auf Anbieterseite und im Delivery

Wissenswerte Zertifizierungen

Der Wert einer Zertifizierung hängt hier ganz davon ab, welchen der drei Jobs Sie besetzen. Ein Architekt auf Anbieterseite, der Cloud-Software verkauft, erhält echte Signalwirkung von einer Cloud-Plattform-Zertifizierung; ein interner Architekt, der die Anwendungslandschaft eines Unternehmens standardisiert, hat mehr von TOGAF. Die folgenden Angaben stammen von den eigenen Seiten der jeweiligen Herausgeber und wurden geprüft.

Ein praktischer Hinweis: Keine dieser Zertifizierungen ersetzt das Gespräch über das Portfolio. Ein Interviewer kann bestätigen, dass ein Kandidat eine bestimmte Zertifizierung hielt, und dennoch nichts darüber erfahren, wie er mit Ihrem tatsächlichen System umgehen würde, und ein Pre-Sales-Kandidat ohne Zertifizierungen, aber mit drei Jahren abgeschlossener relevanter Deals ist kein schwächerer Hire als ein frisch zertifizierter Kandidat ohne Praxiserfahrung.

Was wir bieten

• Wettbewerbsfähige Vergütung: Grundgehalt abgestimmt auf Verantwortungsbereich (Pre-Sales, Delivery oder intern) und Erfahrung, siehe Vergütungsleitfaden unten
• Variable Vergütung, wo zutreffend: Provision oder Bonus in Abhängigkeit von der Zielerreichung, für Rollen auf Anbieterseite und im Delivery-Umfeld
• Umfassende Zusatzleistungen: Kranken-, Zahn- und Sehversicherung, Altersvorsorgezuschuss und bezahlter Urlaub
• Unterstützung bei Zertifizierungen: Prüfungs- und Verlängerungsgebühren für die zu Ihrem Stack passende Zertifizierung werden übernommen
• Entwicklungsweg: Ein Weg zum Senior oder Principal Solutions Architect oder, auf dem Weg der internen Architektur, in eine CTO-Position

Kontextvarianten

Konzernumfeld

In einem großen Unternehmen verantwortet ein Solutions Architect einen Ausschnitt einer größeren Architekturpraxis: eine Branchenvertikale bei einem Anbieter, eine Services-Region in einer Delivery-Organisation oder eine Business Unit bei einem internen Team. Erwarten Sie formale Architektur-Review-Gremien, dokumentierte Standards und ein Budget oder einen Stellenplan, den Sie beeinflussen, aber nicht vollständig kontrollieren.

Startup-Umfeld

In einem Startup ist der Solutions Architect oft die erste Person in dieser Rolle und erledigt alle drei Jobs gleichzeitig: hilft, frühe Enterprise-Deals abzuschließen, liefert die ersten Implementierungen selbst aus und trifft interne Systementscheidungen ohne Architektur-Review-Prozess, an dem man sie messen könnte. Ein Systemadministrator oder ein generalistischer Engineer übernimmt häufig informell Teile dieses Verantwortungsbereichs, noch bevor es den Titel überhaupt gibt.

Remote- oder Hybrid-Umfeld

Verteiltes Arbeiten verändert eher, wie die Designarbeit kommuniziert wird, als was entworfen wird. Asynchrone Dokumentation, aufgezeichnete Architektur-Walkthroughs und ein Entscheidungsprotokoll, das ohne Live-Meeting auskommt, sind wichtiger als in einem Team am selben Standort. Speziell bei den Varianten auf Anbieterseite und im Delivery verändert Remote-Arbeit außerdem, wie Proof-of-Concept-Umgebungen bereitgestellt und mit dem Kunden geteilt werden.

Branchenspezifische Überlegungen

Die Kernarbeit ist über alle Branchen hinweg gleich. Was sich verschiebt, ist, welche der drei Varianten dominiert und wie viel Compliance-Aufwand auf der Designarbeit liegt. Das BLS weist für Computer Network Architects, eine der beiden Berufsgruppen, die diese Rolle eingrenzen, zum Stand Mai 2025 die folgenden bestbezahlten Branchen aus.

Vergütungsleitfaden

Wie die Bundesdaten auf diese Bezeichnung abgebildet werden

Es gibt keine bundesweite Gehaltskategorie "Solutions Architect". Zwei Reihen grenzen ihn ein. Computer Network Architects weist für Mai 2025 ein mittleres Jahresgehalt von $134.050 aus, bei 181.800 Stellen, einem prognostizierten Wachstum von 8 Prozent von 2025 bis 2035, etwa 9.600 offenen Stellen pro Jahr und typischerweise 5 Jahren oder mehr Erfahrung für den Einstieg. Die untersten 10 Prozent verdienten weniger als $79.900 und die obersten 10 Prozent mehr als $202.680.

Software Developers, als Detailberuf und nicht als kombinierte Gruppenzahl, die auch QA-Analysten und Tester umfasst, weist einen Median von $135.980 bei 1.717.800 Stellen aus, 10 Prozent prognostiziertes Wachstum und eine Perzentilspanne von weniger als $82.460 am 10. Perzentil bis mehr als $214.670 am 90. Perzentil.

Beide Reihen liegen beim Median innerhalb von $2.000 beieinander, und diese Konvergenz ist der ehrliche Ankerpunkt: der mittlere Bereich von $130.000 landesweit, bevor Verantwortungsbereich, Branche und Metropolregion die Zahl verschieben.

Marktbänder nach Umfang

Die folgenden Bänder sind von Arbeitgebern gesetzte Marktplanungsbänder, abgeleitet aus Rollenumfang und Unternehmenstyp, kein Zitat aus einer Gehaltsdatenbank. Legen Sie damit ein Budget fest und prüfen Sie es dann anhand der oben genannten Perzentilspanne.

Leitfaden zur Anpassung nach Metropolregion

Der Standort verschiebt diese Bänder, und Rollen auf Anbieterseite werden zunehmend am Kundengebiet statt am Wohnort des Architekten bemessen. Verstehen Sie die Stufen als Richtwerte.

Anforderungsmatrix nach Erfahrungsstufe

Die Jahre zählen weniger als die Form der Erfahrung. Ein Kandidat, der fünf interne Migrationen durchgeführt hat, passt besser auf eine interne Enterprise-Rolle als einer, der zwölf Jahre ausschließlich im Pre-Sales auf Anbieterseite verbracht hat, selbst bei insgesamt längerer Berufserfahrung.

Interviewfragen

Gute Interviews mit Solutions Architects testen, wie jemand bei einem unvollständigen Briefing denkt, nicht wie viele Frameworks er nennen kann.

Fachliche Fragen

1. Klärung des Umfangs: "Ein Stakeholder gibt Ihnen eine Anforderung von einem Absatz. Was tun Sie zuerst?" Achten Sie auf: Fragen, die gestellt werden, bevor ein Diagramm gezeichnet wird.
2. Abwägung von Zielkonflikten: "Führen Sie mich durch eine Designentscheidung, bei der Sie bewusst die technisch schwächere Option gewählt haben." Achten Sie auf: einen geschäftlichen oder durch Rahmenbedingungen bedingten Grund, nicht nur technische Reinheit.
3. Umgang mit Fehlschlägen: "Erzählen Sie mir von einem Entwurf, der in der Produktion gescheitert ist oder mitten im Deal auseinandergefallen ist. Was haben Sie geändert?" Achten Sie auf: eine konkrete Korrektur, nicht eine vage Lehre.
4. Übersetzung für Stakeholder: "Erklären Sie mir eine Caching-Strategie, als wäre ich ein CFO." Achten Sie auf: Geschäftssprache, keine vereinfachte technische Erklärung.
5. Scoping von Proof of Concepts: "Wie entscheiden Sie, was ein POC beweisen muss und was er auslassen darf?" Achten Sie auf: eine enge, widerlegbare Fragestellung, keine offene Exploration.
6. Integrationsrisiko: "Wie bewerten Sie, ob eine API eines Drittanbieters tragen kann, was Sie entwerfen?" Achten Sie auf: Ratenlimits, Datenverträge und Fehlermodi, nicht nur eine Feature-Checkliste.
7. Dokumentationsgewohnheit: "Wie sieht Ihr typisches Architekturdokument aus?" Achten Sie auf: etwas, nach dem jemand anderes arbeiten könnte, keine Folie mit Kästchen und Pfeilen.
8. Plattformtiefe: "Beschreiben Sie das komplexeste System, das Sie auf unserer primären Cloud-Plattform entworfen haben." Achten Sie auf: Details, Servicenamen und tatsächlich getroffene Einschränkungen.

Verhaltensbasierte Fragen

1. Reibung zwischen Teams: "Erzählen Sie mir von einer Situation, in der Vertrieb, Delivery und Engineering uneins darüber waren, was möglich ist." Achten Sie auf: wie sie es gelöst haben, nicht nur dass es passiert ist.
2. Nein sagen: "Beschreiben Sie, wie Sie gegen eine Zusage argumentiert haben, die jemand anderes gemacht hat, bevor Sie im Raum waren." Achten Sie auf: wie sie die Beziehung geschützt und zugleich den Entwurf korrigiert haben.
3. Unklares Briefing: "Erzählen Sie mir von dem am wenigsten definierten Projekt, das Sie je bekommen haben." Achten Sie auf: wie sie Struktur aufgebaut haben, nicht wie sie sich über die Unklarheit beklagt haben.
4. Termindruck: "Beschreiben Sie, wie Sie einen Entwurf unter einer Frist geliefert haben, die Sie für unrealistisch hielten." Achten Sie auf: was sie gestrichen und was sie geschützt haben.
5. Mentoring: "Erzählen Sie mir von jemandem, den Sie bei einem Entwurf mitgenommen haben, und was diese Person heute anders macht." Achten Sie auf: konkretes Coaching, keine allgemeine Behauptung, Mentoring zu betreiben.

Fragen zur kulturellen Passung

1. Grenze der Verantwortung: "Wo endet Ihre Verantwortung für einen Entwurf?" Achten Sie auf: eine klare Linie, nicht eine unbegrenzte oder gar keine.
2. Zusammenarbeit mit Vertrieb oder Delivery: "Wie sollte sich ein Architekt zu dem Team verhalten, das verkaufen oder bauen muss, was Sie entwerfen?" Achten Sie auf: Sprache der Partnerschaft, keine Mauer zwischen den Rollen.
3. Umgang mit Ablehnung: "Erzählen Sie mir von einem Ihrer Entwürfe, der überstimmt wurde. Wie haben Sie reagiert?" Achten Sie auf: professionelle Meinungsverschiedenheit, keinen Groll.
4. Kontinuierliches Lernen: "Was hat sich in den letzten zwei Jahren daran geändert, wie Sie Systeme entwerfen?" Achten Sie auf: eine echte Antwort, die an KI-Tooling, Plattformwechsel oder einen konkreten Fehlschlag anknüpft, keine generische Aussage.

Einstellungstipps

Der häufigste Fehler hier ist, die falsche Variante auszuschreiben. Entscheiden Sie vor dem Schreiben der Anzeige, ob diese Person die Woche in Kundenterminen, in einer Delivery-Queue oder in internen Architektur-Reviews verbringen wird, und schreiben Sie den Abschnitt zu den Aufgaben für diese Realität, nicht für eine idealisierte Mischung aus allen dreien.

Kurzer Sourcing-Leitfaden

Zu vermeidende Warnsignale