Nextcloud: Plattform, Projekt und Praxis – und wie sich Copper daran anbinden lässt

Nextcloud begann 2016 als Abspaltung. Frank Karlitschek, Mitbegründer von ownCloud, verließ das Projekt und baute mit einem kleinen Team eine eigenständige Weiterentwicklung auf. Was damals nach einem weiteren Fork im hart umkämpften Markt für File Sync and Share aussah, ist heute eine Plattform, die in Behörden, Hochschulen, Kliniken und mittelständischen Betrieben als zentrale Arbeitsumgebung dient. Der Anspruch hat sich dabei verschoben: Weg von der reinen Dateiablage, hin zu Groupware, Videokonferenz, Office und Automatisierung – unter eigener Kontrolle, auf eigener Hardware oder in einer europäischen Region.

Wer Nextcloud einführt, kauft allerdings selten nur ein Produkt. Man übernimmt ein Stück Infrastrukturverantwortung: Datenbank, Webserver, Speicher, Backup, Updates, Rechte. Dazu kommt die Frage, wie sich Spezialanwendungen anbinden lassen, die man nicht selbst betreiben will. Ein Beispiel, das in Vertriebs- und Projektteams immer wieder auftaucht, ist Copper – eine CRM-Plattform, die tief in der Google-Welt verwurzelt ist. Beides zusammen, Nextcloud und Copper, ergibt keine Liebesheirat auf den ersten Blick. Aber es gibt tragfähige Wege.

Vom Fork zur Plattform: Wo Nextcloud heute steht

Die Versionsnummern zählen jährlich nach oben, seit 2019 firmiert das Ganze unter dem Label Nextcloud Hub. Damit ist nicht bloß ein Bündel von Apps gemeint, sondern ein abgestimmtes Zusammenspiel: Dateien, Kalender, Kontakte, Mail, Chat, Office, Projektboards, Formulare und Automatisierung greifen auf denselben Identitäts- und Berechtigungsbestand zu. Wer einen Nutzer anlegt, legt ihn einmal an. Wer eine Gruppe ändert, ändert sie überall. Das klingt banal, ist in gewachsenen Umgebungen aber oft der schwierigste Teil.

Der Nextcloud Server selbst steht unter AGPL, die Firma Nextcloud GmbH mit Sitz in Stuttgart verkauft Support, Enterprise-Funktionen und Betriebsleistungen. Das Modell kennt man aus der Open-Source-Welt: Die Community-Edition ist funktional erstaunlich vollständig, die Enterprise-Edition ergänzt Dinge, die vor allem große Organisationen brauchen – zentrale Verwaltung, Audit-Funktionen, skalierbare Freigabe, Support mit Reaktionszeiten. Nicht zuletzt deshalb ist Nextcloud in Ausschreibungen der öffentlichen Hand so präsent.

Interessant ist die Bandbreite der Installationen. Auf der einen Seite steht die Nextcloud auf einem Einplatinenrechner im Arbeitszimmer, auf der anderen ein Verbund mit mehreren hunderttausend Nutzern. Dazwischen liegt die breite Masse: ein paar hundert bis ein paar tausend Konten, betrieben von einer IT-Abteilung, die nebenbei noch zwanzig andere Dinge erledigt. Genau für diese Gruppe ist die Frage nach Betriebsmodell und Speicherarchitektur entscheidend.

Architektur: Was unter der Oberfläche steckt

Technisch ist Nextcloud ein PHP-Anwendungspaket. Es braucht einen Webserver, eine Datenbank und einen Cache. Als Datenbank kommen MariaDB, MySQL, PostgreSQL oder – mit Einschränkungen – SQLite infrage. Im produktiven Betrieb hat sich PostgreSQL in vielen Umgebungen als robust erwiesen, MariaDB ist weiter verbreitet (Standart ist hier schlicht, was das eigene Team beherrscht). Redis übernimmt üblicherweise Dateisperren und Sitzungen, APC oder APCu den lokalen Opcode-Cache. Ohne Redis wird es bei parallelem Zugriff auf dieselbe Datei schnell ungemütlich.

Die Kommunikation nach außen läuft über mehrere Protokolle: WebDAV für Dateien, CalDAV und CardDAV für Kalender und Adressbücher, eine OCS-API für Clients und Verwaltung, dazu eine Weboberfläche, die seit einigen Jahren auf Vue aufsetzt. Wer automatisieren will, kommt an der Kommandozeile nicht vorbei. Das Werkzeug heißt occ und kann erstaunlich viel: Nutzer anlegen, Apps aktivieren, Reparaturen fahren, Verschlüsselung umstellen, Diagnosen ausgeben. Ein Administrator, der occ nicht mag, wird mit Nextcloud nicht glücklich.

