SharePoint On-Premises denken, Teams nutzen – ein architektonischer Spagat

4. Februar 2026

Warum SharePoint-Architektur heute neu gedacht werden muss

Wer sich intensiver mit SharePoint Server on-premises beschäftigt hat, kennt den Anspruch, den dieses Produkt über viele Jahre an Administrator:innen und Architekt:innen gestellt hat. SharePoint war kein Werkzeug, das man nebenbei eingeführt hat. Bereits frühe Designentscheidungen – etwa zur Struktur von Webanwendungen, Websitesammlungen oder Content-Datenbanken – hatten langfristige Auswirkungen auf Skalierbarkeit, Sicherheit und Governance.

Diese Architekturorientierung war kein Selbstzweck. Sie war notwendig, um eine Plattform zu betreiben, die Inhalte, Prozesse und Zusammenarbeit über Jahre hinweg stabil tragen sollte. Planung, Dokumentation und klare Zuständigkeiten waren integraler Bestandteil jedes ernsthaften SharePoint-Projekts.

Beobachtungen aus der Praxis: Teams verändert den Blick auf SharePoint

In aktuellen Seminaren und Projekten zeigt sich jedoch ein deutlich verändertes Bild. Microsoft Teams ist für viele Organisationen der primäre Einstiegspunkt in Zusammenarbeit, Dateiablage und Kommunikation. SharePoint tritt dabei kaum noch sichtbar in Erscheinung – obwohl es technisch weiterhin eine zentrale Rolle spielt.

Teams erzeugt automatisch SharePoint-Websites, bindet Dokumentbibliotheken ein und nutzt Berechtigungen, ohne dass diese Schritte bewusst geplant werden. Aus Sicht vieler Benutzer:innen entsteht der Eindruck, als ob Teams Inhalte magisch organisiert und auffindbar macht. Die darunterliegende Architektur bleibt verborgen.

Diese Abstraktion senkt Einstiegshürden, verändert aber zugleich das Verständnis für Verantwortung, Struktur und Governance.

Ziel dieses Beitrags: Orientierung statt Nostalgie

Dieser Beitrag verfolgt bewusst keinen nostalgischen Blick auf frühere SharePoint-Zeiten. Ziel ist es vielmehr, klassische Architekturkonzepte verständlich einzuordnen und ihre Relevanz im heutigen Microsoft-365-Kontext zu bewerten.

Anfänger:innen sollen verstehen, was im Hintergrund tatsächlich passiert, wenn mit Teams gearbeitet wird. Fortgeschrittene Leser:innen erhalten eine fachliche Einordnung, welche Architekturprinzipien weiterhin gelten – und welche sich grundlegend verschoben haben.

Damit entsteht die Grundlage für eine sachliche Diskussion: Nicht SharePoint oder Teams, sondern Architekturdenken versus implizite Plattformlogik.

SharePoint Server On-Premises – Architektur, Hierarchie und Verantwortung

SharePoint Server on-premises war von Beginn an als Plattform konzipiert, nicht als abgeschlossene Anwendung mit klar definiertem Nutzungsszenario. Der technische Betrieb erforderte – ähnlich wie bei anderen Microsoft-Backoffice-Produkten – ein fundiertes Verständnis von Infrastruktur, Sicherheitsmodellen und Datenhaltung. Gleichzeitig ging SharePoint jedoch deutlich über eine reine Systembereitstellung hinaus.

Bereits frühe Architekturentscheidungen wirkten sich unmittelbar auf Organisation, Zusammenarbeit und Governance aus. SharePoint-Architektur spiegelte damit immer auch die Struktur des Unternehmens wider. Entscheidungen waren selten rein technisch, sondern fast immer strategisch motiviert.

Bottom-up-Produkte: Exchange als Gegenbeispiel

Klassische Serverprodukte wie Exchange Server folgen einem überwiegend bottom-up geprägten Bereitstellungsmodell. Die Administration installiert und konfiguriert die Plattform, sorgt für Sicherheit, Stabilität und Performance. Der funktionale Rahmen ist durch Microsoft weitgehend vorgegeben.

Benutzer:innen passen sich diesem Funktionsumfang an. Ein intensiver fachlicher Austausch zwischen Administration und Anwender:innen ist hilfreich, aber nicht zwingend erforderlich, um das Produkt erfolgreich zu betreiben. Die Rollen sind klar getrennt, Verantwortlichkeiten eindeutig definiert.

SharePoint als Top-down-Produkt

Dieses Bereitstellungsmuster lässt sich auf SharePoint nicht übertragen. Wird SharePoint lediglich technisch bereitgestellt, bleibt eine zentrale Frage unbeantwortet: Wie soll die Organisation mit dieser Plattform arbeiten?

Ohne Zielbilder, Nutzungsszenarien und organisatorische Leitplanken entsteht keine produktive Umgebung, sondern lediglich eine leere Infrastruktur. SharePoint erfordert daher einen top-down geprägten Ansatz, bei dem fachliche Anforderungen die technische Umsetzung steuern.

Die Autowerkstatt als Metapher für fehlende Führung

Ein anschaulicher Vergleich ist der Bau einer neuen Autowerkstatt auf der grünen Wiese. Die Halle ist modern ausgestattet, alle Werkzeuge sind vorhanden, die Eröffnung wird angekündigt. Werden am ersten Tag lediglich die Tore geöffnet und die Autofahrer:innen ohne Anleitung, Struktur oder Verantwortlichkeiten sich selbst überlassen, ist der Misserfolg absehbar.

Einzelne Arbeiten an den Fahrzeugen –einfach, oder schon komplexer – mögen gelingen, andere scheitern. Vor allem bleibt unklar, ob individuelle Erfolge auch im Gesamtkontext tragfähig sind, ob Ordnung gewahrt bleibt und ob Qualität gesichert wird. Genau diese Situation entsteht häufig bei unstrukturierten SharePoint-Einführungen.

Websitesammlungs-Administration als verbindendes Element

SharePoint-Projekte gelingen nur dann nachhaltig, wenn technisches Know-how und fachliche Praxis zusammengeführt werden. An dieser Stelle kommt der Rolle der Websitesammlungs-Administrator:innen besondere Bedeutung zu.

Sie bewegen sich im Spannungsfeld zwischen Plattformverständnis und organisatorischen Anforderungen. Diese Dialektik ist Voraussetzung für tragfähige SharePoint-Lösungen – eine Aufgabe, die weder eine rein technisch agierende Administration noch fachlich isolierte Anwender:innen allein leisten können.

Spannungsfeld Cloud und Teams

Diese bewusste Planungs- und Führungsnotwendigkeit steht heute zunehmend im Kontrast zur Nutzung von SharePoint im Kontext von Cloud und Microsoft Teams. Dort wird SharePoint häufig auf das Prinzip reiner Datenablage reduziert.

Dieser Spannungsbogen bildet die Grundlage für die weitere Diskussion und leitet direkt zu der Frage über, wie tragfähig klassische SharePoint-Prinzipien in einer stark abstrahierten Teams- und Copilot-Welt noch sind.

Architektur verstehen: Webanwendungen, Websitesammlungen und Websites im Überblick

Um die spätere Diskussion rund um SharePoint Online und Microsoft Teams sachlich einordnen zu können, lohnt zunächst ein strukturierter Blick auf die klassischen architektonischen Grundbausteine von SharePoint Server on-premises. Diese bilden das mentale Referenzmodell, an dem sich viele heutige Konzepte – bewusst oder unbewusst – weiterhin orientieren.

