Vorlage für die Stellenbeschreibung Data Architect - Leitfaden 2026

Von Kevin Kim · Aktualisiert am 6. September 2026

Ein Data Architect gestaltet, wie die Daten einer Organisation modelliert, gespeichert und gesteuert werden, damit jedes Dashboard und jedes nachgelagerte System aus einer verlässlichen Struktur schöpft statt aus sechs widersprüchlichen Versionen der Wahrheit. Der Titel deckt mehr ab als die meisten: Er wird verwendet für die Person, die das unternehmensweite Datenmodell verantwortet, für die Person, die das Cloud-Warehouse und seine Modellierungsschicht entwirft, und oft genug für einen Senior Data Engineer, dem ein größerer Titel ohne größeren Verantwortungsbereich verliehen wurde. Das sind drei verschiedene Jobs mit drei verschiedenen Einstellungsmaßstäben. Dieser Leitfaden zieht die Grenzen zwischen ihnen und baut dann eine Vorlage rund um die Variante, für die Unternehmen heute am häufigsten einstellen: den Plattform-Architekten, der entscheidet, wie Snowflake, BigQuery oder Databricks unter allem anderen aufgebaut wird.

Wichtige Eckpunkte

• Ein Titel, drei Jobs: „Data Architect“ umfasst die Person für das Enterprise-Datenmodell, den Designer der Cloud-Plattform und einen Senior Data Engineer mit größerem Titel, und jede Variante braucht eine eigene Stellenbeschreibung
• Bundesdaten zu Löhnen trennen die Vergütung tatsächlich: Das BLS weist für Database Architects und Database Administrators getrennte Mediane aus, eine Unterscheidung, die die meisten Stellenanzeigen verwischen
• Verantwortet die Modellierungsschicht, nicht nur die Plattform: wählt zwischen dimensionalen Mustern (Kimball-Sternschema) und Data Vault 2.0 und legt dann die Standards fest, an denen sich Data Engineers orientieren
• Governance ist vom Nebenprojekt zur Kernaufgabe geworden: Data Contracts, Lineage-Tracking und Katalog-Tools gehören heute zum Tagesgeschäft, nicht zu einem späteren Projekt
• Wächst schneller als das Datenbankfeld ringsum: Bundesprognosen zeigen für Architect-Stellen ein Wachstum, das deutlich vor der Administratorenseite desselben Berufs liegt
• Sitzt über der Pipeline, arbeitet in ihr: berichtet meist an einen Chief Data Officer oder VP of Data Engineering, arbeitet aber täglich mit Data Engineers, DBAs und Analysten zusammen

Warum diese Rolle wichtig ist

Jedes Unternehmen, das über eine Handvoll Tabellen hinauswächst, braucht irgendwann jemanden, der bewusst entscheidet, wie die Daten geformt sind. Ohne diese Person entsteht die Form zufällig: Ein Team baut eine Kundentabelle auf eine Art, ein anderes baut eine parallele Version mit einer anderen Definition von „aktiv“, und drei Dashboards widersprechen sich vor derselben Führungskraft bei derselben Zahl. Ein Data Architect ist dafür verantwortlich, das zu verhindern, und es schnell zu beheben, wenn es trotzdem passiert.

Die Plattformen unter dieser Arbeit wachsen schnell genug, dass heutige Architekturentscheidungen jahrelange Folgen haben. Der weltweite Markt für Data Warehousing soll laut dem Data Warehousing Global Market Report der Business Research Company (Stand September 2026) von $37,42 Milliarden im Jahr 2025 auf $43,48 Milliarden im Jahr 2026 und bis 2030 auf $79,15 Milliarden wachsen, bei einer jährlichen Wachstumsrate (CAGR) von 16,2 Prozent. Jeder Dollar dieser Ausgaben landet auf einer Struktur, die jemand entworfen hat, und eine schlechte strukturelle Entscheidung wird mit der Zeit nur teurer zurückzunehmen.

