Wenn die Firewall den Call verbietet: unser ehrlicher Notausgang

Willkommen zur vierten Ausgabe des S7, dem Club der Souveränen. Diesmal lösen wir ein, was wir in der letzten Ausgabe offen gelassen haben: die Terminfindung ohne Microsoft, und die Frage, warum bei einzelnen Kunden bis heute kein Videocall zustande kommt. Außerdem verraten wir, welche Startseite unser Team morgens öffnet, und wie wir Confluence ersetzt haben, ohne die Automatisierung zu verlieren. Eine Antwort in dieser Ausgabe wird Ihnen nicht gefallen, wir stehen trotzdem dazu. Viel Spaß beim Lesen. 1. UNTER KUMPELN: Der Kalender sagte frei, der Kollege saß im Termin Vor zwei Ausgaben haben wir hier erzählt, wie wir Meetings ohne Microsoft durchführen. Jitsi, OpenTalk, Nextcloud Talk, am Ende blieb Nextcloud Talk mit eigenem Backend. Eine Frage haben wir dabei offen gelassen: Wie kommt der Termin überhaupt zustande? Die lösen wir heute ein. Vorweg die ehrliche Ansage: Die Terminfindung hat uns mehr Nerven gekostet als der Videocall selbst. Die Anforderung klingt trivial. Ein Kunde soll einen Termin buchen können, wenn wir Zeit haben. Fertig. In der Praxis hängt daran mehr. Bei manchen Kollegen laufen drei Kalender parallel, einer für Kundentermine, einer für interne Arbeit, einer für Abwesenheiten. Wer Verfügbarkeit prüft, muss alle drei lesen. Und viele Termine finden nicht mit einer Person statt, sondern mit zwei oder drei. Es braucht also einen Link, der die Kalender mehrerer Kollegen gleichzeitig prüft. Gelöst haben wir das zuerst mit Nextcloud, weil Kalender und Kontakte dort ohnehin liegen. Eine Weile ging das gut. Dann kam der Tag, an dem ein Kunde einen Termin gebucht hat, der längst belegt war. Das Buchungsformular sagte frei, der Kollege saß im Gespräch. Für den Kunden sieht das nach Schlamperei aus. Zu Recht. Die Ursache lag in der Kalendersynchronisierung. Die ist bei uns nicht immer zuverlässig durchgelaufen, und ein Buchungssystem ist nur so gut wie die Verfügbarkeit, die es liest. Dazu kam die zweite Lücke: Gruppenlinks gibt es dort nicht als Feature. Wir haben uns mit kombinierten Kalendern beholfen, also mehreren Kalendern, die in einen gemeinsamen zusammenlaufen. Das trägt, solange niemand etwas umstellt. Als Dauerlösung war es Bastelei. Damit sind wir bei der Erinnerung, die wir uns selbst regelmäßig aufschreiben müssen: Nicht alles muss aus einem Baukasten kommen. Nextcloud kann sehr viel, und genau das ist die Falle. Wenn ein Werkzeug neun Aufgaben gut erledigt und die zehnte nur fast, dann nehmen wir für die zehnte trotzdem ein anderes. Ein Monolith spart Logins und kostet Nerven. Wir haben das lange anders gesehen. Heute läuft unsere Terminfindung über cal.diy, https://www.cal.diy/ , natürlich selbst gehostet. Die Kalendersynchronisierung läuft zuverlässig, Gruppenlinks gibt es ab Werk, und ein Kunde sieht genau die Slots, in denen alle Beteiligten wirklich Zeit haben. Nextcloud Talk hängt direkt darin. Wer bucht, bekommt den Meetingraum automatisch mitgeliefert. Kein zweiter Link, keine Nachfrage per Mail. Bleibt das Problem, das wir vor zwei Wochen angeteasert haben. Bei einzelnen Kunden kommt der Call bis heute nicht zustande, und diesmal hilft kein eigenes Backend. Manche Firewalls blockieren Websockets komplett. Websockets sind die dauerhafte Verbindung zwischen Browser und Server, ohne die kein Bild und kein Ton fließt. Nextcloud Talk braucht sie. Jede andere selbst gehostete Meeting-Plattform, die wir getestet haben, braucht sie auch. Wir haben keine gefunden, die ohne auskommt. Die naheliegende Antwort: Die IT des Kunden passt die Regel an. Manchmal klappt das. Oft dauert es Wochen, und unser Termin ist am Donnerstag. Unser letzter Ausweg steht deshalb im Buchungsformular. Wer bucht, kann Teams auswählen. Wir schlagen es nicht vor, wir bewerben es nicht, es steht einfach da. Prio 1 bleibt Nextcloud Talk, daran ändert sich nichts. Aber wir zwingen keinen Kunden in einen Call, der bei ihm technisch nicht funktioniert. Das ist keine schöne Lösung, sondern eine ehrliche. Was wir daraus gelernt haben: Souveränität endet an der Firewall des Gegenübers. Unsere eigene Infrastruktur haben wir im Griff, das Netz des Kunden nicht. Wer das übersieht, verkauft Prinzipien und liefert Ausfälle. So begegnen wir dem. Wir bauen die Kette so, dass der souveräne Weg der Standard ist und der Notausgang die Ausnahme bleibt, die der Kunde selbst wählt. Wir prüfen jedes Werkzeug entlang der ganzen Kette, von der Einladung bis zum letzten Ton, nicht nur an der Stelle, die uns interessiert. Und wir zählen nicht, wie viele Systeme bei uns selfhosted laufen. Wir zählen, wie viele Termine ohne Rückfrage zustande kommen. 2. HAMMER UND SCHLÄGEL: Dashy, eine Startseite statt einer Linkliste im Chat In dieser Rubrik geht es ums Werkzeug. Heute: Dashy, die Startseite für unser Team, quelloffen und bei uns selbst gehostet. Das Problem davor war unspektakulär und trotzdem jeden Tag da. Nach der Migration haben wir viele einzelne Anwendungen im Einsatz statt einer großen Suite. Jede mit eigener Adresse. Neue Kollegen haben in der ersten Woche Links gesucht, statt zu arbeiten. Wir haben Lesezeichenlisten per Chat verteilt. Das war so gut, wie es klingt. Dashy löst genau das. Eine Seite, alle Anwendungen als Kacheln, sortiert nach Bereichen. Der Login läuft bei uns über Keycloak, unseren zentralen Anmeldedienst. Wer sich morgens einmal anmeldet, sieht seine Kacheln und kommt mit einem Klick weiter. Jeder Kollege legt sich zusätzlich eigene Links ab, ohne dass wir etwas konfigurieren müssen. Warum wir das so machen: Wer viele kleine Werkzeuge einsetzt statt einer Suite, braucht einen Einstiegspunkt. Sonst zahlen Sie die Souveränität mit Sucharbeit. Dashy ist der unscheinbarste Baustein in unserem Stack. Kunden fragen nach keinem häufiger. 3. ERFAHRUNG AUS DEM CLUB: Confluence ersetzen, ohne die Automatisierung zu verlieren Diese Frage hat uns per E-Mail erreicht: Womit ersetzen wir Confluence, wenn daran viele Automatisierungen hängen? BookStack allein war für den Fragesteller keine echte Alternative. Händisch dokumentieren wollte er nicht, und das verstehen wir gut. Wir standen an derselben Stelle. Unser alter Atlassian-Stack war durchautomatisiert, und gerade für Zertifizierungen wie die ISO 27001 hängt daran mehr, als es zuerst aussieht. Nachweise, die sich selbst zusammensuchen. Freigaben, die von allein weiterlaufen. Wer das per Hand macht, macht es irgendwann nicht mehr. Unsere Antwort heute: BookStack und n8n, beides im Selfhosting. BookStack ist die Dokumentation, n8n die Automatisierung. BookStack allein hat unsere Anforderungen nicht erfüllt, das ist auch nicht seine Aufgabe. n8n greift über die Schnittstelle von BookStack zu und schreibt, verschiebt und prüft Seiten. Drei Schritte aus unserer Praxis: Erstens: Schreiben Sie eine Woche lang auf, welche Automatisierungen in Confluence wirklich laufen. Bei uns war die Liste kürzer als erwartet, und die Hälfte hat hinterher niemand vermisst. Zweitens: Trennen Sie Dokumentation und Automatisierung bewusst. Ein Wiki, das alles selbst können soll, wird nie so gut wie ein Wiki plus ein Werkzeug, das nur automatisiert. Drittens: Bauen Sie zuerst die zwei Abläufe nach, die vor einem Audit weh tun. Alles andere kommt danach, oder gar nicht. Nach der Eingewöhnung können wir mehr als vorher, und die Abläufe sind besser wartbar. Der größte Gewinn ist ein anderer: Kein Anbieter verschiebt uns mehr ein Feature in ein teureres Paket, versteckt es in einer neuen Oberfläche oder stellt es ganz ein. Die Eingewöhnung war unbequem. Bereut haben wir sie nicht. Haben Sie auch so eine Frage rund um digitale Souveränität, Migration oder sichere Zusammenarbeit? Antworten Sie einfach auf diese Mail, sie landet direkt bei mir. Die spannendsten Themen nehmen wir uns hier vor, konkret und mit Handlungsschritten statt Beratersprech. Glück auf, Chris