Bei den Installationswegen gibt es drei, die sich etabliert haben. Da ist zum einen das klassische Paket aus Tarball oder Distributions-Repository, bei dem man jede Komponente selbst konfiguriert. Zum anderen das Snap-Paket, das vor allem Einsteiger schätzen, weil es Abhängigkeiten bündelt – dafür ist es starr, was PHP-Versionen und Erweiterungen angeht. Und schließlich der Nextcloud All-in-One-Container, der eine ganze Betriebsumgebung inklusive Datenbank, Collabora, Talk-Signalisierung und Backup-Mechanik mitbringt. Für kleinere Umgebungen ist das oft die vernünftigste Wahl, weil es die klassischen Fehlerquellen beim Zusammenstecken des Stacks vermeidet.

Darüber hinaus existiert ein offizielles Helm-Chart für Kubernetes. Dort betreibt man Nextcloud wie jede andere zustandsbehaftete Anwendung: getrennte Deployments für Webserver und Cron, ein persistenter Speicher oder gleich Objektspeicher, ein eigener Job für Hintergrundaufgaben. Der entscheidende Punkt ist der Cron. Ohne regelmäßig laufenden Hintergrund-Job bleiben Vorschaubilder, Suchindizes, Papierkorb-Bereinigung und Freigabe-Mails liegen. AJAX-Cron, wie ihn viele Hobbyinstallationen nutzen, ist ein Notbehelf und sollte in keinem Unternehmensbetrieb vorkommen.

Speicher: vom lokalen RAID zum Objektspeicher

Die Datenablage ist der Punkt, an dem sich Nextcloud-Installationen am stärksten unterscheiden. Im einfachsten Fall liegt das Datenverzeichnis auf einem lokalen RAID-Verbund. Das funktioniert gut, solange ein einzelner Server ausreicht. Wächst die Umgebung, wird es eng: Der Speicher ist an eine Maschine gebunden, Erweiterungen erfordern Wartungsfenster, und ein Wiederanlauf nach Hardware-Ausfall dauert.

Deshalb lässt sich Nextcloud seit einigen Jahren auch mit einem S3-kompatiblen Objektspeicher als primärem Ablageort betreiben. Ceph, MinIO, Wasabi, IONOS, Scaleway oder auch S3 selbst kommen infrage. Das Muster dahinter ist ein zweistufiges: Metadaten bleiben in der Datenbank, die eigentlichen Dateibrocken landen als Objekte im Bucket. Der Vorteil liegt in der Skalierung, der Nachteil in der Komplexität. Wer Objektspeicher als Primärspeicher nutzt, sollte sich mit Versionierung im Bucket, Konsistenzmodellen und der Frage beschäftigen, wie ein Restore ohne Nextcloud aussieht. Ein Notfallkonzept, das nur auf die Weboberfläche setzt, ist kein Notfallkonzept.

Für sehr große Installationen unterstützt Nextcloud inzwischen mehrere Buckets, sodass sich Mandanten oder Abteilungen auf getrennte Buckets verteilen lassen – das erleichtert Abrechnung, Aufräumen und gezielte Wiederherstellung. Daneben existieren die klassischen Möglichkeiten: externe Speicher über SMB, WebDAV, FTP oder S3 einbinden, Group Folders für abteilungsweite Ablagen, Versionierung und Papierkorb als Schutznetz. Ein erläuterndes Beispiel gefällig? Ein Konstruktionsbüro legt CAD-Dateien in einem Group Folder ab, der per Berechtigung für die Konstruktion schreibbar, für den Vertrieb nur lesbar ist. Verträge dagegen liegen in einem regulären Ordner mit Aufbewahrungsfristen, weil dort die Versionierung und der Papierkorb greifen müssen.

Sicherheit, Datenschutz und die Pflichten des Betreibers

Nextcloud bringt eine ganze Reihe von Schutzmechanismen mit, aber keiner davon wirkt von allein. Zwei-Faktor-Authentifizierung über TOTP oder WebAuthn lässt sich aktivieren, Brute-Force-Schutz und Sperrlisten sind eingebaut, fail2ban lässt sich integrieren. Für größere Umgebungen ist die Anbindung an einen Identity-Provider über LDAP, Active Directory, SAML oder OpenID Connect der eigentliche Hebel: Wer zentral anlegt und zentral sperrt, hat weniger Leichen im Keller.

