top of page
Suche

Data Solution Engineer bei Microsoft: Rolle und Grenzen

Viele Kunden kennen bei Microsoft Account Executives, Cloud Solution Architects oder klassische Support-Rollen. Beim Data Solution Engineer ist die Trennlinie weniger offensichtlich: Ist das Vertrieb, Beratung, Architektur oder schon Umsetzung? Im Daten-WG Podcast beschreiben Alexander Korn und Lukasz Obst ihre Rolle aus der Praxis – und gerade die Grenze ihrer Arbeit ist für Unternehmen fast wichtiger als der Jobtitel.



Beide sind mit Beratungshintergrund zu Microsoft gewechselt, bringen aber unterschiedliche technische Schwerpunkte mit. Alexander Korn kommt stark aus Power BI, Lukasz Obst ursprünglich aus der Softwareentwicklung und später aus Data-Projekten und Presales. Daraus entsteht ein guter Blick auf eine Rolle, die tief technisch sein kann, aber trotzdem klar in der Sales-Organisation verankert ist.


Was ist ein Data Solution Engineer bei Microsoft?

Ein Data Solution Engineer bei Microsoft ist eine technische Presales-Rolle. Er versteht Kundenprobleme, entwickelt mit dem Kunden erste Lösungsbilder, beantwortet technische Fragen, baut Demos oder Proofs of Concept und hilft dabei, eine technische Entscheidung abzusichern. Die produktive Umsetzung und der dauerhafte Betrieb gehören nach der Beschreibung von Korn und Obst dagegen nicht zum Kern der Rolle.


Zwei Wege in dieselbe Rolle: Power BI und Softwareentwicklung

Lukasz Obst beschreibt seinen Weg zunächst gar nicht als klassischen Vertriebspfad. Er kommt aus der Softwareentwicklung, wechselte schrittweise in Datenprojekte und arbeitete anschließend in der Beratung bei einem Microsoft-Partner. Dort gehörte es nicht nur dazu, Projekte technisch umzusetzen. Er musste Kunden auch davon überzeugen, warum ein Ansatz sinnvoll ist, das eigene Unternehmen vertreten, Fragen beantworten und genügend technisches Verständnis mitbringen, um Vertrauen aufzubauen.


Genau an dieser Schnittstelle begann für ihn Presales interessant zu werden. Für Obst bedeutet Presales nicht, möglichst schnell ein Produkt zu platzieren. Entscheidend ist zunächst, den Kunden und sein Problem zu verstehen. Erst danach kommt die Frage, mit welcher Architektur und welchen Microsoft-Technologien sich dieses Problem sinnvoll lösen lässt.


Alexander Korn bringt eine andere technische Historie mit. Im Gespräch wird er als Power-BI-Experte eingeordnet; zugleich kommt auch bei ihm der Beratungshintergrund deutlich durch. Korn formuliert selbst, dass man den „Berater“ nicht einfach aus ihm herausbekomme. Das prägt die Rolle: Der Data Solution Engineer soll verkaufen helfen, arbeitet aber in vielen Gesprächen zunächst wie ein sehr technisch orientierter Berater.


Presales – aber nicht einfach Produktverkauf

Dass Data Solution Engineering Teil des Vertriebs ist, verstecken die beiden nicht. Korn beschreibt mit einem Augenzwinkern, dass Solution Engineers für den Kunden zunächst „nichts kosten“, weil ihre Arbeit Presales ist. Gleichzeitig besteht natürlich eine kommerzielle Motivation: Microsoft möchte, dass Kunden mehr Fabric und weitere Data-Produkte einsetzen.


Damit ist das Spannungsfeld klar. Ein Solution Engineer ist kein neutraler Technologieberater ohne Herstellerinteresse. Er arbeitet für Microsoft und hat Ziele. Obst betont ausdrücklich, dass auch in dieser Rolle Leistungs- und Wachstumsziele existieren und Microsoft im Cloud-, Data- und AI-Markt mit starken Wettbewerbern konkurriert.