Auch der Job hat sich im Gleichschritt mit der AI-Einführung verändert. Der 2026 State of Analytics Engineering Report von dbt Labs (veröffentlicht im April 2026) stellte fest, dass die Bedeutung von Vertrauen in Daten von 66 Prozent im Jahr 2025 auf 83 Prozent im Jahr 2026 sprang, während 72 Prozent der Teams AI-gestütztes Coding priorisieren, aber nur 24 Prozent AI-gestütztes Pipeline-Management und Qualitätskontrollen. Unklare Datenverantwortung blieb bei 41 Prozent hängen, unverändert gegenüber dem Vorjahr. Genau diese Lücke zwischen Output und Stabilisierung soll ein Data Architect schließen: nicht noch eine Pipeline, sondern Verantwortung dafür, was Verantwortung bedeutet.

Data Architect: Drei Jobs, ein Titel

Die Vorlage dieses Leitfadens zielt auf die mittlere Zeile, die Variante, für die Unternehmen heute am häufigsten einstellen. Wenn Sie stattdessen die Enterprise-Variante brauchen, gewichten Sie die Anforderungen stärker auf Governance und Moderation von Stakeholdern als auf praktische Plattformtiefe und lassen die Rolle direkt an Ihren Chief Data Officer berichten. Wenn eine Führungskraft einen Job beschreibt, der sich genau wie eine Data-Engineer-Rolle liest, nur mit dem Wunsch nach höherem Gehalt, benennen Sie das offen, statt den Titel aufzublähen, um ein Vergütungsproblem zu lösen.

Primäre Vorlage für die Stellenbeschreibung

Vorab lesenswert: unser Leitfaden zu Best Practices für Stellenbeschreibungen. Die Vorlage unten orientiert sich standardmäßig an der oben beschriebenen Variante des Plattform- und Warehouse-Architekten; passen Sie den Abschnitt Anforderungen an, wenn Sie stattdessen für die Enterprise- oder Senior-Engineer-Variante einstellen.

Über die Rolle

Wir suchen einen Data Architect, der verantwortet, wie unsere Daten auf unserer Cloud-Datenplattform modelliert, gespeichert und gesteuert werden. Sie entwerfen die Warehouse- und Lake-Strukturen, von denen jedes Dashboard und jedes nachgelagerte System abhängt, entscheiden, wann ein Fachgebiet dimensionale Modellierung statt eines Data-Vault-Ansatzes verlangt, und legen die Standards fest, an denen sich unser Data-Engineering-Team orientiert. Das ist keine Strategierolle aus der Distanz: Rechnen Sie mit echter Zeit in der Plattform, mit der Prüfung von Schemata, dem Feintuning von Kosten und Performance und der Zusammenarbeit mit Engineers an den Pipelines, die umsetzen, was Sie entwerfen.

Sie arbeiten eng mit Data Engineering, Analytics, Security und den Fachbereichen zusammen, die auf verlässliche Zahlen angewiesen sind, und verwandeln ein Gewirr aus Quellsystemen und widersprüchlichen Definitionen in ein Modell, auf dem Menschen aufbauen können. Rechnen Sie damit, Entscheidungen gegenüber Stakeholdern zu verteidigen, die eine Abkürzung an der Governance vorbei suchen, und ebenso oft damit, zu verhindern, dass Governance zur Ausrede wird, alles zum Stillstand zu bringen.

Die ideale Person hat bereits erlebt, dass eine Kennzahl in drei Systemen drei verschiedene Dinge bedeutete, oder eine Migration, die einfach aussah, bis die vierte nachgelagerte Abhängigkeit auftauchte, und will diese Arbeit trotzdem machen. Sie berichten an unseren Chief Data Officer oder VP of Data Engineering und arbeiten täglich mit den Data Engineers, Datenbankadministratoren und Analysten zusammen, die in dem von Ihnen aufgebauten Modell arbeiten.

Hauptaufgaben