Im Kern folgt SharePoint einer klaren hierarchischen Gliederung. Webanwendungen bilden die technische Einstiegsebene und definieren, unter welchen URLs und Sicherheitskontexten SharePoint erreichbar ist. Innerhalb dieser Webanwendungen werden Websitesammlungen angelegt, die jeweils einen eigenen administrativen und sicherheitsrelevanten Rahmen bilden. Darunter strukturieren Websites die eigentlichen Inhalte und Zugriffsmodelle.

Diese Ebenen sind nicht nur logische Container, sondern verkörpern unterschiedliche Verantwortlichkeiten, Berechtigungsgrenzen und Governance-Entscheidungen. Gerade diese bewusste Trennung war ein zentrales Merkmal klassischer SharePoint-Architekturen und prägte Planung, Betrieb und Nutzung über viele Jahre hinweg.

Die folgenden Abschnitte beleuchten diese drei Ebenen im Detail. Sie schaffen damit die fachliche Grundlage, um später bewerten zu können, wie stark sich diese Konzepte im Kontext von SharePoint Online und Microsoft Teams verändert haben – und welche Prinzipien weiterhin Bestand haben.

Webanwendungen: Fundament der SharePoint-Server-Architektur

In SharePoint Server on-premises sind Webanwendungen keine abstrakten Container, sondern konkret realisierte technische Konstrukte, die mehrere Infrastrukturebenen miteinander verknüpfen. Das Verständnis dieses Zusammenspiels ist elementar für den Aufbau und den stabilen Betrieb einer SharePoint-Farm.

Beim Erstellen einer Webanwendung werden stets drei zentrale Komponenten miteinander verbunden:

  • Eine IIS-Website: Sie stellt die HTTP- oder HTTPS-Endpunkte bereit und definiert die erreichbaren URLs.
  • Ein dedizierter IIS-Anwendungspool: Dieser kapselt den Ausführungskontext der Webanwendung und bestimmt Identität, Ressourcenisolierung und Sicherheitskontext.
  • Eine SharePoint-Konfigurations- und Inhaltsanbindung an SQL Server: Die Webanwendung selbst speichert Konfigurationsinformationen, während Inhalte später über Websitesammlungen in Content-Datenbanken abgelegt werden.

Diese Kopplung macht deutlich, dass Webanwendungen immer auch Infrastrukturentscheidungen sind. Änderungen lassen sich nur eingeschränkt und oft nicht ohne Nebenwirkungen durchführen.

Ein wesentliches Architekturmerkmal von SharePoint Server war zudem die Möglichkeit, eine Webanwendung über mehrere IIS-Websites bereitzustellen. Mithilfe von Zonen und Alternate Access Mappings konnten unterschiedliche URLs definiert werden, etwa für:

  • internes Intranet (Kerberos, Windows-Authentifizierung)
  • Extranet-Zugriffe (Claims oder Formularauthentifizierung)
  • administrative Zugriffe mit erhöhten Sicherheitsstandards

So ließ sich ein identischer Inhaltsbestand unter verschiedenen Sicherheits- und Zugriffskonzepten bereitstellen. Diese Flexibilität war mächtig, erforderte jedoch saubere Planung und ein tiefes Verständnis der zugrunde liegenden Architektur.

Genau an dieser Stelle zeigt sich, warum SharePoint Server kein Produkt für Trial and Error war, sondern von Beginn an ein architekturgetriebenes System.

Websitesammlungen: Übergabe von Verantwortung und Governance

Mit der Erstellung einer Webanwendung ist die Aufgabe der SharePoint-Administration im klassischen Sinne zunächst erfüllt. Ab diesem Punkt verschiebt sich der Fokus weg von der technischen Plattform hin zur strukturellen, organisatorischen und inhaltlichen Verantwortung. Diese Verantwortung manifestiert sich in der Websitesammlung.

Die Websitesammlung stellt in SharePoint Server on-premises die zentrale Sicherheits- und Verwaltungseinheit dar. Sie definiert einen abgeschlossenen Berechtigungskontext und bildet die Grundlage für alle darunterliegenden Websites. Innerhalb einer Webanwendung können mehrere Websitesammlungen existieren, jeweils mit eigener Struktur, eigenem Berechtigungsmodell und eigener inhaltlicher Ausrichtung.

An dieser Stelle erfolgt ein bewusster Rollen- und Verantwortungsübergang. Während die SharePoint-Administration lediglich den technischen Rahmen bereitstellt, übernehmen Websitesammlungs-Administrator:innen ab jetzt die operative Steuerung. Zu ihren Aufgaben gehören unter anderem:

  • die Gestaltung der inhaltlichen Struktur
  • die Vergabe und Pflege von Berechtigungen
  • die Verwaltung von Features und Vorlagen
  • die Umsetzung fachlicher Governance-Vorgaben

Die Rolle der Websitesammlungs-Administration ist dabei keineswegs trivial. Sie erfordert sowohl technisches Grundverständnis als auch organisatorische Kompetenz. Fehler in der Berechtigungsstruktur, unkontrollierte Sonderrechte oder fehlende Konzepte für Wachstum und Pflege führten in der Praxis häufig zu schwer wartbaren Umgebungen.

Auch die Zuordnung zu Content-Datenbanken unterstreicht die Bedeutung der Websitesammlung. Sie war nicht nur ein logischer Container, sondern zugleich eine Einheit für Skalierung, Backup und Wiederherstellung. Architekturentscheidungen auf dieser Ebene hatten somit direkte Auswirkungen auf Betrieb und Wartung.

Diese klare Trennung von Plattformbetrieb und fachlicher Verantwortung war ein prägendes Merkmal klassischer SharePoint-Architekturen – und bildet einen wichtigen Kontrast zur heutigen, stark automatisierten Erstellung von Sites im Kontext von Microsoft Teams.

Websites: Faktische Berechtigungsgrenzen und bewährte Praxis

Websites sind in SharePoint Server on-premises die praktisch relevanten Berechtigungsgrenzen. Zwar erlaubt SharePoint technisch eine sehr feingranulare Vergabe von Rechten – auf Listen-, Bibliotheks- oder sogar Elementebene –, doch hat sich dieses Vorgehen in der Praxis nur eingeschränkt bewährt.

Feingranulare Berechtigungen erhöhen die Komplexität erheblich. Sie erschweren Transparenz, Nachvollziehbarkeit und Wartbarkeit und führen langfristig häufig zu schwer analysierbaren Berechtigungsstrukturen. Insbesondere bei personellen Wechseln oder Audits zeigt sich, dass solche Konstrukte kaum noch sauber aufzulösen sind.

Aus diesem Grund galt in klassischen SharePoint-Architekturen eine klare Empfehlung: Unterschiedliche Berechtigungsanforderungen sollten über separate Sub-Websites abgebildet werden.

Dieses Vorgehen hatte mehrere Vorteile:

  • klare Trennung von Verantwortlichkeiten
  • saubere Vererbung innerhalb einer Website
  • bessere Wartbarkeit und Dokumentierbarkeit
  • konsistente Governance-Strukturen

Die Website fungierte damit als organisatorischer und sicherheitsrelevanter Container, während Listen und Bibliotheken primär der inhaltlichen Strukturierung dienten.

Mit dem Übergang zu SharePoint Online und insbesondere mit dem Einsatz von Microsoft Teams muss dieses etablierte Muster jedoch neu bewertet werden. Teams erzeugt standardmäßig eine flache Struktur, bei der Inhalte häufig in einer einzigen Website organisiert werden. Unterschiedliche Zugriffsszenarien werden dabei oft über Kanäle, private Kanäle oder geteilte Bibliotheken abgebildet – nicht über klassische Sub-Websites.

Damit stellt sich zwangsläufig die Frage, ob das frühere Prinzip eine Berechtigungsanforderung – eine Website in der heutigen Plattformrealität noch tragfähig ist oder ob neue Governance-Modelle erforderlich sind. Genau diese Fragestellung bildet einen zentralen Übergang zur weiteren Betrachtung von SharePoint Online und Teams.