Bei der Verschlüsselung lohnt eine Unterscheidung. Serverseitige Verschlüsselung schützt die Daten auf dem Datenträger, etwa bei entsorgten Festplatten oder ausgelagerten Backups – der Server selbst kann sie jederzeit wieder lesen. Ende-zu-Ende-Verschlüsselung schützt zusätzlich vor dem Betreiber, ist aber mit einigen Funktionen nicht kombinierbar, etwa mit serverseitiger Suche oder bestimmten App-Integrationen. Unternehmen müssen hier eine bewusste Entscheidung treffen statt beide Verfahren gleichzeitig zu erwarten. Ein häufiger Fehler in Projekten ist genau das: Man verspricht E2E und wundert sich später, dass die Volltextsuche nicht greift.

Jenseits der Technik steht der organisatorische Teil. Wer Nextcloud selbst betreibt, ist datenschutzrechtlich Verantwortlicher – nicht der Hersteller. Das bedeutet: Verzeichnis der Verarbeitungstätigkeiten, TOM, Löschkonzept, Rollen- und Berechtigungskonzept, Protokollierung. Nextcloud liefert dafür Bausteine: Audit-Logs, Datei-Zugriffskontrolle über Flow-Regeln, Aufbewahrungsfristen, Antivirus-Anbindung über ClamAV, Protokollierung von Freigaben. In sicherheitskritischen Umgebungen sind zusätzlich Themen wie Verschlüsselung mit HSM, Zwei-Personen-Regel für Administratoren oder Netztrennung relevant.

Wer über Zertifizierungen nachdenkt: Nextcloud selbst lässt sich in Umgebungen betreiben, die nach ISO 27001 oder BSI IT-Grundschutz aufgebaut sind, und ist Teil verschiedener Cloud-Angebote mit C5-Testat. Die Zertifizierung gilt dann aber für den Betrieb, nicht für die Software an sich. Der Unterschied ist in Ausschreibungen oft entscheidend und wird trotzdem regelmäßig verwischt.

Apps und Zusammenarbeit: Das Ökosystem

Der eigentliche Reiz von Nextcloud liegt im App-Ökosystem. Groupware mit Mail, Kalender und Kontakten gehört zum Standardumfang. Talk übernimmt Chat und Videokonferenz, seit der Signaling-Server quelloffen ist, lässt sich auch das Hochleistungs-Backend selbst betreiben – ein wichtiger Punkt für alle, die keine Meetingdaten über fremde Infrastruktur leiten wollen. Deck bringt Kanban-Boards, Tables eine Datenbankoberfläche, Collectives eine Wiki-artige Wissensablage, Forms Umfragen und Formulare, Notes einfache Notizen, Whiteboard eine kollaborative Tafel.

Für Dokumentbearbeitung stehen zwei Wege offen. Nextcloud Office basiert auf Collabora Online und lässt sich als integrierter Code-Server betreiben; alternativ bindet man ONLYOFFICE an. Beide Lösungen sind brauchbar, aber ihr Betrieb ist anspruchsvoll – ein Collabora-Server, der für zwanzig Personen ausgelegt ist, bricht bei zweihundert gleichzeitigen Bearbeitern zusammen. Wer Office ernsthaft nutzt, muss die Dimensionierung eigenständig planen und nicht davon ausgehen, dass sie sich von allein ergibt.

Neuere Entwicklungen zielen auf Erweiterbarkeit jenseits von PHP. Über die AppAPI lassen sich sogenannte ExApps betreiben, also containerisierte Anwendungen, die mit Nextcloud über eine definierte Schnittstelle sprechen. Damit sind Funktionen möglich, die in PHP schwer darstellbar wären – etwa Bilderkennung, Sprachtranskription oder Assistentenfunktionen, die auf lokal gehosteten Modellen laufen. Der Ansatz ist noch jung, die Richtung aber erkennbar: Nextcloud wird zum Integrationsrahmen, nicht mehr nur zur Anwendung.