Trotzdem wäre es zu kurz gegriffen, daraus einen klassischen Produkt-Pitch zu machen. Microsoft Careers ordnet Solution Engineering grundsätzlich den technischen Rollen innerhalb der Sales-Organisation zu: Kundenanforderungen sollen technisch verstanden, Lösungen demonstriert, technische Blocker aufgelöst und technische Entscheidungen unterstützt werden. Genau so beschreiben Korn und Obst ihren Alltag.


Vom Kundenproblem zum ersten belastbaren Lösungsbild

Ein Beispiel aus dem Gespräch macht die Rolle konkreter: Ein Unternehmen kommt aus einer Oracle-Data-Warehouse-Landschaft und möchte Richtung Microsoft Fabric modernisieren. Die grundlegende Absicht ist da, aber wichtige Fragen sind offen: Wo fängt man an? Wie sollte die Zielarchitektur aussehen? Ist das Design tragfähig? Welche Bausteine braucht man überhaupt?


Hier kann ein Data Solution Engineer tief einsteigen. Korn beschreibt die Bandbreite von einfachen Fragen über Demos bis zu ersten Lösungsansätzen und Proofs of Concept. Obst spricht von Workshops und davon, Kunden dabei zu helfen, technische Entscheidungen sauber zu treffen. Das Ziel ist nicht, das spätere Projekt vorwegzunehmen, sondern kritische Annahmen früh technisch zu prüfen.


Das ist auch deshalb relevant, weil Microsoft Fabric inzwischen weit mehr als ein einzelnes BI-Produkt ist. Microsoft beschreibt Fabric als End-to-End-Analytics-Plattform mit Data Engineering, Data Factory, Data Science, Real-Time Intelligence, Data Warehouse, Datenbanken und Power BI auf einer gemeinsamen Plattform mit OneLake. Ein Solution Engineer muss deshalb nicht jede Detailfrage selbst dauerhaft umsetzen, aber er muss genügend technische Tiefe besitzen, um eine realistische Lösung zu entwerfen und die richtigen Spezialisten einzubinden.


Gerade bei einer gewachsenen Landschaft hilft zusätzlich eine saubere Einordnung der passenden Data-&-Analytics-Technologien. Nicht jeder Workload muss automatisch in denselben Plattformbaustein wandern – und genau solche Architekturfragen gehören in die frühe Entscheidungsphase.

Wo hört die Arbeit des Data Solution Engineers auf?

Hier wird das Gespräch besonders wertvoll. Korn formuliert die Grenze sehr klar: Produktiv unterstützen dürfen die Solution Engineers nach seiner Beschreibung nicht wirklich; sie helfen bei dem, was davor liegt. Damit endet die Rolle typischerweise dort, wo aus technischer Orientierung, Demo oder PoC eine dauerhafte produktive Umsetzung wird.


Im von Korn beschriebenen Microsoft-Modell kommen dann andere Rollen ins Spiel. Cloud Solution Architects können stärker in die produktive Umsetzung und Adoption einsteigen. Für echte Projekt-Delivery gibt es wiederum entsprechende Delivery-Rollen. Sehr häufig übernehmen außerdem Microsoft-Partner die Umsetzung. Obst und Korn weisen beide darauf hin, dass diese Übergabe kein Ausnahmefall, sondern ein normaler Teil des Modells ist.

Aspekt

Data Solution Engineer

Cloud Solution Architect (CSA)

Phase im Kundenprozess

Technischer Presales vor der produktiven Umsetzung

Customer Success und Adoption – näher an Umsetzung und Produktivbetrieb

Ziel

Kundenproblem verstehen, Lösungsweg validieren und technische Entscheidung absichern

Adoption beschleunigen, Architektur operationalisieren und technische Blocker lösen

Typische Aufgaben

Workshops, Architekturgespräche, Demos, technische Fragen und Proofs of Concept

Architecture Reviews, Design Sessions, PoCs, Implementierungsbegleitung, produktive Deployments und Optimierung

Produktive Umsetzung

Im Interview klar abgegrenzt: keine reguläre produktive Unterstützung oder Delivery

Kann produktive Implementierungen und technische Adoption begleiten; ersetzt aber nicht automatisch ein vollständiges Delivery-Projekt

Partner und Delivery

Übergabe nach der Validierung häufig an CSA, Partner, Delivery oder Kundenteam