Exkurs: Die Entwicklung von SharePoint Server – von IIS-Erweiterung zur Kollaborationsplattform

Die Anfänge: Windows SharePoint Services als IIS-Erweiterung

Die Ursprünge von SharePoint liegen in den Windows SharePoint Services (WSS), einer kostenfreien Erweiterung des Internet Information Services. Ziel war es, einfache Team-Websites, Listen und Dokumentbibliotheken bereitzustellen, eng integriert in Windows Server und Active Directory.

In dieser Phase stand nicht Architektur im Vordergrund, sondern funktionale Zusammenarbeit. SharePoint war leichtgewichtig, pragmatisch und bewusst kein eigenständiges Serverprodukt.

Portal- und Content-Management-Wurzeln

Parallel zu WSS entwickelte Microsoft mit dem SharePoint Portal Server und dem Microsoft Content Management Server (MCMS) zwei Stränge, die später zusammengeführt wurden. Der Content Management Server adressierte klassische Web-Content-Szenarien wie Veröffentlichungsworkflows, Versionierung und redaktionelle Freigaben.

Mit SharePoint 2007 ging MCMS vollständig in SharePoint auf. Dieser Schritt war strategisch entscheidend: SharePoint wurde damit nicht nur Kollaborations-, sondern auch Enterprise-Content-Management-Plattform. Intranet, Internet und Dokumentenmanagement rückten technisch zusammen.

SharePoint 2007 und 2010: Plattform, Identität und soziale Konzepte

Mit SharePoint Server 2007 und stärker noch mit SharePoint Server 2010 etablierte Microsoft SharePoint als zentrale Unternehmensplattform. Architektur, Governance und Erweiterbarkeit rückten in den Mittelpunkt.

Gleichzeitig entstanden Konzepte, die weit über klassische Dokumentenablage hinausgingen:

  • MySite als persönliche Arbeits- und Identitätsfläche
  • Profilinformationen, Tags und Aktivitätsfeeds
  • erste soziale Interaktionen innerhalb der Plattform

MySite war dabei mehr als persönlicher Speicher. Es verband Identität, Inhalte und Zusammenarbeit. In der Cloud wurde dieses Konzept später konsequent weiterentwickelt – heute kennt man es als OneDrive.

Soziale Erweiterungen: Von SharePoint zu Yammer

Mit zunehmender Bedeutung sozialer Interaktion versuchte Microsoft, SharePoint um entsprechende Funktionen zu erweitern. Aktivitätsfeeds, Likes und Diskussionen wurden ergänzt, erreichten jedoch nie die gewünschte Akzeptanz.

Die strategische Antwort war die Integration von Yammer (heute integriert in Viva Engage) als separates soziales Netzwerk. Auch hier zeigt sich ein wiederkehrendes Muster: SharePoint fungierte als stabile Plattform, während spezialisierte Dienste darübergelegt wurden. Dieses Prinzip findet sich später in Microsoft Teams erneut.

Reifephase und strategische Verschiebung

Die Versionen SharePoint Server 2013, 2016 und 2019 markieren eine Phase der Konsolidierung. Technisch wurde SharePoint stabiler, skalierbarer und stärker auf Hybrid-Szenarien ausgerichtet. Gleichzeitig verlagerte Microsoft funktionale Innovation zunehmend in die Cloud. Neue Benutzeroberflächen, moderne Kollaborationsfunktionen und Integrationen entstanden primär in SharePoint Online.

Mit der Einführung von SharePoint Server Subscription Edition (SE) setzt Microsoft diesen Kurs konsequent fort. SharePoint SE ist kein funktionaler Neuanfang, sondern eine strategische Weiterführung der bewährten Serverplattform. Der Fokus liegt klar auf:

  • langfristiger Wartbarkeit
  • Sicherheits- und Compliance-Anforderungen
  • kontinuierlicher Aktualisierung über das Abonnementmodell
  • technischer Nähe zu SharePoint Online, ohne Funktionsgleichheit zu versprechen

SharePoint Server SE positioniert sich damit bewusst als stabile On-Premises-Grundlage für Organisationen mit regulatorischen, betrieblichen oder strategischen Anforderungen an lokale Datenhaltung. Innovation im Sinne neuer Nutzungskonzepte oder Benutzererlebnisse ist hingegen nicht mehr das primäre Ziel.

Diese Rolle verdeutlicht den strategischen Wandel:
SharePoint Server bleibt relevant, verliert jedoch endgültig die Funktion des Innovationstreibers. Diese Rolle übernehmen SharePoint Online, Copilot und insbesondere Microsoft Teams, die als sichtbare Schicht über einer zunehmend abstrahierten Plattform agieren.

Gerade dieser Umstand macht SharePoint SE zu einem wichtigen Referenzpunkt in der heutigen Diskussion. Es ist die konsequente Fortführung eines architekturgetriebenen Produkts in einer Welt, die zunehmend auf Automatisierung und implizite Strukturen setzt.

Historische Einordnung und bleibende Wirkung

Die Entwicklung von SharePoint erklärt, warum das Produkt bis heute als architektur- und konzeptgetrieben wahrgenommen wird. Viele seiner Grundprinzipien entstanden in einer Zeit, in der Plattformen bewusst entworfen, strukturiert eingeführt und über Jahre hinweg stabil betrieben werden mussten. Planung, Rollenverteilung und Governance waren keine Ergänzung, sondern integraler Bestandteil jeder SharePoint-Implementierung.

Diese Herkunft prägt das Verständnis vieler Administrator:innen und Architekt:innen bis heute. SharePoint wurde nicht als fertige Lösung konsumiert, sondern als Werkzeug verstanden, das erst durch konzeptionelle Arbeit seinen eigentlichen Wert entfaltet. Die Plattform zwang Organisationen dazu, sich mit Struktur, Verantwortung und Nutzung auseinanderzusetzen.

Auch wenn sich technische Rahmenbedingungen und Bereitstellungsmodelle verändert haben, wirken diese Denkweisen fort. Sie bilden einen wichtigen Referenzrahmen, um heutige Plattformentscheidungen nicht nur funktional, sondern auch organisatorisch und strategisch zu bewerten.

SharePoint Online – vertraute Begriffe, veränderte Kontrolle

Auf den ersten Blick wirkt SharePoint Online vertraut. Begriffe wie Webanwendung, Websitesammlung oder Website sind mitunter weiterhin präsent und suggerieren eine inhaltliche Nähe zur On-Premises-Welt. Tatsächlich orientiert sich SharePoint Online auch technisch an denselben Grundprinzipien. Die Art und Weise, wie diese Konzepte heute wirken und gesteuert werden können, hat sich jedoch grundlegend verändert.

In SharePoint Online sind die bekannten Ebenen nicht mehr Ergebnis bewusster Architekturentscheidungen innerhalb der Organisation, sondern Bestandteil eines zentral gesteuerten Software-as-a-Service-Modells. Webanwendungen existieren weiterhin als architektonisches Konstrukt, entziehen sich jedoch vollständig dem administrativen Zugriff. URLs, Zugriffspfade, Sicherheitsmechanismen und Skalierung liegen ausschließlich in der Verantwortung von Microsoft.

Damit verschiebt sich Kontrolle auf eine neue Ebene. Architektur wird nicht mehr gestaltet, sondern vorausgesetzt. Die verbleibenden Steuerungsmöglichkeiten beginnen erst unterhalb dieser Schicht – bei Websitesammlungen, Berechtigungen und Nutzungsmustern – und sind selbst dort stark automatisiert.