• Entwurf von Datenmodellen: Konzeptionelle, logische und physische Modelle für Warehouse und Lake entwerfen und je nach Auditbedarf und Änderungsgeschwindigkeit zwischen dimensionalen Mustern (Kimball-Sternschema) und Data Vault 2.0 wählen
• Plattformarchitektur: Architekturentscheidungen für die Cloud-Datenplattform verantworten, ob Snowflake, BigQuery oder Databricks, einschließlich Partitionierung, Clustering und Kostensteuerung bei wachsendem Volumen
• Modellierungsstandards: Die Konventionen festlegen, an denen sich Data Engineers und Analytics Engineers orientieren, damit fünf Teams aufhören, fünf Wege zu erfinden, dieselbe Kundenentität zu modellieren
• Data Contracts: Schema-Verträge zwischen Quellsystemen und Warehouse definieren, damit eine vorgelagerte Produktänderung nicht mehr still ein Dashboard Wochen später zerstört
• Governance, Lineage und Katalogisierung: Die Lineage- und Katalog-Tools verantworten, mit denen jemand eine Zahl bis zur Quelle zurückverfolgen kann, ohne Sie anzuschreiben
• Verantwortung für Stammdaten: Die einzige Wahrheitsquelle für Kernentitäten wie Kunde, Produkt und Konto definieren und festlegen, wie jede über parallele Systeme hinweg zugeordnet wird
• Security by Design: Zugriffskontrolle und Sicherheit auf Zeilen- oder Spaltenebene in das Modell selbst einbauen, in Abstimmung mit Datenbankadministratoren, die die Instanzen im Tagesgeschäft betreiben
• Systemübergreifende Integration: Gestalten, wie Betriebssysteme, Drittdaten und Event-Streams in das Modell einfließen, ohne Geschäftslogik zu duplizieren
• Fachliche Prüfung und Mentoring: Von Data Engineers und SQL-Entwicklern vorgeschlagene Datenmodelle prüfen und das Team zu Abwägungen anleiten
• Dokumentation: Das Enterprise-Datenmodell, das Glossar und die Lineage-Diagramme so aktuell halten, dass ein neuer Data Analyst sie ohne zweistündige Einführung nutzen kann

Anforderungen

Zwingende Qualifikationen:

• Bachelorabschluss in Informatik, Wirtschaftsinformatik oder einem verwandten technischen Fach oder gleichwertige Erfahrung
• 6+ Jahre in Data Engineering, Datenbankadministration oder Datenmodellierung, einschließlich Verantwortung auf Architekturebene
• Tiefe SQL-Kenntnisse und praktische Architekturerfahrung auf mindestens einer großen Cloud-Datenplattform (Snowflake, BigQuery oder Databricks)
• Praktische Erfahrung sowohl mit dimensionaler Modellierung als auch mit Data-Vault-Mustern und Urteilsvermögen, wann welche passt
• Erfahrung in der Definition von Data Contracts oder Schema-Governance zwischen Quellsystemen und einem zentralen Warehouse
• Praktische Kenntnisse von Tools für Datenkataloge, Lineage oder Metadatenmanagement
• Fähigkeit, einem Data Engineer und einem Business-Stakeholder eine Modellierungsabwägung zu erklären, in zwei verschiedenen Vokabularen
• Verständnis von Datensicherheit, Zugriffskontrolle und den für Ihre Branche relevanten Compliance-Frameworks

Wünschenswerte Qualifikationen:

• Erfahrung mit dbt oder einem ähnlichen Transformations-Framework zwischen dem Roh-Warehouse und der modellierten Schicht
• Frühere Erfahrung als Datenbankadministrator oder Data Engineer vor dem Wechsel in die Architektur
• Hintergrund in einer regulierten Branche (Finanzdienstleistungen, Gesundheitswesen) mit entsprechenden Governance-Anforderungen
• Vertrautheit mit Data Mesh oder domänenorientierten Verantwortungsmodellen, auch ohne formale Einführung
• Berührung mit AI-Serving-Infrastruktur und Abstimmung mit einem AI Solutions Architect, wo das Unternehmen einen hat
• Einschlägige Zertifizierungen (SnowPro, Google Professional Data Engineer, Databricks Certified Data Engineer)

Was wir bieten

