Der zweite prägende Zug der Plattform ist der Betrieb im eigenen Rechenzentrum. Während sich der Markt für Zusammenarbeitssoftware in den letzten Jahren fast vollständig in die Cloud verlagert hat, ist Connections eines der wenigen ausgewachsenen Systeme seiner Klasse, das klassisch On-Premises installiert und betrieben werden kann — auf eigener Hardware, in eigener Netzarchitektur, unter eigener Datenhoheit. Für Organisationen, deren Anforderungen an Souveränität, Geheimschutz oder Netztrennung eine Cloud-Nutzung ausschließen, ist das kein Nebenaspekt, sondern häufig der einzige Grund, warum die Plattform überhaupt auf der Auswahlliste steht.
Die Plattform entstand Mitte der 2000er-Jahre im Umfeld der damaligen IBM-Lotus-Produktfamilie und trug über viele Jahre den Namen IBM Connections. Sie war Teil einer Bewegung, die man heute als erste Welle des „Enterprise 2.0“ bezeichnet: die Idee, die aus dem öffentlichen Web bekannten sozialen Muster — Profile, Aktivitätenströme, Kommentare, Lesezeichen, Wikis — in die abgeschlossene Welt des Unternehmens zu übertragen, damit Wissen nicht in Hierarchien und Postfächern versickert. Für IBM war Connections der soziale Gegenpol zur E-Mail-zentrierten Welt von Notes und Domino, und viele Konzerne führten die Plattform in dieser Logik ein.
Ende der 2010er-Jahre wechselte eine Reihe von Collaboration-Produkten aus dem IBM-Portfolio zu HCL Software, darunter Connections, Domino, Notes und die zugehörigen Ergänzungsprodukte. Aus IBM Connections wurde HCL Connections. Dieser Übergang ist mehr als eine Umbenennung, denn er hat den Charakter der Produktpflege verändert. HCL hat die Weiterentwicklung fortgesetzt, mit sichtbaren Schwerpunkten auf einer modernisierten Oberfläche, containerisierten Zusatzkomponenten und einer engeren Verzahnung mit Domino. Gleichzeitig ist die Plattform aus dem Zentrum der öffentlichen Aufmerksamkeit gerückt, was sich in der Verfügbarkeit von Fachliteratur, Community-Beiträgen und Beratungsangeboten niederschlägt.
Connections verfolgt einen Ansatz, der heute meist als digitaler Arbeitsplatz beschrieben wird. Die Grundannahme lautet: Die relevante Einheit der Zusammenarbeit ist nicht die Nachricht an einen Empfängerkreis, sondern der Raum um ein Thema. Wer einer Community beitritt, sieht deren gesamte Geschichte — Diskussionen, Beschlüsse, Dokumente, Wikiseiten, offene Punkte — auch wenn er erst später dazugekommen ist. Genau dieser Unterschied entscheidet darüber, ob Wissen in einer Organisation kumuliert oder mit jedem Personalwechsel neu erarbeitet werden muss.
Technisch wird dieser Ansatz von drei Elementen getragen. Erstens vom Profil, das eine Person mit Rolle, Standort, Fachgebieten, Zuständigkeiten und Netzwerk beschreibt und damit die Frage beantwortbar macht, wer im Haus etwas zu einem Thema weiß. Zweitens vom Aktivitätenstrom, der Änderungen aus abonnierten Räumen, Personen und Inhalten zu einer personalisierten Übersicht verdichtet und so einen Nachrichtenkanal ersetzt, der sonst per E-Mail bedient würde. Drittens von einem gemeinsamen Berechtigungsmodell, das über alle Inhaltsarten hinweg gilt: Wer Zugriff auf eine Community hat, hat Zugriff auf deren Wiki, Blog, Forum und Dateien, ohne dass Rechte in vier Systemen einzeln gepflegt werden müssen.
Im deutschsprachigen Raum begegnet uns die Plattform in drei wiederkehrenden Konstellationen. Die erste und häufigste ist die Bestandsinstallation: Ein Unternehmen hat Connections in der IBM-Zeit eingeführt, betreibt es seit vielen Jahren, hat erhebliche Wissensbestände darin und steht nun vor der Frage, ob es modernisiert, weiterbetrieben oder abgelöst wird. Diese Konstellation ist der eigentliche Anlass, aus dem dieser Artikel in unserer Wissensdatenbank steht, denn die Entscheidung ist anspruchsvoll und wird oft schlecht vorbereitet.
Die zweite Konstellation ist das Unternehmen mit hohen Souveränitätsanforderungen: Rüstungsnahe Zulieferer, kritische Infrastruktur, Forschungseinrichtungen, öffentliche Träger, Unternehmen mit besonders schutzbedürftigem Konstruktions- oder Verfahrenswissen. Dort ist eine Cloud-Nutzung entweder ausgeschlossen oder mit einem Prüfaufwand verbunden, der den Nutzen aufzehrt. Connections gehört zu der kleinen Gruppe von Plattformen, die diese Anforderung erfüllen können, ohne dass man auf Funktionsumfang verzichtet.
Die dritte Konstellation ist die Domino-Historie. Wo Notes und Domino über Jahrzehnte die Grundlage von Mail, Verzeichnisdienst und Fachanwendungen bilden, ist Connections der naheliegende Baustein für alles, was über die Anwendungslogik hinausgeht: Wissen, Diskussion, Dokumentation, informelle Zusammenarbeit. Der gemeinsame Anbieter, die geteilte Identitätsbasis und die vorhandene Betriebskompetenz senken die Einstiegshürde erheblich. Wer diese Ausgangslage hat, bewertet die Plattform anders als ein Unternehmen, das komplett auf Microsoft 365 arbeitet — und beide Bewertungen können richtig sein.
Die wohl häufigste Verwirrung im Umfeld dieser Produktfamilie betrifft die Abgrenzung zwischen Connections und Domino. Beide stammen aus derselben Herkunft, erfüllen aber deutlich unterschiedliche Aufgaben. Domino ist eine Server- und Anwendungsplattform: Sie stellt Mail, Kalender, Verzeichnisdienst und — historisch besonders bedeutsam — eine Umgebung für individuell entwickelte Fachanwendungen bereit. In vielen mittelständischen Unternehmen laufen dort seit Jahrzehnten Genehmigungsverfahren, Reklamationsbearbeitungen, Vertragsverwaltungen oder Prüfprotokolle, die nie durch ein Standardprodukt ersetzt wurden, weil sie exakt zum Prozess passen.
Connections löst eine andere Aufgabe: Es ist die soziale und wissensorientierte Schicht. Es verwaltet keine Postfächer und ersetzt keine Fachanwendung, sondern schafft den Raum für Diskussion, Dokumentation und gemeinsames Arbeiten an Themen. In Häusern, die beide Produkte einsetzen, ergibt sich daraus eine saubere Arbeitsteilung: strukturierte Vorgänge in Domino-Anwendungen, unstrukturiertes Wissen und Zusammenarbeit in Connections, Kommunikation über den Mailserver. Die Verzahnung reicht in der Praxis so weit, dass Verzeichnisdienst und Anmeldung gemeinsam genutzt werden und Inhalte aus dem einen System im anderen sichtbar gemacht werden können.
Ein technischer Baustein verdient besondere Aufmerksamkeit, weil er über den Aufwand einer modernen Installation maßgeblich mitentscheidet: das Component Pack. Der historische Kern von Connections ist eine klassische Java-Anwendungslandschaft, die auf einem Applikationsserver läuft und ihre Daten in einer relationalen Datenbank ablegt. Neuere Funktionsblöcke werden dagegen nicht mehr in dieses klassische Modell gepresst, sondern als Container bereitgestellt und neben dem Serverkern betrieben.
Für die Praxis bedeutet das eine doppelte Architektur. Auf der einen Seite steht die vertraute Welt aus Applikationsserver, Datenbank, Verzeichnisdienst und vorgeschaltetem Webserver. Auf der anderen Seite steht eine Container-Umgebung, die orchestriert, überwacht und aktualisiert werden muss — typischerweise auf Basis von Kubernetes oder einer vergleichbaren Plattform. Diese Zweiteilung ist der Grund, warum ein Modernisierungsprojekt bei Connections in der Regel nicht nur ein Software-Update ist, sondern auch eine Erweiterung des Betriebsmodells. Wer bisher Server administriert hat, muss künftig zusätzlich eine Container-Plattform beherrschen — mit allem, was dazugehört: Netzwerkkonzept, persistente Speicher, Zertifikate, Protokollierung, Sicherungsstrategie.
Grundsätzlich stehen drei Wege offen, und die Wahl zwischen ihnen ist die wichtigste kaufmännische Entscheidung der ganzen Betrachtung. Der erste Weg ist der Betrieb im eigenen Rechenzentrum: maximale Kontrolle über Daten, Netzsegmentierung, Zugriffe und Aufbewahrung, dafür vollständige Verantwortung für Verfügbarkeit, Sicherheitsaktualisierungen, Sicherung und Wiederherstellung. Dieser Weg ist der eigentliche Grund, aus dem sich Organisationen für die Plattform entscheiden, und gleichzeitig die Quelle des größten Aufwands.
Der zweite Weg ist das Hosting bei einem Partner — häufig einem spezialisierten Systemhaus mit Rechenzentrum in Deutschland, Österreich oder der Schweiz. Diese Variante ist im DACH-Markt praktisch relevanter, als sie in der öffentlichen Diskussion erscheint. Sie verbindet einen klar benennbaren Verarbeitungsort und einen deutschsprachigen Vertragspartner mit deutlich reduziertem Eigenaufwand. Für Mittelständler, die Souveränität wollen, aber kein Team für Container-Betrieb haben, ist das oft die realistischste Lösung. Zu prüfen sind dabei Vertragswerk, Verfügbarkeitszusagen, Wiederherstellungszeiten, das Verfahren bei Sicherheitsvorfällen und die Frage, wie ein späterer Wechsel technisch und vertraglich möglich bleibt.
Der dritte Weg ist ein Cloud-Angebot des Anbieters. Hier entfällt der Infrastrukturaufwand weitgehend, und Aktualisierungen erfolgen im Rhythmus des Betreibers. Datenschutzrechtlich verschiebt sich die Betrachtung damit vollständig: Verarbeitungsort, Vertragsgrundlage, Unterauftragsverarbeiter, Supportzugriffe und Transfermechanismen werden zu den entscheidenden Prüfpunkten und sind beim Anbieter konkret und schriftlich zu klären. Pauschale Aussagen dazu wären unseriös, weil Betriebsmodelle, Regionen und Vertragswerke sich ändern. Wichtig ist die nüchterne Einsicht: Wer in die Cloud geht, gibt genau das Argument auf, das für diese Plattform am stärksten spricht — und sollte dann ohne Vorbehalt prüfen, ob nicht eine der verbreiteten Cloud-Alternativen die bessere Wahl wäre.
Die Community ist das prägende Konstrukt und der Grund, warum sich die Plattform grundsätzlich anders anfühlt als ein Wiki mit Kommentarfunktion. Eine Community ist ein Arbeitsraum mit eigenem Mitgliederkreis, eigenen Rollen und einem frei zusammengestellten Satz an Anwendungen. Wer eine Community anlegt, entscheidet, ob sie ein Wiki bekommt, ein Blog, ein Forum, eine Dateiablage, Aufgabenlisten, Lesezeichen oder eine Ideensammlung — und diese Bausteine gelten dann für den gesamten Raum mit einem einheitlichen Rechtemodell.
Ebenso wichtig ist die Sichtbarkeitsstufe. Communities können öffentlich sein, sodass jede Person im Unternehmen sie findet und beitreten kann; moderiert, sodass Beitritte genehmigt werden; oder vertraulich, sodass sie nur für eingeladene Mitglieder existiert und in der Suche nicht auftaucht. Diese drei Stufen sind konzeptionell einfach und decken erfahrungsgemäß fast alle betrieblichen Bedürfnisse ab — vom offenen Fachforum über den Projektraum bis zum Vorstandsvorbereitungsbereich. Eine bewährte Empfehlung aus unseren Projekten lautet, offene Räume zum Standard zu machen und Vertraulichkeit begründen zu lassen, nicht umgekehrt. Wo alles geschlossen ist, entsteht kein Wissensbestand, sondern nur eine feiner unterteilte Aktenlage.
Das Profil ist mehr als eine digitale Visitenkarte. Neben den Stammdaten aus dem Verzeichnisdienst — Name, Abteilung, Standort, Vorgesetzte, Telefonnummer — trägt es selbst gepflegte Angaben: Fachgebiete, Zuständigkeiten, Erfahrungen, aktuelle Vorhaben, Interessen. Über Verschlagwortung entsteht daraus ein durchsuchbares Kompetenzverzeichnis. In verteilten Organisationen mit mehreren Standorten ist genau das ein unterschätzter Nutzen: Die Frage, wer sich mit einer bestimmten Norm, einer Maschine, einem Markt oder einer Software auskennt, lässt sich beantworten, ohne im Bekanntenkreis herumzufragen. Voraussetzung ist allerdings, dass Profile gepflegt werden — was ohne aktive Begleitung selten von allein passiert.
Der Aktivitätenstrom ist die zweite personenbezogene Kernfunktion. Er bündelt Ereignisse aus abonnierten Communities, gefolgten Personen und beobachteten Inhalten zu einer chronologischen, filterbaren Übersicht: neue Wikiseiten, geänderte Dokumente, Kommentare, Forenbeiträge, Statusmeldungen. Der Nutzen liegt darin, dass Information nicht mehr aktiv verschickt werden muss, um anzukommen. Wer eine Wikiseite überarbeitet, informiert damit automatisch alle Interessierten — ohne Verteilerliste, ohne Anhang, ohne Doppelversionen. Für Organisationen, die unter E-Mail-Flut leiden, ist das ein echter struktureller Gewinn.
Die Wikis sind das Arbeitspferd für dauerhaftes Wissen. Seiten lassen sich hierarchisch gliedern, gemeinsam bearbeiten, versionieren und vergleichen; Änderungen sind nachvollziehbar und rückholbar. Typische Inhalte in mittelständischen Installationen sind Verfahrensbeschreibungen, Einarbeitungsanleitungen, Produktwissen, Ansprechpartnerlisten, Prüfvorgaben und Ergebnisse aus Verbesserungsprojekten. Der Unterschied zu einem Dokument auf einem Laufwerk ist nicht die Technik, sondern die Erwartung: Eine Wikiseite ist ein „lebendes Dokument“ mit erkennbarem Bearbeitungsstand, eine Datei auf einem Laufwerk ist „ein Stand von irgendwann“.
Die Blogs übernehmen das Zeitliche und Personelle. Sie eignen sich für Mitteilungen mit Autorenschaft und Datum: Projektfortschritte, Marktbeobachtungen, Berichte aus Messen und Schulungen, Einordnungen der Geschäftsführung. Weil Beiträge kommentierbar sind, entsteht Rückkanal statt Einbahnstraße — ein wesentlicher Unterschied zum klassischen Intranet-Aushang. Die Foren decken den fragenden Modus ab: Eine Frage, mehrere Antworten, eine als Lösung markierte Antwort. Für Support-, Anwendungs- und Fachfragen ist das ausgesprochen wertvoll, weil sich wiederkehrende Fragen genau einmal beantworten lassen und die Antwort danach auffindbar bleibt.
Die Dateien sind die Ablage der Plattform. Dokumente können persönlich oder in Communities geführt, versioniert, kommentiert, verschlagwortet, freigegeben und über Ordner strukturiert werden; Synchronisierung auf den Arbeitsplatzrechner ist je nach Betriebsmodell möglich. Hier ist eine klare Entwurfsentscheidung nötig, die viele Projekte zu lange offenlassen: Was liegt in Connections und was bleibt im Dateisystem? Eine tragfähige Linie ist, arbeits- und diskussionsbezogene Dokumente in der Community zu führen und formale, aufbewahrungspflichtige Bestände im Dokumentenmanagementsystem zu belassen. Wo diese Grenze fehlt, existiert am Ende alles zweimal, und niemand weiß, welcher Stand gilt.
Ergänzt wird das Bild durch vier weitere Bausteine. Lesezeichen erlauben das gemeinsame Sammeln und Verschlagworten von Verweisen — nützlich für Normen, Lieferantenseiten, Fachquellen und interne Anwendungen. Ideation Blogs sind ein eigenes Format für strukturierte Ideensammlung: Vorschläge werden eingereicht, kommentiert, bewertet und durchlaufen einen definierten Weg von der Sammlung über die Bewertung bis zur Entscheidung. Für ein betriebliches Verbesserungswesen oder eine Innovationsinitiative ist das ein direkt nutzbares Werkzeug, das andernorts eigens beschafft werden müsste. Activities beziehungsweise Aufgabenlisten decken die leichte Arbeitsorganisation innerhalb eines Raums ab — Punkte mit Verantwortlichen und Terminen, verknüpft mit den zugehörigen Inhalten. Das ersetzt kein Projektmanagementwerkzeug mit Abhängigkeiten und Auslastungsrechnung, genügt aber für den Alltag vieler Fachthemen.
Der vierte Baustein ist der mobile Zugang. Über Apps für die verbreiteten mobilen Betriebssysteme lassen sich Ströme, Dateien, Communities und Diskussionen unterwegs nutzen. Für Vertrieb, Service und Produktion ist dieser Zugang oft der entscheidende Akzeptanzfaktor, weil ein erheblicher Teil der Belegschaft nicht am Schreibtisch arbeitet. Zu klären ist dabei zweierlei: die technische Erreichbarkeit einer intern betriebenen Installation von außen — was ein Konzept für gesicherte Veröffentlichung oder Netzzugang verlangt — und die geräteseitige Absicherung über die eingesetzte Mobilgeräteverwaltung. Beides ist lösbar, gehört aber in die Planung und nicht in die Betriebsphase.
Die plattformweite Suche ist die wichtigste einzelne Funktion einer Plattform dieser Art, und sie wird bei der Bewertung fast immer unterschätzt. Sie greift über alle Inhaltsarten hinweg: Wikiseiten, Blogbeiträge, Forenbeiträge, Dateien einschließlich ihrer Textinhalte, Kommentare, Lesezeichen, Communitybeschreibungen und Profile. Entscheidend ist dabei, dass die Suche das Berechtigungsmodell respektiert — jede Person sieht nur Ergebnisse aus Bereichen, für die sie berechtigt ist. Das klingt selbstverständlich, ist bei der Zusammenführung mehrerer Quellsysteme aber technisch anspruchsvoll und in Eigenbaulösungen häufig die Stelle, an der Datenschutzprobleme entstehen.
Wirksam wird die Suche erst im Zusammenspiel mit Verschlagwortung. Connections setzt auf frei vergebbare Stichwörter, aus denen sich Themenlandschaften ergeben. Der große Vorteil freier Verschlagwortung ist die niedrige Hürde, ihr großer Nachteil die Beliebigkeit: Wenn dasselbe Thema unter fünf Schreibweisen geführt wird, zerfällt der Bestand. Bewährt hat sich ein pragmatischer Mittelweg — eine kurze, verbindliche Liste von Leitbegriffen für die wichtigsten Themenfelder, darunter freie Verschlagwortung, und eine turnusmäßige Bereinigung durch eine benannte redaktionelle Rolle. Ohne diese Rolle wird die Verschlagwortung binnen eines Jahres wertlos.
Über die Suche hinaus arbeitet die Plattform mit Empfehlungen. Aus Zugehörigkeiten, Interessen, gefolgten Personen, bearbeiteten Inhalten und Verschlagwortung ergeben sich Vorschläge: Communities, die zum eigenen Aufgabenfeld passen, Personen mit verwandten Themen, Inhalte, die andere in vergleichbarer Rolle nützlich fanden. Der Nutzen liegt in der Entdeckung — also genau dort, wo eine Suche nicht hilft, weil man nicht weiß, dass es etwas zu suchen gibt. In größeren Organisationen ist das der Mechanismus, über den doppelte Arbeit an zwei Standorten überhaupt auffällt.
Der dritte Mechanismus ist die Verdichtung. Weil ein aktiver Strom mehr Ereignisse liefert, als eine Person verarbeiten kann, braucht es Zusammenfassungen: gebündelte Benachrichtigungen statt Einzelmeldungen, periodische Übersichten statt Sofortmeldungen, Hervorhebung dessen, was eine Reaktion erfordert. Praktisch ist hier weniger die technische Fähigkeit entscheidend als die Voreinstellung. In unseren Projekten war eine zurückhaltende Standardkonfiguration mit periodischen Sammelbenachrichtigungen fast immer die bessere Wahl. Wer neue Nutzer mit Sofortmeldungen überschüttet, erzeugt in der zweiten Woche Abschaltungen, die niemand wieder einschaltet.
Bei den KI-gestützten Assistenzfunktionen ist Zurückhaltung angebracht — nicht weil es sie nicht gäbe, sondern weil ihr Zuschnitt in diesem Produktumfeld stark von Ausbaustufe, Betriebsmodell und Zusatzkomponenten abhängt. Sinnvoll ist deshalb, die drei Wirkungsfelder zu benennen und deren Verfügbarkeit konkret zu erfragen, statt sich auf allgemeine Marktaussagen zu verlassen.
Das erste Feld ist die semantische Suche und Beantwortung: nicht nur Trefferlisten nach Stichwort, sondern Antworten auf natürlichsprachliche Fragen, gestützt auf den vorhandenen, berechtigungsgeprüften Inhaltsbestand. Für einen gewachsenen Wissensbestand ist das der größte denkbare Hebel, weil er die Einarbeitungszeit neuer Mitarbeitender unmittelbar verkürzt. Entscheidend ist die Frage, wo die Verarbeitung stattfindet. Bei einer intern betriebenen Installation ist eine Auslagerung von Inhalten an einen externen Dienst genau das Gegenteil dessen, was mit dem Betriebsmodell erreicht werden sollte. Wer diesen Weg erwägt, muss klären, ob Verarbeitung lokal möglich ist, welche Daten das System verlässt und ob Inhalte zum Training verwendet werden.
Für alle drei Felder gilt derselbe Governance-Rahmen, und er ist kurz: Vor der Aktivierung wird schriftlich geklärt, welche Daten verarbeitet werden, wo, durch wen, wie lange, mit welcher Rechtsgrundlage und ob die Funktion abschaltbar oder auf bestimmte Bereiche begrenzbar ist. Anschließend wird die Nutzung in das Verarbeitungsverzeichnis aufgenommen und der Datenschutzbeauftragte einbezogen. Wo Inhalte aus vertraulichen Communities betroffen sein können, ist zusätzlich zu prüfen, ob das Berechtigungsmodell auch für die Assistenzfunktion vollständig greift. Diese letzte Frage wird selten gestellt und ist die wichtigste von allen, denn eine Assistenz, die Inhalte über Berechtigungsgrenzen hinweg zusammenfasst, ist ein Datenschutzvorfall mit angenehmer Oberfläche.
Die engste Verbindung besteht naturgemäß zur eigenen Produktfamilie. In Häusern mit Domino als Mail- und Verzeichnisplattform lässt sich Connections auf derselben Identitätsbasis betreiben: Benutzerkonten, Gruppen und Organisationsstrukturen stammen aus dem vorhandenen Verzeichnis, sodass keine zweite Benutzerverwaltung entsteht. Das ist mehr als eine Bequemlichkeit — es ist die Grundlage dafür, dass Berechtigungen konsistent bleiben und dass ausscheidende Mitarbeitende in einem Vorgang aus allen Systemen entfernt werden.
Auf der Anwendungsebene besteht die klassische Verzahnung darin, Inhalte aus Connections im Mail-Client sichtbar zu machen und umgekehrt Inhalte aus der Mailwelt in die Plattform zu überführen. Praktisch heißt das: Aus einem Mailverlauf wird ein Forenbeitrag oder eine Wikiseite, ein Anhang wandert in die Dateiablage der Community, eine Community-Diskussion wird aus der gewohnten Arbeitsumgebung heraus erreichbar. Der Wert dieser Brücke liegt weniger in der Technik als in der Verhaltensänderung, die sie ermöglicht: Sie senkt die Hürde, Wissen aus dem privaten Postfach in den gemeinsamen Raum zu heben. Genau diese Hürde ist in der Praxis das größte Hindernis für jede Wissensplattform.
Die meisten Mittelständler mit einer Connections-Installation arbeiten gleichzeitig mit Microsoft-Office-Anwendungen, häufig auch mit Microsoft 365 in Teilbereichen. Damit stellt sich die Frage der Koexistenz sehr konkret. Auf der Ebene der E-Mail-Integration existieren Wege, Connections-Inhalte aus Outlook heraus zu erreichen: Community-Dateien anstelle von Anhängen versenden, Nachrichten in eine Community überführen, Benachrichtigungen im Postfach mit Handlungsmöglichkeiten versehen. Der genaue Umfang hängt von Ausbaustufe, Client-Version und Betriebsmodell ab und ist beim Anbieter zu prüfen.
Wichtiger für die Alltagsakzeptanz ist die Dokumentenbearbeitung. Die entscheidende Frage lautet, ob Anwender eine Datei aus der Community heraus öffnen, bearbeiten und wieder zurückspeichern können, ohne sie herunterzuladen und manuell hochzuladen. Wo dieser Weg funktioniert, wird die Dateiablage der Plattform tatsächlich genutzt; wo er fehlt, entstehen lokale Kopien und die Ablage verliert ihre Autorität binnen Wochen. Für die Umsetzung kommen abhängig vom Betriebsmodell verschiedene Wege in Betracht — Bearbeitung im Browser über eine eingebundene Office-Komponente, Anbindung an installierte Desktop-Anwendungen oder Synchronisierung eines lokalen Ordners. Welche dieser Wege in der geplanten Konstellation zur Verfügung stehen, gehört zu den ersten Fragen im Anbietergespräch, weil davon die Akzeptanz unmittelbar abhängt.
Auf der Identitätsseite ist die Anbindung an einen Verzeichnisdienst über LDAP der Regelfall — sei es ein Active Directory, ein Domino-Verzeichnis oder ein anderer LDAP-fähiger Dienst. Ergänzend ist Single Sign-on über die gängigen Verfahren möglich, sodass sich Anwender nicht erneut anmelden müssen. Für den Betrieb ist das ein Kernthema und kein Randaspekt: Ein sauberes Identitätskonzept entscheidet über Anmeldekomfort, über die Zuverlässigkeit von Berechtigungen und über die Vollständigkeit des Austritts, wenn Personen das Unternehmen verlassen. Wo hier improvisiert wird, entstehen verwaiste Konten mit Zugriff auf vertrauliche Räume — ein Befund, der in Prüfungen regelmäßig unangenehm auffällt.
Ein Punkt verdient für den deutschsprachigen Raum besondere Erwähnung: das Partner-Ökosystem. Rund um Connections und Domino existiert im DACH-Markt eine über Jahre gewachsene Landschaft spezialisierter Systemhäuser und Softwarehersteller, die Erweiterungen, Vorlagen, Migrationswerkzeuge, Betriebsdienstleistungen und Hosting anbieten. Für Organisationen ohne eigenes Spezialwissen ist das ein realer Vorteil, weil es kompetente Ansprechpartner in der eigenen Sprache und Zeitzone gibt. Gleichzeitig gilt eine nüchterne Vorsichtsregel: Dieses Ökosystem ist kleiner geworden. Wer sich auf einen Partner stützt, sollte dessen wirtschaftliche Stabilität, die personelle Tiefe des Teams und die Frage prüfen, wer im Fall eines Ausfalls übernehmen könnte. Die Abhängigkeit von einem einzelnen Spezialisten ist ein Risiko, das in der Vertragsgestaltung adressiert werden sollte — durch Dokumentationspflichten, Zugang zu Quellständen eigener Anpassungen und ein vereinbartes Übergabeverfahren.
Confluence ist der häufigste Vergleichspunkt, weil beide Systeme als Ort für Unternehmenswissen gelten. Die Schwerpunkte unterscheiden sich jedoch klar. Confluence denkt von der Seite her: Bereiche enthalten Seitenbäume, Seiten enthalten strukturierte Inhalte, und die Stärke liegt in Dokumentation, Vorlagen, Makros und der engen Verzahnung mit einem Vorgangsverfolgungssystem. Connections denkt vom Raum und von der Person her: Die Community mit ihren Mitgliedern und ihrem Aktivitätenstrom steht im Zentrum, die Wikiseite ist eine von mehreren Inhaltsarten darin.
Bei den Rahmenbedingungen hat sich das Bild verschoben und dieser Punkt ist für DACH-Entscheidungen wesentlich: Der Anbieter von Confluence hat den Vertrieb klassischer, selbst betriebener Serverlizenzen für kleinere Installationen eingestellt und lenkt den Markt in Richtung Cloud beziehungsweise einer Ausbaustufe für sehr große Installationen. Für Organisationen, die zwingend selbst betreiben müssen und nicht in der Größenklasse dieser obersten Stufe liegen, ist Confluence damit faktisch keine On-Premises-Option mehr. Genau in diese Lücke fällt ein erheblicher Teil des heutigen Interesses an Connections — und ebenso an Open-Source-Wikis.
Der wirtschaftlich schwerwiegendste Vergleich betrifft Microsoft 365. Wo eine Organisation bereits umfassend lizenziert ist, stehen mit SharePoint, Teams, OneDrive, Loop und Viva Engage Bausteine bereit, die einen erheblichen Teil des Funktionsumfangs abdecken: Dateiablage mit Versionierung, Intranetseiten, Diskussionen in Kanälen, unternehmensweiter sozialer Austausch, Personenprofile und eine übergreifende Suche. Der Kostenvorteil liegt auf der Hand, weil kein zusätzliches Produkt beschafft und kein zweiter Betrieb aufgebaut werden muss.
Die ehrliche Gegenrechnung hat drei Posten. Erstens ist der Microsoft-Ansatz verteilt: Wissen, Diskussion und Dateien liegen in mehreren Werkzeugen mit unterschiedlichen Logiken, und die Aufgabe, daraus einen konsistenten Ort zu machen, verlagert sich vom Produkt in die Konzeptarbeit der Organisation. Connections liefert diese Konsistenz eingebaut. Zweitens ist Microsoft 365 ein Cloud-Dienst; ein Betrieb im eigenen Rechenzentrum ist für den heutigen Funktionsumfang nicht vorgesehen. Wo Souveränität eine harte Anforderung ist, endet der Vergleich an dieser Stelle. Drittens verändert sich das Microsoft-Portfolio schnell, was Nutzungskonzepte laufend nachziehen lässt — ein Aufwand, der selten eingeplant wird.
Bitrix24 tritt als All-in-one-Portal an und deckt neben Intranet, Aktivitätenstrom und Dateiablage auch CRM, Aufgaben und Telefonie ab. Für kleinere Unternehmen, die möglichst viele Bedürfnisse mit einem Vertrag lösen wollen, ist das reizvoll, und es existiert auch eine selbst betreibbare Variante. In der Tiefe von Wissensarbeit — Wiki-Versionierung, Verschlagwortung, Kompetenzprofile, differenzierte Sichtbarkeitsstufen — reicht die Lösung nach unserer Erfahrung nicht an eine spezialisierte Plattform heran. Zudem verdient die Anbieterstruktur eine eigene Prüfung, wenn Souveränität der Anlass der Suche ist.
Für Organisationen, die vor allem Datenhoheit suchen und deshalb bei Connections gelandet sind, gehört ein ehrlicher Blick auf europäische und quelloffene Wege dazu. Nextcloud ist die naheliegendste Alternative, wenn Dateiablage, Zusammenarbeit an Dokumenten und ergänzende Kommunikationsbausteine im Zentrum stehen; es ist selbst betreibbar, europäisch und hat eine aktive Entwicklergemeinschaft, ist aber kein vollwertiger Ersatz für Communities, Ströme und Kompetenzprofile. XWiki deckt den Wissensteil sehr gut ab, ist quelloffen, selbst betreibbar und in der Strukturierung von Inhalten ausgesprochen leistungsfähig, bringt jedoch den sozialen Anteil nur eingeschränkt mit. Stackfield ist ein deutscher Anbieter mit Rechenzentren in Deutschland und starker Verschlüsselungsorientierung, sitzt funktional aber näher an Aufgaben- und Teamzusammenarbeit als an einer Wissensplattform.
Wir führen die Auswahl entlang von vier Fragen, und die Reihenfolge ist entscheidend. Erstens: Ist Eigenbetrieb eine harte Anforderung oder ein Wunsch? Bei einer harten Anforderung schrumpft der Markt auf eine überschaubare Zahl von Kandidaten, und Connections gehört dazu. Bei einem Wunsch lohnt es, den Grund zu prüfen, denn oft steckt dahinter eine ältere Datenschutzbewertung, die inzwischen anders ausfallen würde. Zweitens: Was ist der Schwerpunkt — Dokumentation oder Austausch? Diese Frage entscheidet zwischen wikizentrierten und community-zentrierten Systemen. Drittens: Welche Betriebskompetenz ist real vorhanden? Nicht welche gewünscht ist. Viertens: Wie sieht die Lage in fünf Jahren aus? Also: Wer betreibt das System dann, mit welchem Personal, auf welcher Version, mit welchem Partner.
Eine Connections-Installation ist keine einzelne Anwendung, sondern ein Verbund. Zum klassischen Kern gehören ein Applikationsserver, auf dem die Anwendungen laufen, eine relationale Datenbank für Inhalte und Metadaten, ein Verzeichnisdienst für Benutzer und Gruppen, ein vorgeschalteter Webserver als Zugangspunkt und Lastverteiler sowie ein Suchindex. Hinzu kommen Dateispeicher für Anhänge und Dokumente, Zertifikate für die gesicherte Übertragung und je nach Anforderung eine Ausfallsicherung durch mehrfache Auslegung der Komponenten.
Diese Aufzählung ist kein Selbstzweck, sondern hat unmittelbare Konsequenzen für die Personalplanung. Für einen zuverlässigen Betrieb braucht es Kompetenz in vier Disziplinen: Betriebssystem- und Serverbetrieb, Datenbankadministration, Verzeichnis- und Identitätsverwaltung sowie die Plattform selbst. In größeren IT-Abteilungen sind diese Rollen ohnehin vorhanden, und die Erweiterung ist überschaubar. In einer kleinen IT mit zwei oder drei Personen konzentrieren sie sich auf wenige Köpfe — und damit auf ein Personenrisiko, das offen ausgesprochen gehört. Die entscheidende Frage lautet nicht, ob der Betrieb heute funktioniert, sondern was passiert, wenn die Person, die ihn kennt, sechs Wochen ausfällt oder das Unternehmen wechselt.
Zur klassischen Architektur tritt, wie im Kapitel zur Produktfamilie beschrieben, die containerisierte Erweiterung. Damit kommt eine zweite Betriebswelt ins Haus: eine Orchestrierungsplattform, in der Container ausgeführt, überwacht, mit persistentem Speicher versehen und aktualisiert werden. Wer bereits eine Container-Umgebung betreibt, integriert diese Komponenten als weiteren Mandanten. Wer keine hat, baut sie zusammen mit der Modernisierung auf — und das ist ein eigenes Vorhaben mit eigenem Lernbedarf, eigenem Sicherheitskonzept und eigenem Betriebshandbuch.
Der Aktualisierungszyklus ist der zweite Aufwandstreiber und der häufigste Grund, warum Installationen veralten. Zu unterscheiden sind drei Ebenen: Sicherheitsaktualisierungen der Basiskomponenten, die zeitnah eingespielt werden müssen; Wartungsstände der Plattform, die Fehler beheben; und größere Versionswechsel, die neue Funktionen bringen und Vorbereitung verlangen. In der Praxis begegnen uns Installationen, die jahrelang keinen Versionswechsel erlebt haben, weil der letzte schmerzhaft war und niemand ein Zeitfenster fand. Die Folge ist ein Modernisierungsstau: Je länger gewartet wird, desto größer der Sprung, desto höher das Risiko, desto geringer die Bereitschaft. Dieser Kreislauf ist der eigentliche Grund, aus dem Plattformen sterben — nicht fehlende Funktionen.
Technischer Betrieb ist nur die eine Hälfte. Die andere ist das Redaktionsmodell, und hier scheitern Wissensplattformen häufiger als an der Technik. Eine Community ohne verantwortliche Person verwahrlost innerhalb weniger Monate: Beiträge bleiben unbeantwortet, Wikiseiten veralten, Dateien liegen doppelt, und neue Mitarbeitende ziehen den Schluss, dass hier nichts Verlässliches steht. Deshalb gilt die Regel: Keine Community ohne benannte verantwortliche Person, und diese Rolle steht in der Stellenbeschreibung, nicht in einer Absichtserklärung. Ergänzend braucht es eine kleine zentrale Redaktion, die den unternehmensweiten Teil pflegt, Leitbegriffe verwaltet, inaktive Räume archiviert und bei Bedarf zusammenführt.
Bleibt die unangenehmste Frage: die Verfügbarkeit von Know-how. Für Connections ist der Arbeitsmarkt deutlich dünner besetzt als für die verbreiteten Cloud-Plattformen. Ausschreibungen für Administratoren mit einschlägiger Erfahrung dauern länger, das Angebot an Schulungen ist begrenzt, und ein erheblicher Teil des greifbaren Wissens liegt bei spezialisierten Partnern und in Community-Beiträgen aus der IBM-Zeit. Wer die Plattform weiterbetreiben will, sollte daraus drei Konsequenzen ziehen: Betriebswissen konsequent dokumentieren statt in Köpfen halten, mindestens zwei Personen intern befähigen, und einen Partnervertrag mit klaren Reaktionszeiten als Rückfalloption abschließen. Diese drei Maßnahmen kosten Geld, aber sie sind der Unterschied zwischen einer gepflegten Plattform und einer, die eines Tages „niemand mehr anfassen will“.
Die erste und häufigste Ausgangslage ist die gewachsene Bestandsinstallation. Ein Unternehmen betreibt die Plattform seit vielen Jahren, oft aus der IBM-Zeit. Darin liegen Tausende Wikiseiten, Forenbeiträge und Dokumente — Verfahrenswissen, Produkthistorie, Fehlerbilder, Lieferantenerfahrungen, Entscheidungen mit Begründung. Dieser Bestand ist häufig wertvoller, als die IT-Abteilung annimmt, weil er das enthält, was in keinem ERP steht: das Warum. Gleichzeitig ist die Installation oft veraltet, die Oberfläche wirkt aus der Zeit gefallen, und die jüngeren Mitarbeitenden fragen, warum sie nicht in Teams arbeiten dürfen. Hier ist die Aufgabe keine Softwareauswahl, sondern eine nüchterne Bewertung von Bestandswert, Betriebsrisiko und Alternativen.
Die zweite Ausgangslage ist das Unternehmen mit hohen Souveränitätsanforderungen. Kritische Infrastruktur, sicherheitsrelevante Zulieferung, Forschung mit Schutzbedarf, Verfahrenswissen von erheblichem Wert, öffentliche Träger mit strengen Vorgaben. Dort ist die Cloud-Frage entweder normativ geklärt oder mit einem Prüfaufwand verbunden, der den Nutzen aufzehrt. Für diese Häuser ist Connections eine der wenigen Optionen, die vollständigen Funktionsumfang bei vollständiger Datenhoheit bietet. Die entscheidende Anschlussfrage lautet dann nicht mehr, ob die Plattform passt, sondern ob die Organisation den Betrieb dauerhaft leisten kann oder ein Partner-Hosting im Inland die klügere Antwort ist.
Die dritte Ausgangslage ist die Domino-Landschaft. Wo Mail, Verzeichnis und gewachsene Fachanwendungen auf Domino laufen, ist Connections der natürliche Baustein für alles Unstrukturierte. Der gemeinsame Anbieter, die geteilte Identitätsbasis und vorhandene Betriebskompetenz senken Hürden erheblich. Diese Häuser stehen allerdings meist vor einer größeren Frage als der nach einer Kollaborationsplattform: nämlich wie die Fachanwendungen langfristig weitergeführt werden. Es wäre ein Fehler, diese beiden Entscheidungen getrennt zu treffen. Wer die Domino-Anwendungen mittelfristig ablöst, sollte die Zukunft von Connections in dieselbe Roadmap schreiben.
Der stärkste Effekt ist die Sicherung von Erfahrungswissen. In vielen mittelständischen Betrieben steht in den kommenden Jahren ein erheblicher Teil der Belegschaft vor dem Ruhestand, und mit ihnen geht Wissen, das nie geschrieben wurde: warum eine Anlage genau so eingestellt wird, welcher Lieferant bei welcher Toleranz zuverlässig ist, welche Sonderlösung bei einem Altkunden gilt. Eine Wissensplattform macht dieses Wissen nicht automatisch sichtbar, aber sie schafft einen Ort, an dem es abgelegt werden kann — und mit Foren und Kommentaren einen niedrigschwelligen Weg, es beiläufig zu teilen. Wo dieser Prozess aktiv begleitet wird, ist der Nutzen mit Abstand der größte, den die Plattform liefern kann.
Nun der unangenehme Teil, den kein Beitrag über dieses Produkt auslassen sollte. Der Markt für Enterprise Social Collaboration hat sich verschoben. Die Aufmerksamkeit, die Zahl der Anbieter von Erweiterungen, die Menge aktueller Fachliteratur und die Zahl der Fachkräfte mit einschlägiger Erfahrung sind für Connections geringer als für die verbreiteten Cloud-Plattformen. Das macht die Software nicht schlecht — funktional ist sie in ihrer Kerndisziplin nach wie vor konkurrenzfähig, und der Eigenbetrieb ist ein Merkmal, das andere nicht mehr bieten. Es bedeutet aber, dass ein Legacy-Risiko existiert und benannt werden muss: das Risiko, in einigen Jahren ein System zu betreiben, für das weder intern noch am Markt ausreichend Kompetenz verfügbar ist.
Aus diesen Fragen ergeben sich in der Praxis drei tragfähige Wege. Der geordnete Weiterbetrieb mit Modernisierung passt zu Häusern mit hohem Bestandswert, harter Souveränitätsanforderung und ausreichender Betriebskompetenz oder verlässlichem Partner. Der Wechsel des Betriebsmodells — gleiche Plattform, gehostet bei einem inländischen Partner — passt zu Häusern, die den Bestand und die Souveränität wollen, aber den Eigenbetrieb nicht dauerhaft stemmen. Die geplante Ablösung passt zu Häusern, die ohnehin überwiegend in einer Cloud-Suite arbeiten, deren Bestand überschaubar ist und deren Souveränitätsanforderung sich als Gewohnheit und nicht als Vorgabe erweist.
Eine belastbare Kalkulation besteht bei dieser Plattform aus zwei Blöcken, die sich in der Größenordnung ähneln können — und genau das unterscheidet sie von reinen Cloud-Werkzeugen. Der erste Block ist die Lizenzierung mit den zugehörigen Wartungs- und Supportleistungen. Sie richtet sich üblicherweise nach der Zahl der berechtigten Personen und der gewählten Produktzusammenstellung, teils in Bündeln mit weiteren Produkten der Familie. Konditionen, Zählweisen und Bündelungen sind verhandlungsfähig und stichtagsabhängig; verbindlich ist ausschließlich das Angebot.
Der zweite Block ist der Betrieb, und er wird regelmäßig unterschätzt. Dazu gehören Hardware oder Virtualisierungskapazität für mehrere Serverrollen, Speicher für Dateien und Datenbank, Lizenzen für Betriebssystem und Datenbank, eine Container-Plattform samt deren Betrieb, Sicherungsinfrastruktur, Überwachung, Zertifikate und eine Testumgebung. Hinzu kommt der Personalaufwand: laufende Administration, Aktualisierungen, Fehlersuche, Rechteverwaltung, Unterstützung der Anwender. Wer diesen Posten realistisch bewertet, kommt bei kleineren Installationen häufig zu dem Ergebnis, dass Partner-Hosting günstiger ist als Eigenbetrieb — ein Befund, der oft überrascht, weil er die intuitive Annahme umkehrt, Eigenbetrieb sei sparsamer.
Beim Eigenbetrieb verändert sich die datenschutzrechtliche Betrachtung grundlegend, und zwar zugunsten der Organisation. Es gibt keinen Auftragsverarbeiter für die Inhaltsdaten, weil die Verarbeitung im eigenen Verantwortungsbereich stattfindet. Es gibt keine Frage nach dem Serverstandort, weil der Standort bekannt ist. Es gibt keinen Drittlandtransfer für die laufende Nutzung und keine Diskussion über Unterauftragsverarbeiter. Für Verarbeitungsverzeichnis, Folgenabschätzung und Auskunftsersuchen bedeutet das eine erhebliche Vereinfachung: Alle Fragen lassen sich aus eigener Kenntnis beantworten. In Ausschreibungen und Prüfungen ist dieses Argument stark, und es ist der Hauptgrund, warum die Plattform in bestimmten Branchen weiterhin gesetzt ist.
Diese Stärke hat eine exakte Kehrseite: Die volle Verantwortung liegt im Haus. Wer selbst betreibt, ist selbst zuständig für Härtung der Systeme, zeitnahe Sicherheitsaktualisierungen, Verschlüsselung der Übertragung und gegebenenfalls der Speicherung, Zugriffsbeschränkung, Protokollierung, Erkennung von Angriffen, Sicherung und geprobte Wiederherstellung sowie für die Umsetzung von Löschansprüchen. Der Artikel 32 der Datenschutz-Grundverordnung verlangt angemessene technische und organisatorische Maßnahmen — bei Eigenbetrieb ist es die eigene Aufgabe, deren Angemessenheit zu belegen. Eine veraltete, ungepatchte Installation im eigenen Rechenzentrum ist datenschutzrechtlich schlechter als ein gepflegter Dienst bei einem geprüften Anbieter, auch wenn das Gegenteil intuitiv erscheint. Souveränität ist eine Leistung, kein Zustand — und der Satz „die Daten liegen bei uns“ ersetzt keine Sicherheitsarbeit.
Für den Fall der Cloud- oder Hosting-Nutzung gilt die gewohnte Prüfliste, und sie ist unverkürzt anzuwenden: Auftragsverarbeitungsvertrag mit dokumentierten technischen und organisatorischen Maßnahmen; konkrete Angabe des Verarbeitungsorts für Inhalts- und für Metadaten; Liste der Unterauftragsverarbeiter mit Änderungsmitteilung; Regelung der Supportzugriffe einschließlich Protokollierung; Transfermechanismus, sofern Verarbeitung außerhalb der EU möglich ist; Verfahren bei Sicherheitsvorfällen mit Meldefristen; Regelungen zu Löschung, Rückgabe und Export bei Vertragsende. Diese Punkte gehören schriftlich bestätigt und nicht mündlich zugesichert — beim Anbieter oder beim hostenden Partner, je nachdem, wer verantwortlich ist.
Ein Punkt verdient bei dieser Plattform besondere Aufmerksamkeit, weil er in ihrem Konzept angelegt ist: Connections macht Aktivität sichtbar. Der Aktivitätenstrom zeigt, wer wann welchen Beitrag geschrieben, welche Seite geändert, welche Datei hochgeladen und welchen Kommentar hinterlassen hat. Profile zeigen Zugehörigkeiten und Beiträge. Wikiseiten führen eine vollständige Bearbeitungshistorie. Nutzungsauswertungen können zeigen, welche Bereiche aktiv sind und welche nicht. Nichts davon ist zur Überwachung gedacht — alles davon ist dafür geeignet, und auf diese Eignung stellt das deutsche Betriebsverfassungsrecht ab.
In Betrieben mit Betriebsrat löst der Einsatz deshalb regelmäßig die Mitbestimmung nach § 87 BetrVG aus, insbesondere hinsichtlich technischer Einrichtungen, die dazu bestimmt oder geeignet sind, Verhalten und Leistung der Beschäftigten zu überwachen. Bei einer Plattform, deren Kernmerkmal ein personenbezogener Aktivitätenstrom ist, ist diese Eignung nicht diskutabel. Der praktische Weg ist deshalb, die Arbeitnehmervertretung früh einzubinden — vor der Konfiguration, nicht nach dem Rollout — und in einer Betriebsvereinbarung festzuhalten, welche Auswertungen es gibt, auf welcher Aggregationsebene, wer sie einsehen darf, wie lange Daten aufbewahrt werden und was ausdrücklich ausgeschlossen ist.
Bewährt haben sich vier Zusicherungen, die den Konflikt in der Regel entschärfen. Erstens: Nutzungs- und Aktivitätsdaten werden nicht zur individuellen Leistungsbewertung verwendet — weder für Beurteilungen noch für Zielvereinbarungen. Zweitens: Auswertungen für Steuerungszwecke erfolgen nur aggregiert, etwa auf Ebene von Bereichen und Themen, nicht auf Personenebene. Drittens: Auswertungsberechtigungen sind technisch beschränkt und dokumentiert; wer keine Personenauswertung braucht, kann keine sehen. Viertens: Für Aufbewahrung und Löschung gelten definierte Fristen, insbesondere für Protokoll- und Aktivitätsdaten. Der dritte Punkt ist der wichtigste, weil er die Zusicherung technisch unterlegt statt sie nur zu versprechen — und weil er bei einer selbst betriebenen Installation vollständig in der eigenen Hand liegt.