Der Fokus verlagert sich folglich weg von klassischer Architekturplanung hin zu Governance, Nutzungskonzepten und Integration. Wer SharePoint Online verstehen möchte, muss weniger fragen, wie die Plattform aufgebaut ist, sondern wie Verantwortung und Ordnung in einer weitgehend abstrahierten Umgebung hergestellt werden können.

Websitesammlungen in der Cloud: Automatisierung ersetzt Platzierungslogik

Websitesammlungen existieren auch in SharePoint Online weiterhin als zentrale strukturelle Einheit. Ihre Entstehung folgt jedoch nicht mehr einer bewussten Architektur- oder Platzierungsentscheidung, sondern ist in der Regel automatisiert und ereignisgesteuert.

Typische Auslöser für die Erstellung einer neuen Websitesammlung sind:

  • das Anlegen einer Microsoft 365 Gruppe
  • das Erstellen eines Teams
  • die Nutzung vordefinierter Vorlagen oder Dienste innerhalb von Microsoft 365

Damit verändert sich die Bedeutung der Websitesammlung grundlegend. Die klassische Frage, wo eine Websitesammlung sinnvoll angesiedelt wird und wer die damit verbundene Verantwortung übernimmt, stellt sich in vielen Szenarien nicht mehr. Websitesammlungen entstehen on demand, häufig ohne explizite Beteiligung der IT und ohne vorgelagertes Nutzungskonzept.

Diese Automatisierung reduziert Komplexität und beschleunigt Zusammenarbeit. Gleichzeitig verschiebt sich Verantwortung:
Governance ist nicht mehr implizit durch Struktur gegeben, sondern muss explizit durch Regeln, Rollen und Prozesse definiert werden.

Damit markiert die Websitesammlung in SharePoint Online nicht mehr den Beginn bewusster Architekturarbeit, sondern den ersten sichtbaren Punkt einer vollständig abstrahierten Plattformlogik – eine Entwicklung, die sich auf der darunterliegenden Webanwendungsebene konsequent fortsetzt.

Webanwendungen in SharePoint Online: Architektur vorhanden, Zugriff entzogen

Auch in SharePoint Online existiert weiterhin eine Webanwendungs-ähnliche Architektur, die funktional vergleichbar mit SharePoint Server on-premises ist. SharePoint Online basiert ebenfalls auf klaren Trennungsebenen für URLs, Authentifizierung, Mandantenisolierung und Servicegrenzen. Diese Ebenen sind jedoch vollständig Teil des Software-as-a-Service-Modells und damit ausschließlich durch Microsoft steuerbar.

Für Administrator:innen bedeutet dies einen grundlegenden Rollenwechsel. Während Webanwendungen in SharePoint Server aktiv geplant, erstellt und konfiguriert wurden, existiert in SharePoint Online kein administrativer Zugriff mehr auf diese Ebene. Weder Authentifizierungszonen noch Alternate Access Mappings oder IIS-bezogene Konfigurationen sind sichtbar oder beeinflussbar.

Diese Einschränkung ist kein technischer Mangel, sondern eine bewusste Designentscheidung. Im SaaS-Modell übernimmt Microsoft die vollständige Verantwortung für:

  • Verfügbarkeit und Skalierung
  • Sicherheit und Mandantentrennung
  • Authentifizierungs- und Zugriffspfade
  • Betriebs- und Patch-Management

Damit entfällt für Kund:innen nicht nur die operative Kontrolle, sondern auch die Möglichkeit, Webanwendungen als architektonisches Gestaltungsmittel einzusetzen.

Die Konsequenz ist deutlich: Architektur wird in SharePoint Online nicht mehr an der obersten Ebene gestaltet, sondern beginnt faktisch erst bei der Websitesammlung. Selbst dort sind Steuerungsmöglichkeiten gegenüber dem On-Premises-Modell deutlich reduziert.

Dieser Verlust an Zugriff ist gleichzeitig Voraussetzung für die Vorteile des Cloud-Modells. Automatisierung, hohe Verfügbarkeit und globale Skalierung sind nur möglich, weil Microsoft die vollständige Kontrolle über diese Architekturebene behält. Für Organisationen bedeutet dies jedoch, dass klassische Architekturentscheidungen durch Governance, Richtlinien und Nutzungskonzepte ersetzt werden müssen.

Gerade dieser Umstand markiert einen zentralen Unterschied zwischen SharePoint Server und SharePoint Online – und bereitet den Boden für eine Teams-zentrierte Nutzung, in der Architektur vollständig implizit entsteht.

Berechtigungen und Rollen: Vereinfachung mit strukturellen Nebenwirkungen

Mit dem Wechsel zu SharePoint Online verändert sich auch das Berechtigungsmodell grundlegend. An die Stelle fein abgestufter, hierarchisch geplanter Rollenmodelle treten vereinfachte, gruppenbasierte Rollen, die mandantenweit konsistent eingesetzt werden:

  • Besitzer:innen
  • Mitglieder
  • Gäste

Diese Rollen sind eng mit Microsoft 365 Gruppen verknüpft und wirken dienstübergreifend – etwa in SharePoint, Teams und Exchange. Der Vorteil dieses Ansatzes liegt in der einheitlichen Benutzererfahrung und der reduzierten administrativen Komplexität. Berechtigungen lassen sich schneller vergeben, nachvollziehen und plattformweit anwenden.

Gleichzeitig geht mit dieser Vereinfachung ein Teil der bewussten Steuerbarkeit klassischer SharePoint-Architekturen verloren. Differenzierte Zugriffskonzepte, fein granulierte Verantwortlichkeiten oder langfristig geplante Strukturen lassen sich nur noch eingeschränkt abbilden.

Für Organisationen mit hohen Anforderungen an Compliance, klare Rollentrennung oder nachhaltige Informationsarchitektur entsteht damit ein Spannungsfeld zwischen Einfachheit und Kontrolle, das nicht technisch, sondern organisatorisch aufgelöst werden muss.

SharePoint Online als Fundament, nicht als Oberfläche

In der täglichen Nutzung tritt SharePoint Online zunehmend in den Hintergrund. Benutzer:innen arbeiten selten direkt mit der SharePoint-Oberfläche, sondern greifen über andere Dienste auf Inhalte zu – allen voran Microsoft Teams.

SharePoint übernimmt dabei primär grundlegende Plattformfunktionen:

  • Dokumenten- und Metadatenverwaltung
  • Durchsetzung von Sicherheits- und Berechtigungsmodellen
  • technische Basis für APIs, Suche und Integrationen

Diese Rolle ist technisch essenziell, jedoch bewusst wenig sichtbar. SharePoint entwickelt sich vom aktiven Arbeitswerkzeug zur stabilen Hintergrundplattform, auf der andere Dienste aufsetzen und ihre Funktionalität entfalten.

Gerade diese Unsichtbarkeit macht SharePoint Online strategisch bedeutsam – und erklärt, warum Architekturwissen weiterhin relevant bleibt, auch wenn es nicht mehr direkt angewendet wird.

Übergang zu Teams: Architektur wird implizit

Diese Entwicklung bereitet den Boden für Microsoft Teams als neue Orchestrierungsebene. Teams bündelt Kommunikation, Zusammenarbeit und Dateien in einer Oberfläche und abstrahiert die zugrunde liegende SharePoint-Architektur nahezu vollständig.

Damit stellt sich zwangsläufig die Frage, welche Rolle klassische Architekturprinzipien künftig noch spielen – und ob implizite Plattformlogik langfristig tragfähig ist.

Exkurs: SharePoint-Dienstanwendungen – Shared Services als stilles Rückgrat

Das Prinzip der Shared Services in SharePoint