• Wettbewerbsfähige Vergütung: Grundgehalt abgestimmt auf Marktdaten für Ihre Stufe, im Vergütungsleitfaden unten beschrieben
• Umfassende Benefits: Kranken-, Zahn- und Sehhilfeleistungen sowie 401(k) mit Arbeitgeberzuschuss
• Moderne Datenplattform: Architekturentscheidungen auf einem aktuellen Cloud-Stack, nicht auf einem Jahrzehnt undokumentierter Altschemata
• Echter Einfluss: Ihre Modellierungs- und Governance-Entscheidungen prägen jedes Dashboard und jede Pipeline, die nach Ihrem Eintritt gebaut werden, nicht ein Diagramm, das in einem Wiki liegt
• Berufliche Weiterentwicklung: Budget für Plattform-Zertifizierungen, Konferenzen und modellierungsbezogene Schulungen
• Flexible Arbeitsform: Hybride oder Remote-Optionen je nach Team und Rollenstufe

Kontextvarianten

Konzernumfeld

In größeren Organisationen erwarten Sie formale Governance-Gremien, mehrere Geschäftseinheiten mit widersprüchlichen Kennzahlendefinitionen und längere Zeiträume für Modelländerungen, weil mehr Systeme davon abhängen. Eine große Plattformmigration läuft oft parallel zu einem Implementation Manager, der den Rollout über die Abteilungen hinweg koordiniert, während Sie verantworten, ob das Zielmodell korrekt ist. Katalog- und Lineage-Tools sind meist bereits vorhanden, sodass der Job stärker auf die Durchsetzung von Standards und Verhandlungen mit Stakeholdern ausgerichtet ist als auf einen Neuanfang auf dem leeren Blatt.

Startup-Umfeld

In einem Unternehmen in der Frühphase ist der Data Architect oft die erste Senior-Data-Besetzung, wählt die erste Warehouse-Plattform und baut das erste echte Datenmodell aus dem Nichts. Rechnen Sie damit, dass die Rolle in Data Engineering übergeht und manchmal in Ad-hoc-Arbeit als PostgreSQL-Entwickler auf der Transaktionsseite, bis das Team groß genug ist, um die Verantwortlichkeiten zu trennen. Sicherheit im Umgang mit unvollkommenen, sich schnell bewegenden Daten zählt mehr als ein perfekt normalisiertes Schema, das ein Quartal zu spät ausgeliefert wird.

Remote-/Hybrid-Umfeld

Remote arbeitende Data Architects stützen sich stärker auf schriftliche Architecture Decision Records als auf Whiteboard-Sitzungen vor Ort, denn ein klares Dokument, das erklärt, warum ein Modell so geformt ist, erspart ein Dutzend künftiger Meetings. Die asynchrone Erklärung einer Modellierungsabwägung muss für sich allein stehen können, ohne dass eine mündliche Einführung die Lücken füllt. Die Überschneidung der Zeitzonen mit dem Data-Engineering-Team, das von Ihren Entscheidungen am stärksten betroffen ist, sollte im Auswahlprozess gewichtet werden.

Branchenspezifische Überlegungen

Das Kernspektrum der Architekturkompetenzen lässt sich über Branchen hinweg übertragen, doch welches Modellierungsmuster gewinnt und wie viel Governance-Aufwand damit einhergeht, verschiebt sich je nach Sektor.

Vergütungsleitfaden

Wie die Bundesdaten zu diesem Titel passen

Das U.S. Bureau of Labor Statistics fasst diese Arbeit unter Database Administrators and Architects (SOC 15-1245) zusammen und weist ein gemischtes Median-Jahresgehalt von $126.760 (Mai 2025) aus. Ungewöhnlich für einen Titel in dieser Sammlung trennt das BLS die beiden: Database Architects haben ein Median von $139.500, während Database Administrators bei $104.620 liegen, laut BLS Occupational Outlook Handbook, Database Administrators and Architects (Gehaltsdaten Mai 2025). Diese Lücke allein erklärt, warum allgemeine „Datenbank“-Gehaltsdaten unterschätzen, was eine Besetzung mit Architect-Titel tatsächlich kostet.