Wer Apps von Drittanbietern einsetzt, sollte deren Pflegezustand prüfen. Der App-Store weist aus, wer eine App veröffentlicht und wann sie zuletzt angepasst wurde; ein Blick auf Issue-Tracker und Kompatibilitätsangaben erspart böse Überraschungen beim nächsten Versionssprung. Von den mehreren hundert verfügbaren Erweiterungen sind viele gepflegt, manche halb tot. Verantwortung für Datenverlust trägt am Ende der Betreiber, nicht der Entwickler eines Hobbyprojekts.

Copper: Ein CRM, das in einer anderen Welt zu Hause ist

Copper ist eine CRM-Plattform, die aus dem Google-Ökosystem heraus gedacht ist. Ursprünglich als ProsperWorks gestartet, später umbenannt, richtet sie sich an Teams, die Gmail, Google Kalender und Google Drive als Arbeitsgrundlage nutzen. Kontakte, Unternehmen, Verkaufschancen, Aktivitäten und Aufgaben bilden den Kern; dazu kommen Pipeline-Auswertungen, Automatisierungen und eine Erweiterung für den Browser, die E-Mails direkt einem Datensatz zuordnet. Die Schnittstelle ist gut dokumentiert, es gibt Webhooks für Ereignisse und eine REST-API, über die sich fast alles steuern lässt, was die Oberfläche kann.

Ein interessanter Aspekt: Copper ist kein Open-Source-Produkt, sondern ein Cloud-Dienst mit Sitz in den USA. Für europäische Unternehmen ist das kein Ausschlusskriterium, aber ein Diskussionspunkt. Wer Nextcloud gerade deshalb einführt, weil Daten das Haus nicht verlassen sollen, wird nicht alle Kundendaten in ein US-CRM auslagern wollen. In der Praxis trifft man deshalb häufig auf einen Kompromiss: Sensible Dokumente bleiben in Nextcloud, das CRM enthält nur die Vertriebsinformationen, die für die Arbeit wirklich nötig sind. Datenminimierung als Architekturprinzip, nicht als Fußnote im Verzeichnis der Verarbeitungstätigkeiten.

Interessant ist Copper für Nextcloud-Nutzer aus einem zweiten Grund: Es gibt keine fertige Integration. Wer die beiden Systeme verbinden will, baut sie selbst – oder lässt sie bauen. Das ist Fluch und Segen zugleich. Fluch, weil es Arbeit kostet; Segen, weil man die Datenflüsse dann genau unter Kontrolle hat, statt sie einem Plug-in zu überlassen, dessen Innenleben man nicht kennt.

Nextcloud und Copper verbinden: vier Wege mit unterschiedlichem Aufwand

Der einfachste Weg ist der oberflächliche. Die App „Externe Websites“ erlaubt es, eine fremde Webanwendung in die Nextcloud-Navigation einzubinden. Der Copper-Zugang erscheint dann als Menüpunkt in der eigenen Oberfläche, technisch bleibt es ein iframe. Das ist bequem, hat aber Grenzen: Anmeldung erfolgt weiterhin separat, Content-Security-Policy und Cookie-Richtlinien der Browser machen Ärger, und die Daten liegen natürlich weiterhin bei Copper. Als Einstieg für kleine Teams ist es trotzdem nicht falsch.

Der zweite Weg nutzt offene Standards, wo sie vorhanden sind. Nextcloud spricht CalDAV und CardDAV, Copper selbst tut das nicht – es synchronisiert Kontakte und Termine mit Google. Eine Brücke lässt sich daher nur indirekt bauen, etwa über eine Middleware, die Kontakte aus Nextcloud liest und über die Copper-API einspielt. Bidirektional wird das schnell unübersichtlich, weil beide Seiten eigene Vorstellungen von Feldern, Dubletten und Löschungen haben. Wer diesen Weg geht, sollte eine Richtung als führend definieren. Erfahrungsgemäß ist das die bessere Entscheidung: Nextcloud bleibt Quelle für Stammdaten, Copper bekommt eine Kopie.

Der dritte Weg ist der technisch saubere und aufwendigste: eine eigene Integration über die Copper-API und die Nextcloud-Schnittstellen. Copper bietet Webhooks für Änderungen an Datensätzen, Nextcloud bietet WebDAV für Dateien und eine OCS-API für Nutzer, Gruppen und Freigaben. Dazwischen sitzt ein kleiner Dienst – gebaut mit n8n, Node-RED, einem eigenen Skript oder einer Low-Code-Plattform – der Ereignisse übersetzt. Ein Praxisbeispiel: Wird in Copper eine Verkaufschance auf „gewonnen“ gesetzt, legt die Middleware in Nextcloud einen Projektordner an, vergibt Freigaben an die zuständigen Personen und hinterlegt den Freigabelink im CRM-Datensatz. Umgekehrt schreibt Copper eine Notiz, wenn ein Kunde ein Dokument geöffnet hat – sofern man das datenschutzrechtlich sauber abbildet.

