In der IT begegnen uns Berufsbezeichnungen, die vertraut klingen und dennoch erstaunlich wenig darüber verraten, was jemand tatsächlich tut. Consultant, System Engineer, System Architect, Solution Architect, Technical Lead oder Principal Consultant: Hinter diesen Titeln können sich sehr unterschiedliche Tätigkeiten, Kompetenzen und Verantwortlichkeiten verbergen.
Gerade im Umfeld von Microsoft 365 ist die Abgrenzung schwierig. Ein Consultant konfiguriert SharePoint, ein Engineer entwickelt ein technisches Zielbild, ein Architect begleitet Workshops und spricht mit der Geschäftsführung. Das ist keineswegs ein Zeichen falsch verteilter Aufgaben. Gute Fachleute bewegen sich häufig über die Grenzen ihrer Stellenbeschreibung hinaus.
Problematisch wird es, wenn wir aus einer Bezeichnung automatisch auf Kompetenz, Entscheidungsmacht oder Stellung im Unternehmen schließen. Denn eine Rolle beschreibt zunächst einen Schwerpunkt. Sie ist kein verlässlicher Maßstab dafür, wie gut jemand seine Arbeit beherrscht.
Drei Rollen, drei Perspektiven auf dasselbe Problem
Am einfachsten lässt sich der Unterschied an einem gemeinsamen Vorhaben zeigen: Ein Unternehmen möchte sein Intranet modernisieren. Die Technik soll erneuert werden, Informationen sollen leichter auffindbar sein und die Plattform soll langfristig funktionieren.
| Rolle | Leitfrage | Verantwortungsschwerpunkt |
|---|---|---|
| Consultant | Welches Problem lösen wir und welchen Nutzen soll die Lösung bringen? | Beratung, Anforderungsverständnis, Optionen, Handlungsempfehlung |
| System Engineer | Wie setzen wir die Lösung zuverlässig um und halten sie funktionsfähig? | Technische Realisierung, Automatisierung, Fehleranalyse, Betriebsfähigkeit |
| System Architect | Wie sind die Systemkomponenten aufgebaut und wie spielen sie zusammen? | Systemstruktur, technische Prinzipien, Abhängigkeiten, Qualitätsanforderungen |
Diese Fragen sind typische Schwerpunkte, keine exklusiven Zuständigkeiten. Ein Engineer kann bei der Konzeption führen. Ein Consultant kann selbst implementieren. Ein Architect muss verstehen, was im Betrieb tatsächlich machbar ist. Die Abgrenzung wird erst dann sinnvoll, wenn wir zusätzlich klären, wer für welches Ergebnis verantwortlich ist.
Consultant: das richtige Problem verstehen
Ein guter Consultant übersetzt nicht einfach Kundenwünsche in eine Liste von Funktionen. Er untersucht, was hinter diesen Wünschen steht, welche Interessen aufeinandertreffen und woran sich der Erfolg messen lässt. Bei einem Intranetprojekt geht es daher auch um Kommunikation, Informationsverantwortung, Suchverhalten, Governance und die Bereitschaft der Organisation, bestehende Arbeitsweisen zu verändern.
Der Consultant bewertet Alternativen, macht Zielkonflikte sichtbar und entwickelt Empfehlungen. Das verlangt Fachwissen, wirtschaftliches Verständnis und die Fähigkeit, auch unbequeme Punkte anzusprechen. Beratung erschöpft sich nicht im Moderieren von Workshops oder im Erstellen von Präsentationen. Sie muss Entscheidungen verbessern.
System Engineer: aus einem Konzept eine belastbare Lösung machen
Ein System Engineer bringt technische Lösungen in die Realität. In Microsoft 365 kann das die Konfiguration von SharePoint und Teams, das Einrichten von Identitäts- und Berechtigungskonzepten, die Automatisierung der Site-Bereitstellung oder die Integration weiterer Systeme bedeuten.
Damit ist Engineering deutlich mehr als das Abarbeiten einer vorgegebenen Konfiguration. Gute Engineers beurteilen technische Risiken, erkennen widersprüchliche Anforderungen und verbessern Entwürfe anhand ihrer Umsetzungserfahrung. Wer im Betrieb die Folgen einer Entscheidung tragen muss, sollte bereits beim Design gehört werden.
Auch die Unterscheidung zwischen System Engineer und Administrator ist nicht überall trennscharf. Im üblichen Sprachgebrauch liegt beim Administrator häufig mehr Gewicht auf dem laufenden Betrieb, beim Engineer stärker auf Aufbau, Weiterentwicklung und Automatisierung. In konkreten Organisationen können beide Tätigkeiten in einer Person zusammenkommen.
System Architect: technische Entscheidungen in Zusammenhang bringen
Ein System Architect betrachtet die Struktur eines Systems: seine Komponenten, Schnittstellen, Abhängigkeiten sowie Anforderungen an Sicherheit, Wartbarkeit, Leistung und Erweiterbarkeit. Beim Intranetprojekt kann er beispielsweise festlegen, wie Sites strukturiert, Berechtigungen vererbt oder abgegrenzt und Provisionierungsprozesse technisch eingebunden werden.
Architektur ist dabei keine besonders elegante Form der Dokumentation. Ihr Wert zeigt sich in Entscheidungen, die spätere Änderungen erleichtern und technische Sackgassen vermeiden. Ein tragfähiger Architekturentwurf berücksichtigt auch Einschränkungen: Budget, vorhandene Systeme, Fähigkeiten des Teams und die Kosten des späteren Betriebs.
Ein Architect besitzt aber nicht automatisch die letzte Entscheidungshoheit. Architekturvorgaben können durch ein Gremium, einen Product Owner, Sicherheitsverantwortliche oder andere Entscheidungsstrukturen bestätigt werden. Wer entscheidet, ist eine Frage der Governance und nicht des Titels allein.
Consulting schafft Entscheidungsgrundlagen. Engineering schafft technische Realität. Architektur schafft Zusammenhang und Orientierung.
Alle drei tragen zur Qualität der Lösung bei. Keine der drei Disziplinen ist automatisch wichtiger oder höhergestellt.
Und was ist mit Solution, Cloud und Enterprise Architects?
Der Begriff Architect wird für unterschiedliche Betrachtungsräume verwendet. Der Enterprise Architect verbindet Geschäftsstrategie, Prozesse, Informationsflüsse und die übergreifende Technologieentwicklung einer Organisation. Ein Solution Architect gestaltet eine konkrete End-to-End-Lösung über mehrere Systeme und Disziplinen hinweg. Ein System Architect vertieft die Struktur eines bestimmten Systems oder einer klar abgegrenzten Systemlandschaft.
Ein Cloud Architect wiederum richtet seinen Blick besonders auf Cloud-Dienste, Plattformdesign, Identitäten, Netzwerke, Sicherheit und Betrieb. Diese Bezeichnung beschreibt eher eine technologische Domäne als eine eigene hierarchische Stufe. Cloud Architects können zugleich als Solution Architects arbeiten. Die Praxis passt selten in ein sauberes Organigramm.
| Architekturrolle | Typischer Betrachtungsraum | Beispiel |
|---|---|---|
| Enterprise Architect | Unternehmensweite Zusammenhänge | Wie passen Digital Workplace, Fachanwendungen, Daten und Unternehmensstrategie zusammen? |
| Solution Architect | Vollständige, fachlich abgegrenzte Lösung | Wie greifen Intranet, Suche, Identitäten, Inhalte und Integrationen ineinander? |
| System Architect | System und seine technischen Komponenten | Wie wird die SharePoint-Landschaft strukturiert und erweitert? |
| Cloud Architect | Cloud-Technologien und Plattformprinzipien | Wie werden Identitäten, Sicherheit, Cloud-Dienste und Betriebsanforderungen abgestimmt? |
Die Grenzen sind bewusst durchlässig. Ein kleines Projekt benötigt möglicherweise keinen eigenen Architect für jede dieser Perspektiven. In einer komplexen Organisation kann die Trennung dagegen sinnvoll sein, weil unterschiedliche Entscheidungen über mehrere Teams hinweg koordiniert werden müssen.
Die Rollen, die in solchen Vergleichen häufig fehlen
Bei einer Intranetmodernisierung sind Beratung, Engineering und Architektur notwendig, aber selten ausreichend. Ein Business Analyst präzisiert Anforderungen und Prozesse. Ein User-Experience- oder Informationsarchitektur-Spezialist beschäftigt sich mit Navigation, Verständlichkeit und Auffindbarkeit. Security- und Compliance-Fachleute bewerten Schutzbedarf und regulatorische Anforderungen. Ein Developer schafft Erweiterungen und Schnittstellen, wenn Standardfunktionen nicht ausreichen.
Ebenso wichtig sind Rollen, deren Ergebnis nicht in einer technischen Konfiguration sichtbar wird. Ein Adoption- oder Change-Consultant begleitet die tatsächliche Veränderung von Arbeitsweisen. Ein Product Owner priorisiert Anforderungen und verantwortet den Wert eines Produkts innerhalb des vereinbarten Mandats. Ein Project Manager steuert Termine, Budget, Risiken und Abhängigkeiten. Ein Service Owner sorgt dafür, dass eine Plattform nach dem Projekt nachhaltig als Dienst geführt wird.
Hinzu kommen Technical Leads, die im Team technische Richtung und Qualität koordinieren, sowie spezialisierte DevOps- und Platform Engineers für Automatisierung und Bereitstellungsprozesse. Solche Rollen sind keine Dekoration eines großen Projektplans. Sie machen Arbeit sichtbar, die sonst leicht zwischen den Zuständigkeiten verschwindet.
Das bedeutet nicht, dass jedes Projekt fünfzehn unterschiedliche Personen braucht. Eine Person kann mehrere Rollen übernehmen. Entscheidend ist, dass die jeweiligen Aufgaben bewusst zugewiesen werden und niemand stillschweigend annimmt, ein anderer werde sie schon erledigen.
Fachrolle und Karrierestufe sind zwei verschiedene Fragen
Ein besonders hartnäckiges Missverständnis entsteht, wenn Jobtitel zugleich Fachgebiet und Karrierelevel beschreiben sollen. Consultant, Engineer und Architect benennen vor allem einen Tätigkeitsschwerpunkt. Junior, Senior und Principal sollen dagegen häufig Erfahrung, Selbstständigkeit, Einfluss und Verantwortungsumfang beschreiben.
Ein Senior Engineer kann technische Standards über mehrere Teams hinweg prägen. Ein neuer Solution Architect kann zunächst unter fachlicher Begleitung arbeiten. Ein Principal Consultant kann ohne disziplinarische Führungsfunktion wichtige strategische Entscheidungen vorbereiten. Und ein Teamleiter muss nicht der technisch stärkste Mensch in seinem Team sein.
| Fachlicher Schwerpunkt | Mögliche Entwicklungsstufen |
|---|---|
| Consulting | Junior → Consultant → Senior → Principal |
| Engineering | Junior → Engineer → Senior → Principal |
| Architektur | Architect → Senior → Lead / Principal |
Illustratives Modell, keine allgemein gültige Titelnorm. Führungslaufbahnen können parallel dazu verlaufen.
Die eigentliche Frage lautet daher: Wie komplex sind die Probleme, die jemand eigenständig lösen kann? Welchen Entscheidungsspielraum hat die Person? Wie weit reichen die Folgen ihrer Entscheidungen? Und wie gut befähigt sie andere? Erst solche Kriterien machen Entwicklung nachvollziehbar.
Wenn Titel wichtiger werden als Verantwortung
Unklare Rollen sind nicht bloß ein kosmetisches Problem der Personalabteilung. Sie können Projekte wirtschaftlich belasten. Wenn niemand die fachliche Zielsetzung verbindlich klärt, wird möglicherweise eine technisch saubere Lösung für das falsche Problem gebaut. Wenn Architekturentscheidungen ohne Umsetzungserfahrung getroffen werden, entstehen unnötige Komplexität und Betriebsaufwand. Wenn wiederum alle nur ihren einzelnen Arbeitsschritt sehen, fehlt die Verantwortung für das Gesamtergebnis.
Auch im Recruiting haben Titel ihre Grenzen. Wer einen „Senior Microsoft 365 Consultant“ sucht, kann damit eine strategisch beratende Persönlichkeit, einen technisch versierten Implementierer oder eine Kombination aus beidem meinen. Bewerber und Unternehmen können denselben Titel lesen und ganz unterschiedliche Erwartungen damit verbinden. Das Risiko liegt weniger in einer falschen Bezeichnung als in einer unpräzisen Beschreibung dessen, was tatsächlich gebraucht wird.
Das gilt ebenso für Karrierewege. Eine Organisation, die fachlichen Aufstieg nur über den Wechsel in die Architektur oder Führung ermöglicht, sendet ein problematisches Signal: Wer exzellentes Engineering leistet, müsse seine eigentliche Stärke verlassen, um weiterzukommen. Damit kann man genau jene Menschen verlieren, auf deren Können anspruchsvolle Projekte angewiesen sind.
Wie ich ein Microsoft-365-Team strukturieren würde
Für ein Competence Center mit Schwerpunkt Intranet und Collaboration würde ich kein starres Titelgebäude errichten. Sinnvoller erscheint mir ein überschaubares Modell aus fachlichen Schwerpunkten, transparenten Entwicklungsstufen und klaren Entscheidungsrechten.
Im Consulting braucht es Menschen, die Kundenbedürfnisse verstehen, Lösungswege entwickeln und Veränderung begleiten. Im Engineering braucht es tiefe technische Kompetenz für Konfiguration, Entwicklung, Integration und Betriebsfähigkeit. Architekturkompetenz verbindet einzelne Entscheidungen zu einer tragfähigen Gesamtlösung. Je nach Portfolio ergänzen Spezialisten für Adoption, Governance, Security oder User Experience das Team.
Seniorität würde ich anhand des tatsächlichen Beitrags beurteilen: Selbstständigkeit, Komplexität, Qualität der Entscheidungen, Verantwortung für Ergebnisse und Unterstützung anderer. Nicht daran, wie häufig jemand das Wort „Strategie“ verwendet oder wie selten er noch eine PowerShell-Konsole öffnet.
Und ich würde für jedes größere Vorhaben vier Dinge ausdrücklich klären: Wer verantwortet den fachlichen Nutzen? Wer trägt die technische Umsetzungsverantwortung? Wer sorgt für konsistente Architekturentscheidungen? Wer sichert Betrieb und Weiterentwicklung nach der Übergabe? Rollen dürfen sich überschneiden. Verantwortung sollte es nicht unbemerkt tun.
Der Wert einer Rolle zeigt sich im Ergebnis
Beratung, Engineering und Architektur sind unterschiedliche professionelle Perspektiven auf gemeinsame Aufgaben. Ein guter Consultant darf technisch tief sein. Ein guter Engineer darf mitgestalten. Ein guter Architect sollte die Umsetzung nicht aus dem Blick verlieren. Gerade in kleineren und mittelgroßen Teams sind diese Überschneidungen häufig eine Stärke.
Ich halte deshalb wenig davon, aus Berufsbezeichnungen eine verdeckte Rangordnung zu bauen. Mich interessiert stärker, welche Verantwortung ein Mensch tatsächlich übernimmt, wie fundiert seine Entscheidungen sind und welchen Beitrag er zum Erfolg des Kunden und des Teams leistet.
Klare Rollen schaffen Orientierung. Gute Zusammenarbeit entsteht aber erst, wenn wir Verantwortung gemeinsam denken und Leistung unabhängig vom Titel anerkennen.
Quellen und Einordnung
Die Rollenbeschreibungen sind eine praxisorientierte Interpretation, keine universell verbindlichen Berufsdefinitionen. Zur fachlichen Einordnung:
- SFIA 9 – Skills Directory: Kompetenzfelder wie Consultancy (CNSL), Solution Architecture (ARCH), Systems Design (DESN), Systems Integration and Build (SINT) sowie Enterprise and Business Architecture (STPL).
- SFIA 9 – Summary Chart: Differenzierung von Kompetenzen über verschiedene Verantwortungsniveaus.
- SFIA 9 – Systems Integration and Build: Engineering umfasst je nach Verantwortungsniveau auch Standards, Führung und strategische Entscheidungen.
- Microsoft Learn – Functional Consultant: Fachliche Beratung als Verbindung zwischen Geschäftsproblemen und technischen Lösungen.