Die Wachstumszahlen stimmen damit überein. Das BLS prognostiziert für den kombinierten Beruf von 2025 bis 2035 ein Wachstum von 4 Prozent, etwa durchschnittlich schnell, mit rund 7.300 jährlichen offenen Stellen bei insgesamt 144.500 Stellen, doch seine eigenen Untergliederungen zeigen für Architects ein Wachstum von 9 Prozent, während Administrators bei 0 Prozent stagnieren. Die Seite von O*NET zu Database Architects (Code 15-1243.00) ergänzt Nuancen: 66.900 Beschäftigte im Jahr 2024, etwa 4.000 jährliche offene Stellen bis 2034, die Kennzeichnung Bright Outlook und 76 Prozent der Stellenanzeigen, die mindestens einen Bachelorabschluss verlangen.

Die Nachfrage steigt weiter, weil die Plattformausgaben weiter zusammenwachsen, und die Ausgaben für Governance-Tools wachsen noch schneller: Der weltweite Markt für Data Governance soll laut dem Data-Governance-Marktbericht von Fortune Business Insights (Stand August 2026) von $5,38 Milliarden im Jahr 2026 auf $24,07 Milliarden bis 2034 wachsen, bei einer CAGR von 20,50 Prozent. Jemand muss das Modell verantworten, auf dem diese Tools aufsetzen, und das ist diese Rolle.

Marktvergütung nach Erfahrungsstufe

Die folgenden Spannen sind vom Arbeitgeber festgelegte Marktschätzungen, aufgebaut um die oben überprüfte BLS- und O*NET-Basis und die übliche Senioritätsprogression in Rollen der Datenarchitektur. Verstehen Sie sie als Planungsspanne, nicht als Zitat aus einer einzelnen Gehaltsdatenbank.

Leitfaden zur regionalen Anpassung nach Metropolregion

Was ein konkretes Angebot beeinflusst: die Branche (Finanzdienstleistungen und Technologie zahlen über dem Median), wie tief die Plattformverantwortung reicht, ob Katalog- und Lineage-Verantwortung dazugehören und wie direkt das Modell mit regulatorischem Risiko oder Umsatzberichterstattung verknüpft ist.

Anforderungsmatrix nach Erfahrungsstufe

Interviewfragen

Fachliche Fragen

1. Modellierungsabwägungen: „Wann würden Sie für ein neues Fachgebiet dimensionale Modellierung statt Data Vault 2.0 wählen, und was würde Ihre Meinung ändern?"
2. Plattformdesign: „Entwerfen Sie die Warehouse-Schicht für ein Unternehmen, das über drei Produktlinien hinweg fünf Milliarden Events pro Tag verarbeitet. Welche Plattform würden Sie wählen, und warum?"
3. Data Contracts: „Wie würden Sie einen Schema-Vertrag zwischen einem vorgelagerten Produktteam und dem Warehouse definieren und durchsetzen?"
4. Governance in der Praxis: „Ein VP möchte Lesezugriff auf rohe Kundendaten für eine einmalige Analyse. Wie bewerten Sie das und wie reagieren Sie?"
5. Migrationsplanung: „Beschreiben Sie, wie Sie die Migration von einem On-Premises-Warehouse auf eine Cloud-Plattform planen, ohne das Reporting sechs Monate lang zu beeinträchtigen."
6. Performance und Kosten: „Die Abfragen eines Teams sind korrekt, aber die Warehouse-Rechnung hat sich in diesem Quartal verdreifacht. Wie gehen Sie der Ursache nach?"
7. Stammdatenkonflikte: „Zwei Systeme sind sich uneins, was als ‚aktiver Kunde‘ zählt. Wie lösen Sie das auf Modellebene und nicht innerhalb eines Dashboards?"
8. Lineage und Vertrauen: „Wie würden Sie es einem neuen Analysten ermöglichen, einer Dashboard-Zahl zu vertrauen, ohne Sie direkt zu fragen?"