Der vierte Weg betrifft die Anmeldung. Copper unterstützt je nach Tarif Single Sign-on über SAML, Nextcloud kann als Identitätsanbieter auftreten oder einen externen Provider nutzen. Eine gemeinsame Anmeldung reduziert nicht nur die Passwortverwaltung, sondern auch die Zahl der Konten, die bei Austritten vergessen werden. Wer beides betreibt, sollte hier zuerst ansetzen. Es ist die unspektakulärste Maßnahme mit dem größten Effekt.

Nicht zuletzt die Dateifrage. Copper speichert Anhänge, aber es ist kein Dokumentenmanagement. Verträge, Angebote, technische Zeichnungen und Protokolle gehören nicht in ein CRM, sondern in eine Ablage mit Versionierung, Aufbewahrungsfristen und Rechteverwaltung. Die naheliegende Arbeitsteilung: Datei liegt in Nextcloud, Link steht im Copper-Datensatz. Wichtig ist, dass Freigaben ablaufen und mit Passwort versehen werden können – beides beherrscht Nextcloud von Haus aus. Wer stattdessen Dateien unnötig dupliziert, erzeugt genau das Problem, das ein zentrales Ablagesystem vermeiden soll.

Wo es in der Praxis hakt

Integrationen scheitern selten an der Schnittstelle, sondern an den Details. Feld-Mapping ist so ein Thema: Copper kennt Firmen, Personen und Chancen als getrennte Objekte, Nextcloud-Adressbücher kennen nur Kontakte. Wer nicht sauber modelliert, erzeugt Dubletten, die sich später kaum noch auflösen lassen. Dazu kommen unterschiedliche Auffassungen darüber, wann ein Datensatz gelöscht ist – in einem System ist er weg, im anderen nur archiviert.

Technisch unterschätzt wird die Idempotenz. Webhooks können mehrfach ausgeliefert werden, API-Aufrufe können in Zeitüberschreitungen laufen, ohne dass die Aktion fehlgeschlagen ist. Eine Integration, die bei jedem Ereignis blind einen Ordner anlegt, produziert nach dem dritten Wiederholungsversuch drei Ordner. Sauber gebaute Middleware arbeitet deshalb mit externen Schlüsseln, prüft vor dem Schreiben und protokolliert jeden Vorgang nachvollziehbar.

Auch die Durchsatzgrenzen sollte man kennen. Cloud-CRMs drosseln API-Aufrufe; wer beim Erstimport Zehntausende Datensätze in kurzer Folge überträgt, landet in der Warteschleife. Bewährt hat sich ein gestaffelter Import mit Wiederholungslogik und einer harten Obergrenze pro Minute. Klingt unspektakulär, ist aber der Unterschied zwischen einem Import, der nachts durchläuft, und einem, der morgens halbfertig abbricht.

Und dann ist da die Rechtsfrage. Wer Kundendaten zwischen einer selbst betriebenen Nextcloud und einem US-Cloud-Dienst abgleicht, braucht einen Auftragsverarbeitungsvertrag, eine Rechtsgrundlage und eine Einschätzung zum Drittlandtransfer. Das ist kein Grund, solche Projekte nicht zu machen. Es ist ein Grund, sie nicht nebenbei zu machen.

Betrieb im Alltag: Updates, Backup, Monitoring

Nextcloud veröffentlicht jährlich eine Hauptversion und dazwischen kleinere Aktualisierungen. Der Upgrade-Pfad führt immer über die jeweils nächste Hauptversion, Sprünge über mehrere Stände hinweg sind nicht vorgesehen. In der Praxis heißt das: Wer zwei Jahre nicht aktualisiert hat, plant besser ein Wochenende ein. Vor jedem Sprung gehören Apps auf Kompatibilität geprüft, ein Datenbank-Dump gezogen und das Datenverzeichnis konsistent kopiert.