Arbeitet mit Kunden, Partnern und Delivery-Teams an Adoption und Umsetzung

Kommerzieller Kontext

Teil der Sales-Organisation mit Presales- und Wachstumszielen

Stärker auf Customer Success, Nutzung und nachhaltigen Mehrwert aus Microsoft-Investitionen ausgerichtet

Besonders sinnvoll, wenn …

eine technische Entscheidung noch nicht belastbar ist

eine validierte Architektur in produktive Nutzung und nachhaltige Adoption überführt werden soll

Die exakte Abgrenzung kann je nach Kunde, Vertragsmodell, Region und Microsoft-Organisation variieren. Entscheidend ist deshalb weniger ein starres Organigramm als das Prinzip: Technischer Presales kann eine Lösung sehr weit vorbereiten und validieren, ersetzt aber kein vollständiges Implementierungs- und Betriebsmodell. Für Power-BI-spezifische Umsetzung, Modellierung oder Reporting-Architektur ist dann beispielsweise eine Power BI Beratung eine andere Leistung als die vorgelagerte Herstellerunterstützung.


Partner sind kein Gegenspieler, sondern Teil des Modells

Gerade für Beratungsunternehmen ist die Abgrenzung interessant. Korn sagt ausdrücklich, dass Solution Engineers sehr eng mit Partnern zusammenarbeiten. Sie entwickeln beispielsweise erste PoCs und holen für die anschließende Umsetzung Partner hinzu. Nicht jeder Kunde verfügt über die Vertrags- oder Budgetstruktur, um im nächsten Schritt umfangreich Microsoft-Ressourcen wie Cloud Solution Architects einzusetzen.


Obst ergänzt die Partnerperspektive aus eigener Erfahrung. Er war selbst bei einem Microsoft-Partner und beschreibt, dass Microsoft Spezialisierungen und nachgewiesene Projekterfahrung nutzt, um Partnerkompetenzen einzuordnen. Größere und stärker spezialisierte Partner werden enger betreut; gleichzeitig gibt es je nach Kundengröße und Anforderung sehr unterschiedliche Partnerrollen.


Microsoft und Partner sind nicht zwangsläufig Alternativen. Der Solution Engineer kann die technische Richtung mitentwickeln und Hürden ausräumen, während ein Partner die konkrete Umsetzung, Integration, Migration oder langfristige Betreuung übernimmt. Wer diese Rollen früh sauber trennt, vermeidet später die Erwartung, dass Presales automatisch zum kostenlosen Projektteam wird.


Die Rolle hat Ziele – und trotzdem braucht sie Vertrauen

Besonders glaubwürdig wird das Gespräch dort, wo beide den kommerziellen Zielkonflikt nicht wegreden. Obst beschreibt, dass jeder Solution Engineer ein bestimmtes Kundenset beziehungsweise eine Branche betreut und seine Energie auf die Themen mit dem größten Impact konzentrieren muss. In seinem Fall nennt er Financial Services & Insurance und ein Set von rund 15 Kunden. Vollzeitbetreuung für jeden Kunden ist damit weder vorgesehen noch realistisch.


Gleichzeitig betonen beide den langfristigen Blick. Obst nennt ausdrücklich Situationen, in denen man einem Kunden von einer Plattform oder Dimensionierung abraten müsse, obwohl eine größere Lösung kurzfristig mehr Umsatz bringen könnte. Auch „skalier mal ein bisschen runter“ könne die richtige Empfehlung sein. Korn beschreibt dasselbe Prinzip aus dem Public-Sector-Umfeld: Souveränität, lokale Anforderungen oder On-Premises-Themen können wichtig sein, obwohl sie nicht unmittelbar auf die eigenen Umsatzziele einzahlen.


Der Anspruch des „Trusted Advisor“ funktioniert nur, wenn technische und wirtschaftliche Grenzen offen angesprochen werden. Ein technischer Presales-Experte verliert seinen Wert, wenn der Kunde jede Empfehlung als Upselling interpretiert. Gerade deshalb gehört auch Optimierung zur Rolle: Korn nennt beispielsweise Fabric-Kapazitäten oder semantische Modelle, bei denen nicht mehr Verbrauch, sondern eine bessere Nutzung des Vorhandenen die richtige Antwort sein kann.


