Der wichtigste Satz vorweg: Matrix ist ein Protokoll, kein Produkt – und genau darin liegt der Unterschied zu jedem anderen Messenger auf Ihrer Auswahlliste. Bei Teams, Slack, Threema Work oder stashcat kaufen Sie einen geschlossenen Dienst, der Ihnen ein Konto in der Welt des Anbieters gibt. Bei Matrix betreiben Sie einen eigenen Knoten in einem Netz, das nach offen dokumentierten Regeln funktioniert, und Sie können den Client, den Server und den Betreiber austauschen, ohne Ihre Identitäten, Ihre Räume oder Ihre Gesprächsverläufe aufzugeben. Diese Konstruktion erklärt sowohl die Stärken als auch die Grenzen der Lösung.
Drei Eigenschaften beschreiben Matrix und Element treffender als jede Funktionsliste:
Für jede Entscheidung sollten Sie drei Ebenen auseinanderhalten. Die erste Ebene ist die Spezifikation: ein offen gepflegter Standard, der beschreibt, wie Server untereinander sprechen, wie Räume aufgebaut sind, wie Verschlüsselung funktioniert und wie Clients auf Server zugreifen. Diese Ebene ist herstellerneutral und wird von einer gemeinnützigen Organisation getragen, an deren Finanzierung und Weiterentwicklung mehrere Beteiligte mitwirken.
Die zweite Ebene ist der Homeserver – die Software, die Konten, Räume, Nachrichten und die Föderation verwaltet. Die bekannteste Umsetzung ist Synapse; daneben existieren weitere Implementierungen mit unterschiedlichem Reifegrad und unterschiedlichen Betriebseigenschaften. Der Homeserver ist der Teil, den Ihre IT betreibt oder betreiben lässt, und er bestimmt Skalierung, Betriebsaufwand und einen erheblichen Teil der Kosten.
Die dritte Ebene ist der Client – die Anwendung auf Rechner, Telefon oder im Browser. Element ist hier der Referenzpunkt, aber nicht die einzige Option: Es existieren alternative Clients, teils mit anderem Bedienkonzept, teils für spezielle Anforderungen wie besonders schlanke Oberflächen oder besondere Barrierefreiheitsanforderungen. Ebenso können Organisationen einen eigenen, gebrandeten Client auf Basis der offenen Codebasis bereitstellen – genau das ist der Weg, den einige große Anwender im öffentlichen Sektor gegangen sind.
Diese Dreiteilung hat eine praktische Konsequenz: Sie können jede Ebene einzeln bewerten und einzeln wechseln. Ein Betreiberwechsel ändert nicht den Client. Ein Clientwechsel ändert nicht die Daten. Ein Serverwechsel innerhalb derselben Domäne ist eine technische Migration, aber keine Neuanschaffung. Kein anderes Produkt in dieser Kategorie bietet diese Trennung.
Föderation ist der Begriff, der in Präsentationen am häufigsten fällt und im Alltag am seltensten verstanden wird. Die Analogie zur E-Mail trägt weit: Sie schreiben aus Ihrem Postfach an eine Adresse bei einer anderen Organisation, ohne dass eine der beiden Seiten ein Konto beim jeweils anderen Anbieter braucht. Genau so funktioniert Matrix – nur eben für Räume, Dateien, Sprache und Video statt für Einzelnachrichten.
Im Mittelstand entfaltet das seine Wirkung an einer sehr konkreten Stelle: der Zusammenarbeit mit Externen. Heute lösen die meisten Unternehmen das über Gastkonten in ihrer Kollaborationsplattform, über parallele Chatgruppen in einem privaten Messenger oder über E-Mail-Verteiler, die niemand pflegt. Alle drei Wege haben Nachteile: Gastkonten verursachen Verwaltungsaufwand und Lizenzfragen, private Messenger sind arbeitsrechtlich und datenschutzrechtlich heikel, E-Mail-Verteiler verlieren den Gesprächszusammenhang. Föderation löst das anders: Der Zulieferer, das Ingenieurbüro, die Behörde oder das Krankenhaus bleibt auf seinem eigenen Server und arbeitet trotzdem mit Ihnen im selben Raum.
Die ehrliche Einschränkung dazu: Föderation funktioniert nur, wenn die Gegenseite ebenfalls Matrix nutzt. Im öffentlichen Sektor, im Gesundheitswesen und in Teilen der Forschung ist das zunehmend der Fall. In einer typischen mittelständischen Lieferkette ist es das noch nicht. Rechnen Sie deshalb nicht damit, dass Föderation ab Tag eins Ihr Hauptnutzen ist – planen Sie sie als Option, die an Wert gewinnt, sobald Ihr Umfeld nachzieht. Zusätzlich lässt sich Föderation bewusst begrenzen: Viele Organisationen erlauben nur den Austausch mit ausgewählten, namentlich freigegebenen Servern statt mit dem offenen Netz.
Aus unserer Beratungspraxis passt der Matrix-Ansatz besonders gut zu vier Profilen. Erstens zu Organisationen mit einer verbindlichen Anforderung an Datenhoheit – weil eine Aufsicht, ein Auftraggeber, ein Konzernstandard oder eine Branchenvorgabe es verlangt. Zweitens zu Unternehmen, die regelmäßig mit Behörden, Kliniken, Forschungseinrichtungen oder Verteidigungskunden zusammenarbeiten und dort auf Gegenstellen treffen, die bereits auf Matrix setzen. Drittens zu Betreibern kritischer Infrastruktur, die eine Kommunikationsfähigkeit brauchen, die auch dann funktioniert, wenn ein externer Cloud-Dienst nicht erreichbar ist. Viertens zu Organisationen mit ausgeprägter Open-Source-Strategie, die den Anbieterwechsel bewusst offenhalten wollen.
Weniger gut passt der Ansatz, wenn Sie eine schlüsselfertige Kollaborationsumgebung mit tiefer Dokumentenintegration, Tabellenbearbeitung im Browser und einem breiten Anwendungsmarkt suchen und dafür keine eigene Betriebsverantwortung übernehmen möchten. In diesem Szenario sind integrierte Suiten der direktere Weg. Ebenso zurückhaltend wären wir, wenn in Ihrer IT weder Erfahrung mit dem Betrieb serverseitiger Anwendungen vorhanden ist noch Bereitschaft besteht, diese aufzubauen oder einzukaufen – dann kaufen Sie mit dem Messenger eine dauerhafte Betriebsaufgabe ein.
Die Grundlogik ist einfach: Das Protokoll und die Basisserver sind quelloffen und ohne Lizenzkosten nutzbar. Kommerziell werden Zusatzkomponenten für Verwaltung, Compliance und Skalierung, professioneller Support mit zugesagten Reaktionszeiten sowie der betreute Betrieb. Wer die Eigeninstallation wählt, zahlt statt Lizenzen mit Personalzeit; wer den betreuten Weg wählt, tauscht Betriebsaufwand gegen laufende Kosten. Beide Rechnungen können aufgehen – aber nur, wenn Sie sie vollständig aufmachen.
Für Entscheidungsgremien ist die Kombination aus quelloffenem Fundament und kommerziellem Angebot zunächst irritierend: Wenn alles offen ist, wofür zahlt man dann? Die Antwort ist präzise und für die Kalkulation wichtig. Sie zahlen nicht für Funktionen im engeren Sinne, sondern für drei Dinge: für Betriebssicherheit in Form von Support, Wartungszusagen und getesteten Aktualisierungspfaden; für Werkzeuge, die eine Installation von einer verwalteten Plattform unterscheiden – Massenbereitstellung, Richtlinien, Auswertung, Bridges, Migrationshilfen; und für Verantwortungsübernahme, also einen Vertragspartner, der im Störungsfall haftbar ist.
Das ist genau die Konstellation, die man aus anderen Open-Source-Märkten kennt: Ein freier Kern, um den herum ein Markt aus Anbietern, Dienstleistern und Betreibern entsteht. Für Sie hat das einen konkreten Vorteil, den geschlossene Produkte nicht bieten können – Sie können den Anbieter wechseln, ohne die Plattform zu wechseln. Wenn Ihr Betreiber die Konditionen verschlechtert, migrieren Sie zu einem anderen Betreiber oder in den Eigenbetrieb. Ihre Identitäten, Ihre Räume und Ihre Verläufe bleiben Ihre.
Die Kehrseite gehört ebenso genannt: Ein offenes Ökosystem ist unübersichtlicher als ein einzelnes Produkt. Es gibt mehrere Homeserver-Implementierungen, mehrere Clients, unterschiedlich gepflegte Bridges und Komponenten in sehr unterschiedlichem Reifegrad. Nicht jede Erweiterung, die es gibt, ist für den produktiven Einsatz in einem Unternehmen geeignet. Wer Matrix einführt, braucht deshalb entweder eigene Bewertungskompetenz oder einen Partner, der diese Auswahl verantwortet.
Matrix hat im DACH-Raum eine ungewöhnliche Marktposition: unauffällig im klassischen Mittelstand, aber ausgesprochen stark dort, wo Souveränitätsanforderungen verbindlich sind. Im Verteidigungsumfeld existiert seit Jahren ein auf Matrix basierender dienstlicher Messenger. In der öffentlichen Verwaltung gibt es Angebote für Bund, Länder und Kommunen, die auf demselben Standard aufsetzen und untereinander föderieren sollen. Im Gesundheitswesen ist Matrix die technische Grundlage des Messenger-Standards der Telematikinfrastruktur, über den Praxen, Kliniken und weitere Leistungserbringer kommunizieren können sollen. Im Bildungs- und Forschungsbereich betreiben zahlreiche Hochschulen und Rechenzentren eigene Instanzen.
Diese Verankerung ist für den Mittelstand aus zwei Gründen relevant, auch wenn sie zunächst nach einem fremden Markt klingt. Erstens verändert sie den Reifegrad: Anforderungen aus dem öffentlichen Sektor – Massenverwaltung, Protokollierung, Richtliniensteuerung, Zulassungsverfahren – haben das Ökosystem in Bereichen weitergebracht, in denen ein reines Community-Projekt üblicherweise schwächelt. Zweitens verändert sie das Umfeld: Wenn Ihre Auftraggeber, Ihre Aufsichtsbehörde oder Ihre Kliniken Matrix nutzen, entsteht ein Netzeffekt, der Ihnen einen Zugang eröffnet, den kein geschlossener Messenger bietet.
Gleichzeitig ist eine nüchterne Einordnung angebracht: Im breiten Mittelstand ist Matrix bislang eine Nischenentscheidung. Wer den Weg geht, tut das aus einem Grund, nicht aus Bequemlichkeit. Das erhöht die Anforderungen an die interne Begründung – Sie sollten schriftlich festhalten, welche Anforderung Sie mit dieser Entscheidung erfüllen, damit die Wahl auch zwei Jahre später gegenüber Geschäftsführung und Belegschaft erklärbar bleibt.
Lassen Sie Matrix nicht in einem generischen Funktionskatalog gegen integrierte Kollaborationssuiten antreten. Ein solcher Vergleich fällt zwangsläufig verzerrt aus, weil er Kriterien enthält, die auf Dokumentenbearbeitung, Kalender und Anwendungsmarkt zielen – Felder, in denen ein Messenger-Protokoll bewusst nichts leisten will. Umgekehrt enthalten Kataloge aus dem Sicherheitsumfeld Kriterien, die eine geschlossene Suite kaum erfüllen kann.
Sinnvoller ist ein Vergleich entlang der Fälle, die Ihre Anforderung tatsächlich begründen: die verschlüsselte Abstimmung mit einem externen Ingenieurbüro ohne Gastkonten, die Notfallkommunikation bei Ausfall der zentralen IT, der Austausch mit einer Behörde, die auf Matrix setzt, die Kommunikation einer Schichtmannschaft auf Geräten, die das Werk nicht verlassen. Wer so vergleicht, erhält ein realistisches Bild – und meist auch eine klarere Antwort darauf, ob Matrix Ihr Hauptwerkzeug wird oder eine bewusst gesetzte zweite Schiene neben einer vorhandenen Suite.
Die folgenden Bausteine machen den praktischen Alltag aus. Welche davon in Ihrer Ausbaustufe, Ihrer Client-Auswahl und Ihrem Betriebsmodell verfügbar sind und in welcher Ausprägung, sollten Sie vor der Beschaffung abgleichen – in einem offenen Ökosystem entwickelt sich der Funktionsumfang schneller und ungleichmäßiger als bei einem einzelnen Produkt.
Wenn Sie nur eine Gestaltungsentscheidung aus diesem Kapitel behalten, sollte es diese sein: Die Struktur Ihrer Räume bestimmt, ob das Werkzeug nach einem Jahr noch benutzbar ist. Ein Raum ist in Matrix keine flüchtige Gruppe, sondern ein dauerhaftes Objekt mit eigener Kennung, eigenem Rechtekonzept, eigenem Verlauf und einer Mitgliederliste, die serverübergreifend sein kann. Räume lassen sich öffentlich oder nur auf Einladung führen, in der eigenen Organisation halten oder für ausgewählte Partner öffnen.
Spaces sind die Ordnungsebene darüber. Sie bündeln Räume zu Bereichen – nach Abteilung, Standort, Projekt oder Kunde – und lassen sich verschachteln, sodass eine Hierarchie entsteht, die zur Organisation passt. Für den Betrieb ist das mehr als Kosmetik: Ein Space kann als Einstiegspunkt dienen, über den neue Mitglieder automatisch die für sie relevanten Räume finden, statt sie einzeln zugewiesen zu bekommen. Wir empfehlen, die Space-Struktur vor dem Rollout zu entwerfen und ausdrücklich festzulegen, wer Räume anlegen darf. Ein Chatwerkzeug, in dem jede Person unbegrenzt Räume erzeugt, sieht nach sechs Monaten aus wie ein ungepflegtes Dateisystem.
Threads – Diskussionsstränge innerhalb eines Raums – sind das dritte Element. Sie halten Nebendiskussionen zusammen, statt sie in den Hauptverlauf zu mischen, und sind besonders in Räumen mit vielen Mitgliedern wirksam. In der Praxis lohnt eine einfache Regel im Onboarding: Was mehr als drei Antworten braucht, wandert in einen Thread. Diese eine Konvention senkt die wahrgenommene Nachrichtenlast spürbar.
Die Verschlüsselung ist der stärkste Sicherheitsvorteil und gleichzeitig die häufigste Ursache für Rückfragen im ersten Betriebsjahr. Das Prinzip ist klar: Schlüssel liegen auf den Endgeräten, nicht auf dem Server. Wer den Server betreibt – Ihre IT oder Ihr Dienstleister – kann Nachrichteninhalte nicht mitlesen. Sichtbar bleiben Metadaten wie Zeitpunkte, Raumzugehörigkeiten und Datenmengen; diese Unterscheidung sollten Sie in der Kommunikation gegenüber Belegschaft und Mitbestimmung sauber treffen, weil sie oft verwischt wird.
Aus diesem Prinzip folgen drei praktische Konsequenzen, die Sie einplanen müssen. Erstens die Geräteverifikation: Damit ein zweites Gerät verschlüsselte Verläufe lesen kann, muss es bestätigt werden – meist über einen Abgleich von Zeichen oder Symbolen oder über eine Wiederherstellungsschlüssel. Das ist ein Schritt, den Beschäftigte verstehen müssen, sonst entsteht der Eindruck, das Werkzeug sei kaputt. Zweitens die Schlüsselsicherung: Ohne eingerichtete Sicherung ist ein verlorenes Gerät gleichbedeutend mit einem verlorenen Verlauf. Drittens die serverseitige Suche: Weil der Server die Inhalte nicht kennt, findet die Suche in verschlüsselten Räumen auf dem Gerät statt – mit den entsprechenden Grenzen bei sehr langen Verläufen und auf schwächeren Geräten.
Diese drei Punkte sind kein Argument gegen Verschlüsselung, sondern eine Aufgabe im Rollout. Unsere Empfehlung: Behandeln Sie Geräteverifikation und Schlüsselsicherung als festen Bestandteil der Ersteinrichtung, dokumentieren Sie beides in einer einseitigen Anleitung mit Bildern, und definieren Sie im Voraus, was der Servicedesk tun darf und was nicht. Der wichtigste Satz für die Anwenderkommunikation lautet: Die IT kann Ihr Passwort zurücksetzen, aber sie kann Ihre verschlüsselten Nachrichten nicht wiederherstellen.
Beim Dateiaustausch bleibt der Messenger bewusst zurückhaltend: Dateien werden angehängt, versioniert werden sie nicht. Für verbindliche Dokumente gilt deshalb dieselbe Regel wie bei jedem Chatwerkzeug – die verbindliche Fassung liegt im Dokumentensystem oder in der Dateiablage, im Chat liegt der Verweis darauf. Wer diese Regel in zwei Sätzen aufschreibt und kommuniziert, verhindert die häufigste Ursache doppelter Ablagen und veralteter Anhänge.
Die Verwaltungsebene ist der Teil, der eine Installation von einer unternehmenstauglichen Plattform unterscheidet. Dazu gehören Rollen- und Rechtestufen je Raum, Moderationswerkzeuge, organisationsweite Richtlinien – etwa, ob Verschlüsselung erzwungen wird, welche Server föderiert werden dürfen, ob Gäste zugelassen sind –, die automatisierte Bereitstellung und Deaktivierung von Konten sowie aggregierte Auswertungen zur Nutzung. Der Umfang dieser Werkzeuge unterscheidet sich deutlich zwischen der rein quelloffenen Installation und den kommerziellen Serverpaketen. Genau hier liegt in vielen Projekten die wirtschaftliche Begründung für das kommerzielle Angebot.
Vorab eine notwendige Einordnung: Der Nutzen von KI in einem Kommunikationswerkzeug liegt selten dort, wo Produktdemonstrationen ihn zeigen. Beeindruckend wirken Textgenerierung und automatische Antwortvorschläge; wirtschaftlich relevant sind Zusammenfassungen langer Verläufe, Übersetzung in mehrsprachigen Teams und die Anbindung an Abläufe, die ohnehin stattfinden. Prüfen Sie Angebote deshalb nicht danach, ob KI enthalten ist, sondern danach, welches konkrete Alltagsproblem damit kleiner wird – und zu welchem Preis an Vertraulichkeit.
Hier liegt der wichtigste Prüfpunkt dieses Kapitels. Eine Assistenzfunktion, die einen Gesprächsverlauf zusammenfasst, muss diesen Verlauf lesen können. In einem verschlüsselten Raum bedeutet das: Entweder die Verarbeitung findet auf dem Endgerät statt, oder ein Dienst wird als Teilnehmer in den Raum aufgenommen und erhält damit Zugriff auf die entschlüsselten Inhalte. Einen dritten Weg gibt es nicht, und jede Produktbeschreibung, die etwas anderes suggeriert, verdient eine Rückfrage.
Beide Wege sind vertretbar, aber sie haben unterschiedliche Folgen. Die Verarbeitung auf dem Gerät ist datenschutzrechtlich unproblematisch, aber begrenzt in Leistungsfähigkeit und Modellgröße und abhängig von der Geräteausstattung Ihrer Belegschaft. Ein Dienst als Raumteilnehmer ist leistungsfähiger, hebt aber die Vertraulichkeit gegenüber diesem Dienst auf – und zwar für alle Beteiligten des Raums, auch für externe Partner, die davon möglicherweise nichts wissen. Wenn Sie diesen Weg gehen, muss die Anwesenheit des Dienstes für alle sichtbar sein, und der Betreiber des Dienstes gehört in Ihre Datenschutzdokumentation.
Unsere Empfehlung für den Mittelstand ist pragmatisch und lässt sich in einem Satz zusammenfassen: Setzen Sie KI-Assistenz gezielt in unverschlüsselten Arbeitsräumen ein, in denen ohnehin keine sensiblen Inhalte liegen, und lassen Sie die vertraulichen Räume unangetastet. Diese Trennung ist einfacher zu erklären, einfacher zu dokumentieren und einfacher zu prüfen als jede Feinsteuerung – und sie erhält das Sicherheitsversprechen dort, wo es zählt.
Der größere und unspektakulärere Hebel liegt in klassischer Automatisierung. Weil Matrix ein offenes Protokoll mit dokumentierten Schnittstellen ist, lassen sich Bots und Anbindungen vergleichsweise einfach bauen – und zwar unabhängig davon, welchen Client Ihre Belegschaft nutzt. Ein Bot ist in Matrix schlicht ein Konto, das programmgesteuert handelt und einem Raum beitritt. Daraus entstehen Abläufe, die im Alltag spürbar Arbeit sparen.
Diese Automatisierungen sind unscheinbar und deshalb häufig nicht Teil der Auswahlentscheidung. In der Nutzungsbilanz nach einem Jahr sind sie oft der Grund, warum ein Werkzeug lebt oder eingeschlafen ist. Wir empfehlen, mindestens die Kontenbereitstellung und eine einzige, wirklich nützliche Systemmeldung von Anfang an zu automatisieren – alles andere kann nachwachsen.
Sobald ein Bot oder eine Assistenzfunktion Nachrichten verarbeitet, entsteht eine datenschutzrechtliche Frage, die vor der Aktivierung geklärt werden muss. Chatverläufe enthalten regelmäßig personenbezogene Daten: Namen, Termine, Einschätzungen zu Personen, teilweise auch Gesundheits- oder Leistungsbezüge. Wenn diese Inhalte an einen Dienst übergeben werden, ist zu klären, wer verarbeitet, wo verarbeitet wird, wie lange Daten vorgehalten werden und ob sie zum Training verwendet werden.
Vier Punkte gehören dazu in jedes Gespräch mit dem Anbieter. Erstens der Verarbeitungsort und die Frage nach Unterauftragsverarbeitern. Zweitens eine ausdrückliche Zusage, dass Ihre Inhalte nicht zum Training allgemeiner Modelle verwendet werden – nicht aus einer Marketingseite übernommen, sondern in den Vertragsunterlagen. Drittens die Sichtbarkeit: Alle Teilnehmenden eines Raums müssen erkennen können, dass ein automatisierter Teilnehmer mitliest; das gilt gegenüber der eigenen Belegschaft ebenso wie gegenüber föderierten Partnern. Viertens die Abschaltbarkeit: Können Sie einzelne Funktionen deaktivieren oder auf bestimmte Räume begrenzen, wenn Datenschutz oder Mitbestimmung das verlangen?
Die relevanten Anknüpfungspunkte gliedern sich in vier Gruppen: Bridges zu anderen Messaging-Netzen, Identitäts- und Verzeichnisdienste, Fachsysteme über Bots und Schnittstellen sowie eingebettete Anwendungen innerhalb von Räumen. Die konkrete Verfügbarkeit und der Reifegrad einzelner Anbindungen sollten Sie für Ihre Ausbaustufe und Ihr Betriebsmodell beim Anbieter verifizieren – Bridges sind der Bereich mit den größten Qualitätsunterschieden im gesamten Ökosystem.
In Migrationsprojekten sind Bridges häufig das entscheidende Werkzeug, weil sie den Umstieg entzerren. Statt einer Stichtagsumstellung, die immer Widerstand erzeugt, laufen beide Welten eine Zeit lang parallel: Die Pilotgruppe wechselt, bleibt aber über die Bridge mit den übrigen Bereichen verbunden. Erst wenn die neue Umgebung trägt, wird die Brücke abgebaut. Dieses Vorgehen senkt das Projektrisiko erheblich.
Drei Einschränkungen gehören ebenso genannt. Erstens die Vertraulichkeit: Eine Bridge muss Nachrichten entschlüsseln, um sie zu übersetzen. Damit ist die durchgehende Ende-zu-Ende-Verschlüsselung an dieser Stelle unterbrochen – Ihre Sicherheitsargumentation muss das berücksichtigen, und die Bridge selbst wird zu einer besonders schützenswerten Komponente. Zweitens der Funktionsverlust: Nicht jedes Element einer fremden Plattform lässt sich abbilden. Reaktionen, Threads, Formatierungen, Bearbeitungen oder Umfragen kommen je nach Bridge unterschiedlich gut an. Drittens die rechtliche Frage: Manche Anbieter erlauben in ihren Bedingungen keine Anbindung von außen. Klären Sie das, bevor Sie eine Bridge produktiv setzen – insbesondere bei privaten Messengern.
Dies ist der Integrationspunkt, der am stärksten über den Betriebsaufwand entscheidet – und der am häufigsten zu spät bearbeitet wird. Ein Homeserver lässt sich an gängige Anmeldeverfahren und Verzeichnisdienste anbinden, sodass Anmeldung, Gruppenzugehörigkeiten und Rechte aus einer zentralen Quelle kommen. Beschäftigte melden sich mit ihrem gewohnten Zugang an, mehrstufige Authentifizierung greift wie in anderen Anwendungen, und Konten entstehen und verschwinden automatisch mit dem Beschäftigungsverhältnis.
Klären Sie in der Einführung vier Fragen. Welches System ist die führende Quelle für Identitäten und Gruppen? Wie gelangen Änderungen dorthin, und in welchem Rhythmus werden sie übertragen? Wie werden Konten beim Austritt deaktiviert, damit keine verwaisten Zugänge zurückbleiben – und was geschieht dann mit den Räumen, in denen diese Person Verwaltungsrechte hatte? Und wie werden Beschäftigte ohne eigenes Firmenkonto behandelt, etwa in Produktion oder Logistik? Die letzte Frage wird regelmäßig übersehen und entscheidet darüber, ob ein erheblicher Teil der Belegschaft das Werkzeug überhaupt nutzen kann.
Ein zweiter Punkt betrifft die Auffindbarkeit von Personen. In einem föderierten Netz ist nicht automatisch klar, wie eine Person außerhalb der eigenen Organisation gefunden wird. Innerhalb Ihres Servers löst ein Verzeichnis das; über Servergrenzen hinweg braucht es entweder die bekannte Kennung der Gegenseite oder einen abgestimmten Weg. Für die Zusammenarbeit mit Partnern empfehlen wir, Kennungen bewusst nach einem verständlichen Schema zu vergeben und dieses Schema gegenüber Partnern zu dokumentieren.
Die Grenze liegt selten in der Technik, sondern in Aufwand und Pflege. Jede individuelle Anbindung ist ein kleines Softwareprojekt mit Lebenszyklus: Sie muss bei Änderungen im Quellsystem angepasst und bei Aktualisierungen der Plattform geprüft werden. Wir empfehlen deshalb, mit maximal zwei Anbindungen zu starten – idealerweise mit denen, die den größten sichtbaren Nutzen für die Belegschaft haben – und weitere erst zu ergänzen, wenn das Werkzeug angenommen ist.
Ehrlich benannt gehört auch, wo die Integrationstiefe hinter integrierten Suiten zurückbleibt. Wer erwartet, dass sich eine Tabelle im Chatfenster gemeinsam bearbeiten lässt, dass Kalender, Aufgaben, Dokumente und Telefonie aus einer Hand kommen und dass ein großer Anwendungsmarkt jede Nische bedient, wird die Erfahrung machen, dass ein Messenger-Protokoll diese Aufgaben bewusst nicht löst. Das ist keine Schwäche der Umsetzung, sondern eine Abgrenzung des Anspruchs – aber sie gehört in die Erwartungshaltung, bevor die Entscheidung fällt.
Matrix unterscheidet sich in vier Punkten, die entweder entscheidend sind oder gar keine Rolle spielen. Erstens Datenhoheit: Sie bestimmen Serverstandort, Betreiber und Zugriffswege. Zweitens Prüfbarkeit: Protokoll und Software sind offen und lassen sich unabhängig begutachten. Drittens Föderation: Zusammenarbeit über Organisationsgrenzen ohne Gastkonten. Viertens Anbieterbindung: Ein Wechsel des Betreibers ist möglich, ohne die Plattform zu verlassen. Wenn keiner dieser vier Punkte für Sie verbindlich ist, ist der Aufwand einer Matrix-Einführung schwer zu begründen. Ist auch nur einer davon verbindlich, dreht sich die Rechnung.
Häufig ist die richtige Antwort im Mittelstand nicht ein Entweder-oder, sondern eine bewusste Zweiteilung: die vorhandene Suite für den allgemeinen Büroalltag, Matrix als zweite Schiene für die vertraulichen und die organisationsübergreifenden Fälle. Das kostet mehr als eine einzelne Plattform, ist aber ehrlicher als der Versuch, alle Anforderungen mit einem Werkzeug zu erschlagen.
Der Unterschied liegt in der Architektur. Rocket.Chat und Mattermost sind Produkte mit einer Serverinstanz, die Ihre Organisation abbildet. Matrix ist ein Netz, in dem Ihre Instanz ein Knoten unter vielen ist. Solange Sie nur intern kommunizieren, ist dieser Unterschied theoretisch. Sobald Sie regelmäßig mit anderen Organisationen zusammenarbeiten, die ebenfalls einen eigenen Server betreiben, wird er praktisch – und dann ist er der wichtigste Unterschied überhaupt. Ein zweiter Unterschied betrifft die Verschlüsselung: Bei Matrix ist sie in privaten Räumen der Regelfall, bei den beiden anderen je nach Produkt und Konfiguration unterschiedlich tief umgesetzt.
Unsere Faustregel: Wenn Ihre Anforderung „quelloffener Slack-Ersatz im eigenen Haus“ lautet, sind Rocket.Chat und Mattermost die naheliegenderen Kandidaten. Wenn sie „souveräne Kommunikation, die auch über Organisationsgrenzen hinweg trägt und im öffentlichen Sektor anschlussfähig ist“ lautet, führt der Weg zu Matrix.
Matrix unterscheidet sich in drei Punkten. Erstens in der Offenheit: Protokoll und Software sind einsehbar, Anbieter austauschbar. Zweitens in der Föderation: Andere Organisationen können mit eigenen Servern teilnehmen, statt Konten in Ihrem System zu bekommen. Drittens in der Reichweite des Funktionsumfangs: Räume, Spaces, Bots, Bridges und eingebettete Anwendungen gehen über einen reinen sicheren Messenger deutlich hinaus. Der Preis dafür ist Komplexität – im Betrieb, in der Schulung und in der Auswahl der Komponenten.
Ein einfacher Entscheidungsweg: Brauchen Sie einen sicheren Kanal für definierte Gruppen, mit minimalem Aufwand und maximaler Klarheit? Dann sind die geschlossenen Sicherheitsprodukte stark. Brauchen Sie eine souveräne Kommunikationsplattform, die auch Fachsysteme, Automatisierung und organisationsübergreifende Zusammenarbeit trägt und die Sie langfristig nicht an einen Anbieter bindet? Dann führt der Weg zu Matrix.
Das folgende Vorgehen hat sich in Mittelstandsprojekten bewährt. Es beginnt bewusst nicht mit der Technik, sondern mit der Frage, welche Anforderung das Werkzeug erfüllen soll – denn ein Messenger ohne klaren Auftrag ist nach sechs Monaten ein leerer Raum neben der Plattform, die alle ohnehin nutzen.
Der Eigenbetrieb ist der Weg mit der größten Kontrolle und dem größten Anspruch an die eigene Organisation. Sie betreiben einen Anwendungsserver mit Datenbank, Medienspeicher, Umkehrproxy und Zertifikaten, dazu je nach Ausbau Komponenten für Konferenzen, Bridges und Verwaltung. Sie sorgen für Aktualisierungen, Sicherung, Wiederherstellungstests, Überwachung und Kapazitätsplanung. Das ist eine anteilige Personalstelle, keine Nebentätigkeit.
Zwei Punkte verdienen dabei besondere Aufmerksamkeit, weil sie in Projekten regelmäßig unterschätzt werden. Der Medienspeicher wächst schneller, als die meisten erwarten: Bilder, Videos und Dateien aus Räumen summieren sich, und in einem föderierten Netz kommen auch Inhalte aus Räumen mit externen Teilnehmenden hinzu. Legen Sie deshalb früh Regeln für Aufbewahrung und Bereinigung fest – technisch wie rechtlich. Die Datenbank ist der zweite Punkt: Die Raumhistorie ist der Kern des Systems, und ihr Wachstum bestimmt Antwortzeiten und Sicherungsdauer. Beides ist beherrschbar, aber es will beobachtet werden.
Unsere Empfehlung für den Mittelstand: Wählen Sie den Eigenbetrieb nur, wenn Sie bereits Linux- und Containerbetrieb im Haus haben, wenn Vertretungsregelungen bestehen und wenn die Bereitschaft da ist, Aktualisierungen als festen Termin einzuplanen statt als Gelegenheit. Andernfalls ist der betreute Betrieb mit eigener Domäne die wirtschaftlichere und meist auch die sicherere Wahl – Souveränität bemisst sich an der Kontrolle über Daten und Vertragsbeziehung, nicht daran, wer die Serverschränke aufschließt.
Zwischen vollständigem Eigenbetrieb und einem beliebigen Cloud-Dienst liegt ein Mittelweg, der für den Mittelstand meist der richtige ist: Ein spezialisierter Anbieter betreibt den Homeserver für Sie, in einer europäischen Region oder bei einem deutschen Rechenzentrumsbetreiber, während Sie Domäne, Nutzerverwaltung, Richtlinien und Vertragshoheit behalten. Sie geben die technische Betriebsverantwortung ab, nicht die Kontrolle über Identitäten und Daten.
Prüfen Sie bei diesem Weg fünf Punkte schriftlich. Erstens den tatsächlichen Verarbeitungsort einschließlich Sicherungen und Notfallstandort. Zweitens die Liste der Unterauftragsverarbeiter und die Regeln für deren Änderung. Drittens die Zugriffsmöglichkeiten des Betreibers auf Ihre Instanz und deren Protokollierung. Viertens die Ausstiegsbedingungen: In welcher Form und in welcher Frist erhalten Sie Ihre Daten, wenn Sie wechseln oder in den Eigenbetrieb gehen wollen? Fünftens die Zusagen zu Aktualisierungen und Sicherheitsmeldungen – gerade bei einer offenen Plattform ist der zeitnahe Einspielrhythmus ein Qualitätsmerkmal.
Ein Hinweis zur Argumentation gegenüber Datenschutz und Aufsicht: Der betreute Betrieb bei einem europäischen Anbieter mit einer Instanz, die ausschließlich Ihre Organisation bedient, ist deutlich einfacher zu begründen als ein geteilter Cloud-Dienst mit außereuropäischer Konzernmutter. Halten Sie diese Begründung schriftlich fest – sie ist der Kern Ihres Nachweises.
Zur Skalierung lässt sich qualitativ Belastbares sagen, ohne Zahlen zu erfinden. Der Ressourcenbedarf eines Homeservers hängt weniger an der reinen Nutzerzahl als an drei anderen Größen: der Zahl und Größe der Räume, dem Umfang der Föderation und der Menge der geteilten Medien. Ein Raum mit sehr vielen Mitgliedern über viele fremde Server hinweg ist deutlich aufwendiger als ein interner Raum mit derselben Mitgliederzahl. Wenn Sie große öffentliche Räume betreten, sollten Sie das bewusst tun und die Auswirkungen beobachten.
Föderation ist deshalb nicht nur eine Sicherheits-, sondern auch eine Betriebsentscheidung. Drei Einstellungen sind üblich: offene Föderation mit dem gesamten Netz, begrenzte Föderation mit namentlich freigegebenen Partnerservern oder vollständig geschlossener Betrieb. Für Organisationen mit erhöhtem Schutzbedarf ist die begrenzte Variante der pragmatische Standard – sie bewahrt den Nutzen der Zusammenarbeit mit definierten Partnern und schließt gleichzeitig unkontrollierte Verbindungen aus. Legen Sie diese Richtlinie ausdrücklich fest, statt sie als Voreinstellung stehen zu lassen.
Für die laufende Routine haben sich drei Regeln bewährt. Erstens: Führen Sie eine Liste aller Komponenten – Server, Bridges, Bots, Konferenzdienst – mit Zweck, Verantwortlichem und Notwendigkeit, und streichen Sie regelmäßig, was niemand mehr braucht. Zweitens: Betreiben Sie eine Testumgebung und spielen Sie Aktualisierungen zuerst dort ein; bei einem Werkzeug, das die ganze Belegschaft nutzt, ist eine fehlgeschlagene Aktualisierung unmittelbar sichtbar. Drittens: Prüfen Sie halbjährlich Räume, Rechte und Konten – welche Räume sind verwaist, wer hat Verwaltungsrechte ohne Grund, welche Konten gehören zu Personen, die längst gegangen sind. Diese Prüfung kostet wenige Stunden und ist gleichzeitig ein guter Nachweis, dass die Plattform nicht nur eingeführt, sondern geführt wird.
Dies ist das Szenario mit dem klarsten wirtschaftlichen Argument. Wenn Ihre Auftraggeber im Verteidigungsumfeld, in der Verwaltung, bei Bahn und Energieversorgern oder in Kliniken sitzen, dann verschieben sich deren Kommunikationsanforderungen gerade spürbar. Wo früher E-Mail und Telefon genügten, kommen zunehmend Vorgaben zur Vertraulichkeit, zur Nachvollziehbarkeit und zum Kommunikationsweg hinzu – und in einem wachsenden Teil dieses Umfelds ist Matrix die technische Grundlage.
Für Sie als Zulieferer entsteht daraus eine einfache Frage: Können Sie auf dem Kanal erreichbar sein, den Ihr Kunde nutzt, ohne dass er Ihnen ein Konto in seinem System anlegen muss? Mit einem eigenen Homeserver lautet die Antwort ja. Ohne bleibt der Umweg über Gastzugänge, die in sicherheitsrelevanten Umgebungen oft gar nicht vorgesehen sind, oder über E-Mail, die den Gesprächszusammenhang verliert.
Zwei praktische Hinweise dazu. Erstens: Klären Sie früh mit Ihren wichtigsten Kunden, ob und mit welchen Servern sie föderieren dürfen. Manche Umgebungen sind bewusst geschlossen und lassen keine externe Föderation zu – dann bringt Ihnen der eigene Server für diesen Kunden nichts, wohl aber möglicherweise für andere. Zweitens: Dokumentieren Sie Ihre Sicherheitsmaßnahmen so, dass Sie sie in einem Lieferantenaudit vorlegen können. Ein selbst betriebener oder in Ihrem Auftrag betriebener Messenger ist in solchen Prüfungen ein Aktivposten, aber nur, wenn Betrieb, Zugriffsrechte und Aufbewahrung nachvollziehbar geregelt sind.
Betreiber kritischer Infrastruktur haben eine Anforderung, die in der Auswahl gewöhnlicher Kollaborationswerkzeuge selten vorkommt: Die Kommunikation muss auch dann funktionieren, wenn etwas Grundlegendes ausgefallen ist. Wenn Ihre Kollaborationsplattform ein externer Cloud-Dienst ist, sind Sie im Störungsfall doppelt abhängig – von Ihrer eigenen Anbindung und von der Verfügbarkeit des Anbieters. Ein selbst betriebener Messenger auf eigener Infrastruktur ändert diese Rechnung.
In der Praxis geht es dabei um drei Fähigkeiten. Die erste ist die reine Erreichbarkeit: Ein Krisenstab braucht einen Kanal, der unabhängig von der üblichen Bürowelt funktioniert und dessen Zugang vorab eingerichtet und geübt ist. Die zweite ist die geordnete Alarmierung: Bots, die den Dienstplan kennen, die richtige Person ansprechen und nach definierter Zeit eskalieren, ersetzen Telefonketten, die im Ernstfall nie vollständig funktionieren. Die dritte ist die Nachvollziehbarkeit: Ein dokumentierter Verlauf, wer wann was entschieden hat, ist in der Nachbereitung eines Vorfalls Gold wert – und wird von Aufsichten zunehmend erwartet.
Unsere Empfehlung: Behandeln Sie diesen Anwendungsfall als eigenständiges Vorhaben mit eigener Übung. Ein Notfallkanal, der nie benutzt wurde, funktioniert im Ernstfall nicht, weil niemand sein Passwort kennt und die Geräte nicht verifiziert sind. Zwei Übungen im Jahr, in denen der Kanal tatsächlich genutzt wird, sind wirksamer als jede Dokumentation.
Im Anlagenbau, im Bauwesen, in der Ingenieurdienstleistung und in Forschungsverbünden arbeiten regelmäßig mehrere Unternehmen an einem Vorhaben. Heute entstehen dafür entweder Gastkonten in der Plattform des Hauptauftragnehmers – mit dem entsprechenden Verwaltungsaufwand und der unangenehmen Nebenwirkung, dass Externe Zugriff auf mehr sehen, als vorgesehen war – oder es bildet sich, was in der Praxis am häufigsten geschieht, eine Gruppe in einem privaten Messenger. Föderierte Projekträume sind die dritte Möglichkeit: Jedes Unternehmen bleibt auf seinem Server, alle arbeiten in einem Raum, die Rechte sind sauber gesetzt, und beim Projektende wird der Raum geschlossen und archiviert.
Der letzte Punkt verdient besondere Aufmerksamkeit, weil er ein reales und weit verbreitetes Problem betrifft. In Produktion, Logistik, Handwerk und Pflege läuft ein erheblicher Teil der betrieblichen Abstimmung über private Chatgruppen auf privaten Telefonen. Das ist verständlich – es funktioniert und kostet nichts –, aber es ist datenschutzrechtlich problematisch, arbeitsrechtlich unscharf und im Streitfall nicht rekonstruierbar. Ein dienstlicher Messenger mit App löst dieses Problem, aber nur unter drei Bedingungen.
Erstens die Gerätefrage: Nutzen Beschäftigte private Telefone, und auf welcher Grundlage? Das ist keine technische, sondern eine arbeitsrechtliche und mitbestimmungsrelevante Frage, und sie gehört vor den Rollout. Zweitens die Kontenfrage: Diese Gruppe hat oft keine geschäftliche E-Mail-Adresse – klären Sie Anmeldung, Kontoanlage und Ausgabe der Zugangsdaten. Drittens die Erreichbarkeit: Ein dienstlicher Messenger auf dem privaten Telefon wirft unmittelbar die Frage auf, wann jemand erreichbar sein muss und wann nicht. Diese Frage lässt sich regeln, aber nicht ignorieren. Wer sie offen lässt, bekommt entweder ein ungenutztes Werkzeug oder eine Betriebsvereinbarung im Nachgang unter unangenehmen Vorzeichen.
Zunächst zu den Kosten. Die Gesamtkosten setzen sich aus fünf Blöcken zusammen, von denen bei der quelloffenen Variante nur zwei überhaupt auf einem Angebot stehen – und der teuerste Block steht dort nie.
Diesen Kosten steht ein Nutzen gegenüber, der sich benennen lässt: ein belastbarer Kanal für vertrauliche Abstimmungen, die Ablösung privater Messenger mit ihren rechtlichen Risiken, Anschlussfähigkeit an ein behördennahes Umfeld, Handlungsfähigkeit im Störungsfall, geringere Anbieterbindung und ein Nachweis gegenüber Kunden und Aufsichten, der in Audits zählt. Wir empfehlen, diese Nutzenerwartung vor der Einführung schriftlich zu fixieren – mit zwei oder drei einfachen Messpunkten –, damit nach zwölf Monaten überprüfbar ist, ob sie eingetreten ist.
Die Kombination aus quelloffener Software, frei wählbarem Serverstandort und Ende-zu-Ende-Verschlüsselung ergibt eine Datenschutzargumentation, die in dieser Produktkategorie schwer zu übertreffen ist. Sie können belegen, wo die Daten liegen, wer Zugriff hat, welche Software läuft und dass Inhalte für den Betreiber nicht lesbar sind. Für Organisationen mit strengen Vorgaben – im behördennahen Umfeld, in regulierten Branchen, bei Betreibern kritischer Infrastruktur – ist das häufig der ausschlaggebende Punkt, und es ist ein Punkt, den geschlossene Cloud-Dienste konstruktionsbedingt nicht erreichen können.
Gleichzeitig sollten Sie vier Einschränkungen kennen, die in Marketingaussagen gern verschwinden. Erstens: Verschlüsselung schützt Inhalte, nicht Metadaten. Wer wann mit wem in welchem Raum war, ist auf dem Server sichtbar – das ist datenschutzrechtlich relevant und mitbestimmungsrelevant. Zweitens: Föderation bedeutet, dass Kopien von Rauminhalten auf den Servern der beteiligten Organisationen liegen. Wer einen Raum mit einer externen Organisation teilt, teilt auch Daten mit deren Server – das ist gewollt, muss aber in der Verarbeitungsdokumentation abgebildet sein. Drittens: Bridges heben die durchgehende Verschlüsselung an ihrer Stelle auf. Viertens: Quelloffenheit ist kein Sicherheitsnachweis an sich, sondern die Voraussetzung dafür, dass ein Nachweis überhaupt geführt werden kann.
Souveränität ist deshalb keine Eigenschaft, die Sie mit der Produktentscheidung ein für alle Mal erwerben, sondern eine Eigenschaft, die Sie bei jeder Funktionsaktivierung erneut prüfen. Legen Sie fest, wer diese Prüfung verantwortet, und machen Sie sie zu einem festen Schritt, bevor eine neue Bridge, ein neuer Bot oder eine neue Assistenzfunktion produktiv geht.
Ein Punkt, der in Auswahlprojekten fast immer zu spät auftaucht: Ende-zu-Ende-Verschlüsselung und revisionssichere Archivierung stehen in einem Spannungsverhältnis. Wenn der Server Inhalte nicht lesen kann, kann er sie auch nicht archivieren. Für Organisationen mit Aufbewahrungspflichten – etwa bei geschäftsrelevanter Korrespondenz – ist das eine Frage, die vor der Einführung beantwortet werden muss, nicht danach.
In der Praxis gibt es drei gangbare Wege. Der erste: Sie definieren ausdrücklich, dass der Messenger kein Ort für aufbewahrungspflichtige Kommunikation ist, und halten das in einer Nutzungsrichtlinie fest – verbindliche Vorgänge laufen über E-Mail, Dokumentensystem oder Fachanwendung. Der zweite: Sie führen bestimmte Räume unverschlüsselt und archivieren dort serverseitig, mit klarer Kennzeichnung für alle Beteiligten. Der dritte: Sie setzen eine Archivierungslösung ein, die als Teilnehmer im Raum arbeitet – mit derselben Transparenzanforderung wie bei jedem automatisierten Teilnehmer.
Wir empfehlen im Mittelstand fast immer den ersten Weg, weil er am einfachsten zu erklären und am schwersten falsch zu machen ist. Entscheidend ist, dass die Regel existiert und kommuniziert wird. Eine kurze, klare Aussage in der Nutzungsrichtlinie, welche Inhalte ausdrücklich nicht im Messenger abgelegt werden dürfen – Personalangelegenheiten, Gesundheitsdaten, verbindliche Vertragskorrespondenz –, ist eine der wirksamsten Maßnahmen überhaupt.
Fünf Punkte gehören in jede Einführung. Erstens die vertragliche Grundlage: beim betreuten Betrieb ein Auftragsverarbeitungsvertrag mit Standort- und Unterauftragsangaben, beim Eigenbetrieb die saubere Beschreibung der eigenen Verantwortlichkeit – in beiden Fällen dokumentiert im Verarbeitungsverzeichnis. Zweitens ein Rechte- und Rollenkonzept: Wer legt Räume und Spaces an, wer hat Verwaltungsrechte, wer darf externe Teilnehmende einladen, wer verwaltet Konten? Drittens eine Föderationsrichtlinie mit einer nachvollziehbaren Begründung, mit welchen Servern der Austausch erlaubt ist. Viertens die Einbindung der Mitbestimmung: dienstliche Erreichbarkeit, Nutzung privater Geräte, Auswertung von Metadaten und Bereitschaftsalarmierung berühren regelmäßig mitbestimmungspflichtige Tatbestände; eine frühzeitige Betriebsvereinbarung ist einfacher als eine nachträgliche Auseinandersetzung. Fünftens Regeln zu Aufbewahrung, Archivierung und Löschung, einschließlich der Frage, was mit Räumen und Verläufen beim Ausscheiden einer Person geschieht.