Konsistenz ist hier das Zauberwort. Ein Backup, das Dateien und Datenbank zu unterschiedlichen Zeitpunkten sichert, ergibt nach dem Restore einen Zustand, in dem Metadaten auf Dateien verweisen, die es nicht mehr gibt – oder umgekehrt. Bewährt hat sich, Nextcloud vor der Sicherung in den Wartungsmodus zu setzen, dann Datenbank und Verzeichnis zu sichern und erst danach wieder freizugeben. Nach dem 3-2-1-Prinzip sollten mindestens drei Kopien existieren, auf zwei Medien, eine davon außer Haus. Wichtiger als die Sicherung selbst ist der regelmäßige Wiederherstellungstest. Ein Backup, das nie zurückgespielt wurde, ist eine Annahme, keine Gewissheit.

Für den laufenden Betrieb lohnt Monitoring. Nextcloud stellt einen Prometheus-Export bereit, der sich in gängige Überwachungssysteme einbinden lässt; dazu kommen Protokolle auf PHP-, Webserver- und Datenbankebene. Sinnvolle Kennzahlen sind Antwortzeiten, Warteschlangenlänge der Hintergrundjobs, Speicherwachstum, fehlgeschlagene Anmeldungen und der Zustand des Objektspeichers. Wer diese Zahlen nicht erhebt, merkt Probleme erst, wenn Anwender anrufen – und dann meist alle gleichzeitig.

Grenzen und berechtigte Kritik

Nextcloud ist kein Microsoft 365 und wird es auch nicht. Die Oberfläche ist an manchen Stellen uneinheitlich, manche Apps fühlen sich wie eigenständige Welten an, und die Volltextsuche über große Bestände ist nicht mit kommerziellen Produkten vergleichbar. Ende-zu-Ende-Verschlüsselung bleibt in der Praxis ein Nischenfeature. Collabora und ONLYOFFICE sind für alltägliche Dokumente völlig ausreichend, bei komplexen Excel-Modellen mit Makros stoßen beide an Grenzen. Und wer zehntausende Nutzer mit hoher Parallelität betreibt, braucht Erfahrung, Geld oder beides.

Umgekehrt wäre es unfair, Nextcloud an einem Ideal zu messen, das kein Anbieter erfüllt. Der eigentliche Wert liegt nicht in einzelnen Funktionen, sondern in der Kontrolle über Daten, Schnittstellen und Betrieb. Wer die Abhängigkeit von einem Anbieter reduzieren will, bekommt dafür Arbeit und Verantwortung zurück. Das ist der Deal, und man sollte ihn offen benennen, statt ihn schönzureden.

Ausblick: Souveränität als Treiber

Die Nachfrage nach selbst betriebenen oder europäisch gehosteten Kollaborationsplattformen ist in den vergangenen Jahren deutlich gestiegen. Treiber sind regulatorische Vorgaben, aber auch ein gewachsenes Misstrauen gegenüber der Konzentration von Unternehmensdaten bei wenigen Anbietern. Nextcloud profitiert davon, wird aber nicht allein davon getragen. Die Entwicklung geht erkennbar in Richtung offener Schnittstellen und lokal betriebener KI-Funktionen – ein Assistent, der Dokumente zusammenfasst, ohne dafür Inhalte an einen externen Dienst zu schicken, ist für viele Organisationen der eigentliche Grund, sich überhaupt mit dem Thema zu befassen.

Für Werkzeuge wie Copper bedeutet das keinen Gegensatz. Vertriebsteams werden weiterhin spezialisierte CRM-Systeme nutzen, weil Nextcloud dort schlicht nicht antreten will. Die Frage ist nicht, welches System gewinnt, sondern wie Daten zwischen ihnen fließen – nachvollziehbar, sparsam, rechtssicher. Eine eigene Nextcloud mit einer selbstgebauten Anbindung an ein Cloud-CRM ist technisch anspruchsvoller als ein durchgestricktes Paket von einem Anbieter. Dafür weiß man am Ende, wo die Daten liegen und wer sie sehen kann.

Wer heute ein solches Vorhaben plant, sollte mit zwei Dingen beginnen: einer klaren Zuständigkeit für den Betrieb und einer ebenso klaren Vorstellung davon, welche Information wo führend ist. Alles andere – Middleware, Schnittstellen, Automatisierung – lässt sich darauf aufbauen. Umgekehrt führt jede technisch brillante Integration ins Leere, wenn niemand sagen kann, welcher Datensatz im Zweifel der richtige ist. So unspektakulär diese Antwort klingt, sie entscheidet über den Erfolg.