Ein zentrales Architekturmerkmal von SharePoint Server war über viele Jahre das Konzept der Dienstanwendungen. Diese folgten dem Prinzip der Shared Services: Funktionalitäten wurden nicht mehrfach innerhalb einzelner Websites oder Websitesammlungen bereitgestellt, sondern zentral als Dienst für die gesamte Farm oder definierte Teilbereiche.

Dienstanwendungen entkoppelten fachliche Funktionen von konkreten Websites. Sie ermöglichten Skalierung, Wiederverwendung und konsistente Nutzung über organisatorische Grenzen hinweg. SharePoint wurde dadurch nicht nur zur Inhaltsplattform, sondern zu einer Service-orientierten Architektur.

Welche Funktionen über Dienstanwendungen bereitgestellt wurden

Über Dienstanwendungen ließen sich in SharePoint Server unter anderem folgende zentrale Funktionen abbilden:

  • Managed Metadata Service zur zentralen Verwaltung von Taxonomien
  • Search Service Application für unternehmensweite Suche
  • User Profile Service für Identitäten, Profile und soziale Informationen
  • Business Data Connectivity zur Anbindung externer Systeme
  • Secure Store Service für sichere Anmeldeinformationen

Diese Dienste wirkten stets websitesammlungsübergreifend. Sie stellten sicher, dass Informationen wie Begriffe, Profile oder Suchindizes nicht isoliert gepflegt wurden, sondern organisationsweit konsistent blieben.

Verantwortung und Governance bei Dienstanwendungen

Dienstanwendungen waren klassischerweise klar in der Verantwortung der SharePoint-Administration verortet. Anders als Websites oder Inhalte waren sie nicht für Endanwender:innen bestimmt, sondern bildeten die infrastrukturelle Grundlage für Zusammenarbeit.

Gerade hier zeigte sich die Trennung zwischen Plattformbetrieb und fachlicher Nutzung besonders deutlich. Fehlerhafte Konfigurationen wirkten sich nicht lokal, sondern plattformweit aus. Entsprechend hoch war der Anspruch an Planung, Dokumentation und Governance.

Dienstanwendungen in SharePoint Online: Abstraktion statt Abschaffung

Mit dem Übergang zu SharePoint Online verschwanden Dienstanwendungen nicht, sie wurden jedoch weitgehend abstrahiert. Administrator:innen haben keinen direkten Zugriff mehr auf deren Bereitstellung oder Skalierung. Dennoch sind viele dieser Konzepte weiterhin vorhanden und aktiv genutzt.

Ein besonders sichtbares Beispiel ist die Taxonomie. Der Managed Metadata Service existiert auch in SharePoint Online und bildet weiterhin die Grundlage für:

  • einheitliche Begriffe
  • Metadatenbasierte Navigation
  • konsistente Klassifizierung von Inhalten

Ähnliches gilt für Suche, Benutzerprofile oder Compliance-nahe Dienste. Die Verantwortung für Betrieb und Skalierung liegt nun bei Microsoft, die konzeptionelle Nutzung bleibt jedoch Aufgabe der Organisation.

Einordnung im Kontext moderner Zusammenarbeit

Dienstanwendungen verdeutlichen, dass SharePoint auch in der Cloud mehr ist als reine Datenablage. Viele der Funktionen, die Teams heute selbstverständlich nutzt, basieren auf genau diesen plattformweiten Services.

Der Unterschied liegt weniger in der Existenz dieser Dienste, sondern in ihrer Sichtbarkeit und Steuerbarkeit. Während sie On-Premises explizit geplant und betrieben wurden, wirken sie in SharePoint Online im Hintergrund.

Gerade dieses Wissen hilft, moderne Plattformentscheidungen besser einzuordnen. Auch wenn Architektur nicht mehr gestaltet wird, bleibt sie vorhanden – nur in anderer Form.

Microsoft Teams – Orchestrator statt Plattform

Microsoft Teams hat sich in vielen Organisationen zum zentralen Einstiegspunkt für Zusammenarbeit entwickelt. Chats, Besprechungen, Dateien und Apps werden in einer Oberfläche gebündelt. Für Benutzer:innen entsteht der Eindruck einer geschlossenen Plattform, die Zusammenarbeit vollständig abbildet.

Aus technischer Sicht ist Teams jedoch kein eigenständiges System, sondern eine Orchestrierungsschicht. Inhalte werden nicht in Teams selbst gespeichert, sondern über bestehende Microsoft-365-Dienste bereitgestellt. Teams abstrahiert diese Zusammenhänge bewusst und reduziert sie auf eine konsistente Benutzererfahrung.

Diese Abstraktion ist einer der Hauptgründe für die hohe Akzeptanz von Teams, verändert jedoch zugleich das Architekturverständnis in Organisationen.

Was beim Erstellen eines Teams tatsächlich entsteht

Wird ein neues Team angelegt, werden im Hintergrund mehrere Ressourcen automatisch erstellt und miteinander verknüpft. Dazu gehören unter anderem:

  • eine Microsoft 365 Gruppe als identitäts- und berechtigungsgebendes Element
  • eine SharePoint-Website für Dateien und Inhalte
  • ein Exchange-Postfach für Gruppenkommunikation und Kalender
  • optional weitere Dienste wie Planner oder OneNote

Diese Ressourcen entstehen ohne explizite Architekturentscheidung durch die Administration. Der Prozess ist standardisiert, reproduzierbar und stark automatisiert. Genau hier unterscheidet sich Teams grundlegend von klassischen SharePoint-Bereitstellungsmodellen.

Die Rolle der Microsoft 365 Gruppe: Historisch gewachsenes Kommunikationsfundament

Die Microsoft 365 Gruppe – die ausschließlich im Cloud-Kontext verfügbar ist – bildet heute das zentrale Bindeglied zwischen Microsoft Teams, SharePoint und Exchange. Ihre Bedeutung wird dabei häufig auf Teams reduziert, tatsächlich existiert die Gruppe jedoch unabhängig von Teams und funktioniert vollständig auch ohne dessen Einsatz.

Konzeptionell steuert die Microsoft 365 Gruppe unter anderem:

  • Mitgliedschaften und Rollen
  • Zugriff auf Dateien und Kalender
  • Sichtbarkeit und Zusammenarbeit innerhalb des Mandanten

Die Idee der Microsoft 365 Gruppe ist nicht mit Teams entstanden, sondern geht auf eine langjährige technische und konzeptionelle Verzahnung von Exchange und SharePoint zurück. Bereits in früheren Versionen – etwa mit den Websitepostfächern in SharePoint und Exchange 2013 – verfolgte Microsoft das Ziel, gemeinsame Inhalte, E-Mails und Dokumente enger zusammenzuführen und gruppenbasiert nutzbar zu machen.

Mit der Microsoft 365 Gruppe wurde dieses Konzept weiter abstrahiert und vereinheitlicht. Die Gruppe stellt seitdem eine dienstübergreifende Identitäts- und Berechtigungseinheit dar, die von verschiedenen Workloads genutzt werden kann – etwa von SharePoint Online, Exchange Online, Planner oder OneNote. Microsoft Teams greift später genau auf dieses Fundament zurück und nutzt es als Kommunikations- und Berechtigungsbasis.

Berechtigungen werden damit nicht mehr primär auf Website- oder Websitesammlungsebene gedacht, sondern gruppenbasiert und plattformübergreifend umgesetzt. Dieses Modell vereinfacht Verwaltung und Nutzung erheblich, reduziert jedoch die Granularität klassischer SharePoint-Konzepte.