Power BI und Fabric: technische Tiefe ohne Delivery-Verantwortung

An mehreren Stellen wird deutlich, wie technisch die Rolle trotz Presales werden kann. Korn und Obst diskutieren Performance, Fabric-Kapazitäten, semantische Modelle, Migrationen und Architekturentscheidungen. Microsofts aktuelle Dokumentation zeigt, wie breit dieses Feld inzwischen ist: Power BI ist eine Kernkomponente von Fabric; Fabric selbst verbindet verschiedene Daten- und Analytics-Workloads über OneLake.


Auch die Optimierung von Power BI ist kein rein oberflächliches Reporting-Thema. Microsoft unterscheidet Optimierung auf Ebene der Datenquellen, Datenmodelle, Visualisierungen und Umgebung – inklusive Kapazitäten und Gateways. Wenn ein Solution Engineer technische Blocker analysiert oder einen PoC baut, kann das deshalb sehr tief in Architektur und Modellierung hineinreichen.


Technische Tiefe ist nicht dasselbe wie dauerhafte Projektverantwortung. Ein Data Solution Engineer kann zeigen, wie etwas funktionieren kann, Architekturentscheidungen challengen und technische Risiken reduzieren. Wer danach Datenpipelines, semantische Modelle, Governance, Deployment-Prozesse und den Betrieb dauerhaft verantwortet, braucht jedoch ein eigenes Team oder Umsetzungspartner.


Was Unternehmen realistisch erwarten können

Für Entscheider lässt sich die Rolle auf vier Erwartungen herunterbrechen. Erstens: Nutze den Data Solution Engineer, wenn eine technische Entscheidung noch nicht belastbar ist und Microsoft-Expertise helfen kann. Zweitens: Nutze Demos und PoCs, um kritische Annahmen früh zu testen. Drittens: Erwarte keine unbegrenzte kostenlose Projektkapazität – die Ressourcen werden nach Kunden- und Geschäftswirkung priorisiert. Viertens: Plane die Übergabe in die Umsetzung von Anfang an mit.


Genau hier lohnt sich eine saubere Datenstrategie. Wer Zielbild, Use Cases, Verantwortlichkeiten und Prioritäten nicht geklärt hat, kann auch mit sehr guter Herstellerunterstützung in Einzelentscheidungen hängen bleiben. Der Solution Engineer kann Orientierung geben; die Verantwortung für die eigene Datenplattform und deren nachhaltigen Betrieb bleibt beim Unternehmen. Für wiederkehrende Architektur- und Umsetzungsfragen kann später auch laufendes Data-&-Analytics-Sparring sinnvoller sein als eine punktuelle Presales-Unterstützung.

Fazit

Der Data Solution Engineer bei Microsoft sitzt bewusst zwischen Vertrieb, Beratung und Technik. Alexander Korn und Lukasz Obst beschreiben eine Rolle, die Kundenprobleme versteht, Architektur diskutiert, Demos und PoCs baut und technische Entscheidungen absichert – aber nicht als dauerhaftes kostenloses Implementierungsteam gedacht ist.


Die vielleicht wichtigste Erkenntnis ist deshalb nicht, welche Technologien ein Solution Engineer kennt. Wichtiger ist die Übergabe: Wann ist eine technische Entscheidung ausreichend validiert, wer setzt sie produktiv um und wer trägt danach Verantwortung für Betrieb, Governance und Weiterentwicklung? Wer diese Fragen früh beantwortet, nutzt Microsofts Expertise deutlich effektiver.

Der nächste sinnvolle Schritt

Sinnvoll ist es zuerst zu klären, welche Use Cases, Verantwortlichkeiten und Plattformbausteine wirklich zusammengehören. Mit dem Data Strategy Check könnt ihr die nächsten Data-Schritte strukturiert priorisieren, bevor aus einzelnen technischen Entscheidungen ein unübersichtliches Gesamtbild entsteht.


Wenn du Power BI strukturiert aufsetzen oder bestehende Lösungen verbessern willst, unterstützen wir dich mit:


So wird aus einem funktionierenden Bericht eine belastbare Analytics-Lösung.

bottom of page