Verhaltensbasierte Fragen

1. „Erzählen Sie von einem Datenmodell, das Sie entworfen haben und das später überarbeitet werden musste. Was haben Sie gelernt?"
2. „Beschreiben Sie eine Situation, in der Sie die Anfrage eines Stakeholders wegen eines Governance- oder Sicherheitsbedenkens abgelehnt haben."
3. „Schildern Sie eine Meinungsverschiedenheit mit einem Data Engineer oder DBA über eine Architekturentscheidung. Wie wurde sie gelöst?"
4. „Erzählen Sie von der komplexesten Enterprise-Integration, die Sie von Anfang bis Ende verantwortet haben."
5. „Beschreiben Sie, wie Sie ein Datenmodell übernommen haben, das Sie nicht selbst entworfen hatten. Wie haben Sie entschieden, ob Sie es behalten oder ersetzen?"
6. „Erzählen Sie, wie Sie über mehrere Teams hinweg einen Konsens aufgebaut haben, bevor eine Architekturentscheidung ausgeliefert wurde."

Fragen zur kulturellen Passung

1. „Wie wägen Sie architektonische Reinheit gegen die Realität eines termingetriebenen Teams ab?"
2. „Wie sieht im Alltag eine gesunde Beziehung zwischen Datenarchitektur und Data Engineering aus?"
3. „Wie gehen Sie mit einem Team um, das das von Ihnen entworfene Modell regelmäßig umgeht?"
4. „Welche Architekturentscheidung würden Sie anders treffen, wenn Sie diese Rolle noch einmal von vorn beginnen würden?"

Bewertungshinweise: Achten Sie auf Kandidatinnen und Kandidaten, die eine Abwägung in einfacher Sprache erklären, statt nur das Muster zu benennen. Starke Antworten enthalten ein konkretes System, einen Stakeholder und eine Konsequenz, nicht die allgemeine Behauptung, „das Datenmodell verbessert“ zu haben. Seien Sie vorsichtig bei Personen, die darauf beharren, ein Modellierungsansatz sei immer richtig, oder die einen „Architect“-Titel hatten, aber keine unternehmensweite Entscheidung nennen können, die sie getroffen haben.

Einstellungstipps

Kurzer Sourcing-Leitfaden

• LinkedIn: Suchen Sie Titel wie „Data Architect“, „Enterprise Data Architect“ oder „Analytics Architect“, gefiltert nach Ihrer Ziel-Cloud-Plattform
• Plattform-Communities: Nutzergruppen und Zertifizierungsverzeichnisse von Snowflake, Databricks und BigQuery bringen Personen zum Vorschein, die täglich mit der Plattform arbeiten
• Auf Modellierung fokussierte Communities: Gruppen rund um Data Vault und Kimball sowie die dbt-Slack-Community ziehen Menschen an, die in Abwägungen denken statt in einem einzigen Muster
• Interner Aufstiegspfad: Ihre stärksten Data Engineers und DBAs sind oft die besten Kandidaten; achten Sie auf Personen, die bereits informell teamübergreifende Modellierungsentscheidungen treffen

Zu vermeidende Warnsignale

• Nur Tool-Kenntnis: Kennt die Konsole einer Cloud-Plattform in- und auswendig, kann aber nicht erklären, warum ein Modell so geformt ist
• Keine Governance-Geschichte: Kann keine echte Entscheidung zu Zugriffskontrolle oder Data Contracts beschreiben, die sie oder er getroffen hat
• Denken in nur einem Muster: Besteht darauf, dass dimensionale Modellierung oder Data Vault immer richtig sei, ohne ein Gefühl dafür, wann das andere besser passt
• Titel ohne Verantwortungsbereich: Hatte schon einen „Architect“-Titel, beschreibt aber Arbeit, die der eines Senior Data Engineer gleicht, ohne unternehmensweite Entscheidungen vorzuweisen
• Kann eine schlechte Entscheidung nicht erklären: Kein Beispiel für eine Architekturentscheidung, die nicht aufging, oder dafür, was sie oder er ändern würde