Die Microsoft 365 Gruppe ersetzt SharePoint-Berechtigungen dabei nicht vollständig, sondern überlagert sie mit einem einheitlichen, mandantenweiten Ansatz, der bewusst auf Konsistenz und Automatisierung ausgelegt ist. Genau diese Überlagerung erklärt, warum klassische SharePoint-Strukturen im Teams-Kontext zunehmend in den Hintergrund treten, technisch jedoch weiterhin unverzichtbar bleiben.

Dateien in Teams: SharePoint als funktionales Fundament für unterschiedliche Kommunikationspfade

Microsoft Teams unterscheidet sehr bewusst zwischen unterschiedlichen Kommunikations- und Zusammenarbeitsszenarien. Diese Differenzierung spiegelt sich unmittelbar in der Art wider, wie Dateien in SharePoint abgelegt werden. SharePoint fungiert dabei nicht als konzeptionell gestaltete Informationsplattform, sondern als technisches Rückgrat für Speicherung, Berechtigungen und Compliance.

Dateien aus Standardkanälen eines Teams werden in einer gemeinsamen Dokumentbibliothek der zugehörigen SharePoint-Website gespeichert. Die Kanalstruktur wird dabei über Ordner abgebildet. Kommunikation und Inhalte bleiben eng gekoppelt, ohne dass Benutzer:innen mit SharePoint-Strukturen konfrontiert werden.

Private Kanäle verfolgen einen anderen Ansatz. Sie erzeugen jeweils eine eigene SharePoint-Websitesammlung mit separatem Berechtigungsmodell. Damit wird ein klar abgegrenzter Kommunikationsraum geschaffen, der technisch isoliert ist – sowohl hinsichtlich Zugriff als auch Verwaltung. Geteilte Kanäle folgen einem ähnlichen Prinzip, um organisationsübergreifende Zusammenarbeit zu ermöglichen.

Diese Architektur verdeutlicht eine zentrale Verschiebung: SharePoint wird in Teams nicht mehr als gestaltbares Intranet- oder Kollaborationskonzept verstanden, sondern primär als:

  • Speicherplattform für Dateien
  • Durchsetzungsinstanz für Berechtigungen
  • Grundlage für Aufbewahrung, Compliance und eDiscovery

Für Benutzer:innen bleibt diese Trennung weitgehend unsichtbar. Aus administrativer Perspektive entstehen jedoch neue Herausforderungen, insbesondere im Hinblick auf:

  • Konsistenz von Berechtigungsmodellen
  • Lifecycle-Management verteilter Websitesammlungen
  • Auffindbarkeit von Inhalten über Kanal- und Teamgrenzen hinweg
  • Governance in stark fragmentierten Ablagestrukturen

SharePoint ist damit weiterhin technisch zentral, wird jedoch funktional auf seine Rolle als unsichtbares Fundament reduziert. Die konzeptionelle Verantwortung verlagert sich von der Plattform hin zu Nutzungsmustern und Governance-Vorgaben – ein Paradigmenwechsel gegenüber klassischen SharePoint-Architekturen.

Implizite Architektur, gruppenbasierte Steuerung und neue Verantwortung

Mit Microsoft Teams verschiebt sich Architektur von einer bewusst gestalteten Struktur hin zu einer implizit entstehenden Plattformlogik. Zentrale Ressourcen wie SharePoint-Websites, Exchange-Postfächer oder Berechtigungsmodelle werden nicht mehr explizit geplant, sondern automatisiert über Microsoft 365 Gruppen erzeugt und gesteuert. Nutzungsmuster ersetzen klassische Architekturentscheidungen.

Diese gruppenbasierte Steuerung entlastet die Administration operativ erheblich. Standardisierte Prozesse, konsistente Berechtigungsmodelle und eine einheitliche Benutzererfahrung senken die Einstiegshürden für Zusammenarbeit. Gleichzeitig verlagert sich Verantwortung: weg von der technischen Detailgestaltung, hin zur Definition von Regeln, Rahmenbedingungen und Leitplanken.

Ohne klare Governance entstehen in kurzer Zeit stark fragmentierte Strukturen. Zahlreiche Teams, Gruppen und zugehörige SharePoint-Websitesammlungen wachsen parallel, oft ohne abgestimmtes Lifecycle-Management oder konsistentes Berechtigungskonzept. Die technische Plattform bleibt stabil, organisatorische Ordnung hingegen nicht automatisch.

Damit verschiebt sich die zentrale Fragestellung. Es geht weniger darum, ob SharePoint oder Teams das richtige Werkzeug ist. Entscheidend ist vielmehr, wie Organisationen Verantwortung, Struktur und Compliance in einer Umgebung sicherstellen, in der Architektur nicht mehr geplant, sondern aus Nutzung heraus erzeugt wird.

Exkurs: Die Entwicklung von Microsoft Teams – von Unified Communications zur Kollaborationsplattform

Vor Teams: Fragmentierte Zusammenarbeit im Microsoft-Ökosystem

Vor der Einführung von Microsoft Teams war Zusammenarbeit im Microsoft-Umfeld funktional verteilt. Kommunikation, Inhalte und Identität waren zwar vorhanden, jedoch auf unterschiedliche Produkte aufgeteilt.

Skype for Business Online stellte über Jahre hinweg zentrale Funktionen für Chat, Präsenz sowie Audio- und Videokonferenzen bereit. Diese Dienste waren technisch ausgereift, jedoch stark auf synchrone Kommunikation fokussiert. Inhalte, Dokumente und kontextbezogene Zusammenarbeit spielten dabei nur eine untergeordnete Rolle.

Parallel dazu etablierten sich Exchange und SharePoint als tragende Säulen für E-Mail, Kalender und Dokumentenmanagement. Zusammenarbeit entstand damit über mehrere Werkzeuge hinweg – funktional leistungsfähig, konzeptionell jedoch fragmentiert.

Der Paradigmenwechsel: Kommunikation im Kontext von Gruppen

Mit der Einführung der Microsoft 365 Gruppe begann Microsoft bereits vor Teams, diese Fragmentierung aufzulösen. Die Gruppe stellte erstmals eine dienstübergreifende Identitäts- und Berechtigungseinheit bereit, die Exchange, SharePoint, Planner und weitere Dienste miteinander verband.

Diese Entwicklung knüpfte an frühere Konzepte an, etwa die Websitepostfächer in SharePoint und Exchange 2013, und verfolgte ein klares Ziel: Zusammenarbeit sollte nicht mehr um einzelne Anwendungen herum organisiert werden, sondern um Gruppen mit gemeinsamem Zweck.

Microsoft Teams setzte genau an diesem Punkt an. Teams ist keine eigenständige Plattform, sondern eine Erweiterung des Gruppenmodells um Kommunikation. Typische Skype-Funktionen wurden dabei gezielt integriert und funktional weiterentwickelt:

  • persistenter, kontextbezogener Chat
  • Audio- und Videokonferenzen
  • Präsenzinformationen
  • Besprechungen mit Kalenderanbindung

Aus einer primär inhaltsorientierten Gruppe wurde damit ein dauerhafter Kommunikations- und Arbeitsraum.

Teams als strategische Antwort auf veränderte Arbeitsmodelle

Die Einführung von Teams war zugleich eine strategische Antwort auf neue Formen der Zusammenarbeit. Persistente Chats, themenbezogene Arbeitsräume und die enge Kopplung von Kommunikation und Inhalten entsprachen zunehmend den Erwartungen moderner Arbeitsumgebungen.

Teams verband diese Anforderungen mit der bestehenden Microsoft-365-Infrastruktur. SharePoint übernahm die Rolle der Daten- und Compliance-Plattform, Exchange stellte Kalender und Postfächer bereit, die Microsoft 365 Gruppe definierte Identität und Berechtigungen. Teams bündelte diese Elemente zu einer einheitlichen Benutzeroberfläche.

Damit erklärt sich auch die starke Abstraktion: Teams macht komplexe Abhängigkeiten bewusst unsichtbar, um Zusammenarbeit niedrigschwellig zu ermöglichen.

Vom Client zur Umgebung: Teams als Raum- und Geräteplattform

Mit zunehmender Reife entwickelte sich Teams über den klassischen Desktop-Client hinaus. Konzepte wie Teams Rooms integrieren Besprechungsräume direkt in die Plattform und ersetzen traditionelle Konferenzsysteme durch eine einheitliche Teams-basierte Logik.

Geräte wie das Surface Hub verdeutlichen diesen Ansatz besonders. Teams wird hier zum zentralen Interaktionsraum für Meetings, Whiteboarding und kollaboratives Arbeiten. Software, Hardware und Raumkonzepte verschmelzen zu einem gemeinsamen Nutzungserlebnis.

Teams ist damit nicht mehr nur eine Anwendung, sondern Teil eines umfassenden Collaboration-Ökosystems.

Historische Einordnung: Warum Teams Architektur abstrahiert

Die historische Entwicklung von Teams erklärt, warum die Plattform heute so funktioniert, wie sie funktioniert. Teams ist das Ergebnis einer bewussten Zusammenführung von:

  • Echtzeitkommunikation aus Skype
  • gruppenbasierter Zusammenarbeit über Microsoft 365 Gruppen
  • Inhalts- und Dokumentenmanagement durch SharePoint

Kommunikation steht im Vordergrund, Struktur entsteht implizit. Architektur wird nicht mehr gestaltet, sondern aus Nutzung heraus erzeugt. Genau diese Herkunft macht Teams zugänglich – und zugleich erklärungsbedürftig.

Diese Spannung zwischen Einfachheit und technischer Tiefe bildet den Hintergrund für die anschließende Diskussion rund um Governance, Verantwortung und Ordnung in einer Teams-zentrierten Welt.

Governance in einer Teams-zentrierten Welt – Ordnung ohne klassische Architektur

In klassischen SharePoint-Architekturen wurde Ordnung primär durch bewusste Strukturentscheidungen hergestellt. Webanwendungen, Websitesammlungen und Websites bildeten feste Rahmen, innerhalb derer sich Nutzung bewegte. Diese Ebenen waren administrativ sichtbar, steuerbar und Teil einer expliziten Architekturplanung.

Dieser Strukturwandel beginnt jedoch nicht erst mit Microsoft Teams, sondern ist bereits beim Übergang von SharePoint Server zu SharePoint Online deutlich erkennbar. In SharePoint Online entfällt für Administrator:innen der Zugriff auf Webanwendungen vollständig. Auch die Steuerungsmöglichkeiten auf Websitesammlungsebene sind stark reduziert. Microsoft folgt hier zunehmend der Philosophie One Website, one Collection, um Komplexität zu senken und Automatisierung zu ermöglichen.

Architektur entsteht damit nicht mehr durch frei gestaltbare Hierarchien, sondern durch vordefinierte Plattformmuster. An die Stelle detaillierter Strukturplanung tritt ein modellbasierter Ansatz, bei dem Websitesammlungen häufig direkt mit konkreten Nutzungsszenarien verknüpft sind.

Mit Microsoft Teams wird diese Entwicklung konsequent fortgeführt. Struktur entsteht nicht mehr durch Planung im Vorfeld, sondern durch Regeln, Standards und Nutzungsauslöser. Governance wird damit zur vorgelagerten Disziplin. Nicht die konkrete Struktur steht im Vordergrund, sondern die Frage, unter welchen Bedingungen neue Teams, Gruppen und Inhalte entstehen dürfen.

Diese Verschiebung erfordert ein grundlegendes Umdenken: Weg von detaillierter Vorab-Architektur, hin zu klar formulierten Leitplanken, die Orientierung geben, ohne Nutzung unnötig einzuschränken.

Zentrale Governance-Fragestellungen im Teams-Kontext

Mit dem Übergang zu SharePoint Online und der weiteren Zuspitzung durch Microsoft Teams sind klassische architektonische Steuerungsmöglichkeiten weitgehend entfallen. Webanwendungen existieren nicht mehr als gestaltbare Ebene, Websitesammlungen entstehen häufig automatisiert, und Microsoft folgt zunehmend dem Prinzip eine Website pro Nutzungskontext. Damit verschiebt sich Ordnung von der Struktur- auf die Regel-Ebene.

Governance muss diese Lücke bewusst schließen. Die zentralen Fragestellungen ergeben sich nicht mehr aus der Architektur, sondern aus der Automatisierung der Plattform:

  • Wer darf Microsoft 365 Gruppen und Teams erstellen? Da jede Erstellung neue Ressourcen erzeugt, ist diese Entscheidung unmittelbar architekturwirksam.
  • Welche Namens- und Klassifizierungsregeln gelten? Ohne konsistente Konventionen verlieren automatisch erzeugte Websites und Teams schnell ihre Einordnung.
  • Wie wird der Zweck eines Teams definiert? Kurzlebige Projektarbeit, dauerhafte Zusammenarbeit und reine Kommunikationsräume benötigen unterschiedliche Governance-Vorgaben.
  • Wie wird der Lifecycle gesteuert? Archivierung, Verlängerung oder Löschung müssen geregelt sein, da Struktur nicht mehr durch Hierarchie entsteht.
  • Welche Inhalte unterliegen besonderen Compliance- und Aufbewahrungspflichten? Da SharePoint primär als Storage- und Compliance-Fundament fungiert, müssen diese Anforderungen früh berücksichtigt werden.

Diese Fragestellungen sind keine Ergänzung zur Plattform, sondern ihre notwendige Steuerung. Wo Architektur früher Orientierung bot, müssen heute Governance-Regeln Klarheit schaffen. Ohne diese Regeln entsteht zwar funktionierende Zusammenarbeit, jedoch kaum nachhaltige Ordnung.

Damit wird deutlich: Governance ist im Teams-Kontext kein administratives Beiwerk, sondern der zentrale Ersatz für verlorene architektonische Kontrolle.

Rollen und Verantwortlichkeiten neu denken

Mit dem Übergang von SharePoint Server zu SharePoint Online und weiter zu einer Teams-zentrierten Nutzung verlieren klassische Architekturrollen einen Teil ihrer bisherigen Steuerungsfunktion. Entscheidungen zu Webanwendungen, Websitesammlungen oder Strukturhierarchien werden nicht mehr explizit getroffen, sondern durch Plattformmechanismen vorgegeben. Damit verändert sich nicht nur die Technik, sondern auch das Rollenverständnis.

Die klassische SharePoint-Administration bleibt weiterhin für Stabilität, Sicherheit und Compliance verantwortlich. Ihre Rolle verschiebt sich jedoch von der aktiven Architekturgestaltung hin zur Definition und Durchsetzung von Rahmenbedingungen. Technische Kontrolle wird durch Richtlinien, Policies und Automatisierung ersetzt.

Gleichzeitig entsteht ein Bedarf an neuen, vermittelnden Rollen. Diese bewegen sich zwischen Technik und Fachbereichen und übernehmen Verantwortung dort, wo Plattformautomatik allein nicht ausreicht. Dazu gehören unter anderem:

  • Microsoft-365-Governance-Verantwortliche, die Regeln für Erstellung, Nutzung und Lifecycle von Teams und Gruppen definieren
  • fachlich verankerte Team- oder Gruppenverantwortliche, die Zweck, Struktur und Ordnung innerhalb eines Teams sicherstellen
  • Personen mit Überblick über Compliance und Aufbewahrung, die sicherstellen, dass automatisiert erzeugte Strukturen regulatorischen Anforderungen entsprechen

Diese Rollen sind kein Ersatz für die IT-Administration, sondern eine notwendige Ergänzung. Sie adressieren genau den Bereich, den klassische Architekturentscheidungen früher abgedeckt haben: Ordnung, Verantwortung und Nachhaltigkeit.

Damit wird deutlich, dass erfolgreiche Microsoft-365-Umgebungen weniger von technischer Detailsteuerung abhängen, sondern von klar definierten Zuständigkeiten. In einer automatisierten Plattform ist Verantwortung nicht implizit gegeben – sie muss bewusst zugewiesen und gelebt werden.

SharePoint bleibt zentral – vom Gestaltungselement zum Governance-Fundament

Auch in einer Teams-zentrierten Welt verliert SharePoint nicht an Bedeutung. Im Gegenteil: SharePoint bildet weiterhin das technische Rückgrat für Zusammenarbeit in Microsoft 365. Was sich verändert hat, ist nicht die Relevanz der Plattform, sondern ihre Sichtbarkeit und Rolle.

SharePoint stellt nach wie vor zentrale Funktionen bereit, unter anderem:

  • die physische Speicherung von Dokumenten und Inhalten
  • die Durchsetzung von Berechtigungen auf Dateiebene
  • die Grundlage für Aufbewahrung, Retention und eDiscovery
  • die technische Basis für Suche, Metadaten und Compliance

Während diese Aspekte früher aktiv gestaltet wurden, wirken sie heute meist im Hintergrund. SharePoint wird weniger als konzeptionelle Kollaborationsplattform wahrgenommen, sondern als verlässliche Infrastruktur, auf der andere Dienste aufsetzen.

Gerade diese Verschiebung erfordert Erfahrung. Klassisches SharePoint-Wissen ist weiterhin entscheidend, um Auswirkungen von Berechtigungsvererbung, Websitesammlungsgrenzen oder Lifecycle-Entscheidungen richtig einzuordnen. Der Unterschied liegt darin, dass diese Kenntnisse heute nicht mehr zur Strukturplanung, sondern zur Definition von Governance-Regeln genutzt werden.

Wer versteht, wie SharePoint intern arbeitet, kann auch in einer stark abstrahierten Umgebung bessere Entscheidungen treffen – etwa bei der Gestaltung von Richtlinien, der Bewertung von Kanaltypen oder der Umsetzung regulatorischer Anforderungen. SharePoint wird damit vom sichtbaren Gestaltungselement zum unsichtbaren Stabilitätsanker.

Diese Rolle ist weniger spektakulär, aber strategisch entscheidend. Ohne SharePoint als Governance- und Compliance-Fundament wäre die Flexibilität von Microsoft Teams organisatorisch nicht tragfähig.

Ordnung als kontinuierliche Aufgabe in einer automatisierten Plattform

In einer Teams-zentrierten Microsoft-365-Umgebung entsteht Struktur nicht mehr primär durch Architektur, sondern durch Nutzung. Teams, Gruppen und zugehörige SharePoint-Ressourcen werden automatisiert erstellt, wachsen organisch und verändern sich über die Zeit. Ordnung ist damit kein statischer Zustand, sondern ein laufender Prozess.

Governance lässt sich in diesem Kontext nicht einmalig definieren und anschließend abhaken. Nutzungsmuster, organisatorische Anforderungen und regulatorische Rahmenbedingungen entwickeln sich kontinuierlich weiter. Entsprechend müssen auch Regeln, Verantwortlichkeiten und Leitplanken regelmäßig überprüft und angepasst werden.

Erfolgreiche Organisationen akzeptieren, dass nicht jede Struktur im Voraus festgelegt werden kann. Stattdessen schaffen sie verlässliche Rahmenbedingungen, innerhalb derer Zusammenarbeit flexibel stattfinden darf, ohne die langfristige Ordnung zu gefährden. Automatisierung ersetzt Planung nicht, sondern verschiebt sie auf eine andere Ebene.

Damit wird deutlich: Governance ist weniger ein Kontrollinstrument als ein ermöglichender Faktor. Sie sorgt dafür, dass die technische Stärke von Microsoft Teams und die Stabilität von SharePoint nicht in unübersichtlichen Strukturen verpuffen, sondern nachhaltig wirksam werden.

SharePoint, Teams und die Zukunft der Zusammenarbeit – eine strategische Einordnung

Die Diskussion um die Zukunft von SharePoint wird häufig als Konkurrenzfrage geführt. Tatsächlich geht es jedoch weniger um ein Entweder-oder als um ein bewusstes Zusammenspiel mehrerer Ebenen. Microsoft Teams fungiert heute als primäre Benutzeroberfläche für Zusammenarbeit, während SharePoint die darunterliegende Struktur für Inhalte, Berechtigungen und Compliance bereitstellt.

Diese Rollenverteilung ist kein Zufall, sondern das Ergebnis einer langjährigen Entwicklung. SharePoint ist nicht verschwunden, sondern bewusst aus dem Vordergrund gerückt. Seine Stärke liegt nicht mehr in der direkten Interaktion, sondern in der Stabilität und Durchsetzbarkeit zentraler Regeln.

Architekturwissen bleibt relevant – aber mit neuem Fokus

Klassisches SharePoint-Wissen verliert nicht an Wert, verändert jedoch seinen Einsatzbereich. Webanwendungen, Websitesammlungen und Berechtigungsvererbung werden heute seltener aktiv gestaltet, bleiben aber entscheidend für das Verständnis von Auswirkungen automatisierter Entscheidungen.

Administrator:innen und Architekt:innen, die diese Zusammenhänge kennen, können Governance-Regeln fundierter definieren, Risiken besser einschätzen und Nutzungsmuster bewusster steuern. Architekturwissen wird damit vom Werkzeug zur analytischen Grundlage.

Von Planung zu Steuerung: Der neue Gestaltungsraum

Wo früher detaillierte Vorabplanung erforderlich war, treten heute Steuerungsmechanismen. Leitplanken, Richtlinien und Verantwortlichkeiten ersetzen starre Hierarchien. Diese Verschiebung bedeutet keinen Kontrollverlust, sondern eine Verlagerung der Kontrolle.

Erfolgreiche Organisationen nutzen diese Entwicklung, um Zusammenarbeit flexibler zu gestalten, ohne Ordnung und Compliance aus dem Blick zu verlieren. Entscheidend ist nicht die vollständige Kontrolle über jede Struktur, sondern die Fähigkeit, Rahmenbedingungen sinnvoll zu setzen.

Einordnung für die Praxis

SharePoint On-Premises zu denken und Teams zu nutzen bedeutet heute, zwei Welten miteinander zu verbinden: das architekturgetriebene Denken klassischer Plattformen und die nutzungsorientierte Logik moderner Cloud-Dienste. Dieser Spagat ist anspruchsvoll, bietet jedoch große Chancen.

Wer versteht, wie SharePoint als Fundament wirkt, kann Teams bewusster einsetzen. Wer Teams als Einstiegspunkt akzeptiert, ohne SharePoint zu ignorieren, schafft nachhaltige Strukturen. Genau in dieser Balance liegt der Schlüssel für zukunftsfähige Zusammenarbeit.

Quellenangaben

(Abgerufen am 04.02.2026)

SharePoint Architektur, Konzepte und Entwicklung

SharePoint Online, Teams und technische Zusammenhänge

Microsoft Teams – Historie, Strategie und Plattformentwicklung

SharePoint Framework, Plattform und Zukunft

Weiterlesen hier im Blog

SharePoint On-Premises denken, Teams nutzen – ein architektonischer Spagat
Kategorien: Microsoft | SharePoint | Skype | Teams
Veröffentlicht: 04. Februar 2026