01SYSTEM THINKING
Warum ein IT-Projekt nicht mit dem Stack beginnen sollte
Technologieentscheidungen sind wichtig, aber sie sind nicht die erste Architekturentscheidung. Wenn Datenbank, Framework oder Deployment feststehen, bevor der Prozess verstanden ist, beginnt das Projekt leicht den Werkzeugen statt der Geschäftsaufgabe zu dienen.
Ich beginne meist mit Prozess und Daten: Wer erzeugt Informationen, wo ändern sie sich, was ist die Quelle der Wahrheit, welche Vorgänge sind zeitkritisch, was kann unabhängig arbeiten und was muss den Ausfall einer Komponente überstehen?
Der Stack wird damit zur Folge der Anforderungen. Das reduziert zufällige Abhängigkeiten, macht Updates planbarer und erlaubt Architektur anhand von Ergebnissen zu bewerten: Zeit, Betriebskosten, Verfügbarkeit, Wiederherstellung und Weiterentwicklung.
02OFFLINE-FIRST
Offline-first bedeutet mehr als „ohne Internet nutzbar“
Bei Feld-, GIS- und verteilten Systemen ist die Nutzung ohne Verbindung nur die sichtbare Ebene. Die eigentliche Architekturfrage beginnt, wenn dasselbe Objekt in zwei unabhängigen Replikaten verändert werden kann.
Objekt-IDs, Versionen, Änderungsjournal, Synchronisationsregeln und Konfliktpolitik müssen von Anfang an definiert sein. Nutzer sollten außerdem verstehen können, warum zwei Versionen voneinander abweichen.
Offline-first ist deshalb eine Eigenschaft des Datenmodells und des Projektlebenszyklus, nicht nur ein zusätzlicher UI-Modus. So kann das System instabile Netze tolerieren, ohne unbemerkt die Kontrolle über Daten zu verlieren.
03PRIVATE COMMS
Eigene Kommunikationsinfrastruktur: was über die Serverinstallation hinaus wichtig ist
Ein Nachrichtenserver ist nur ein kleiner Teil einer unternehmensweiten Kommunikationsplattform. In Production kommen Identität, Clients, Sprach- und Videoszenarien, Speicherung, Backup, Monitoring und kontrollierte Updates hinzu.
Migration ist ein eigener Layer. Benutzer, Räume, Nachrichtenhistorie und Anhänge müssen aus einem definierten Quellzustand in kontrollierten Batches übertragen und vor dem Gesamtwechsel geprüft werden.
Der Wert einer eigenen Kommunikationsinfrastruktur liegt in Daten- und Betriebskontrolle. Das Unternehmen weiß, wo Informationen liegen, wie der Dienst wiederhergestellt wird, wer Zugriffe steuert und wie sich die Plattform weiterentwickelt.
041C / OPERATIONS
1C ist mehr als Anwendungskonfiguration: Stabilität beginnt bei der Infrastruktur
Wenn eine 1C-Umgebung langsam oder instabil wird, beginnt die Suche häufig in der Anwendungskonfiguration, obwohl die eigentliche Ursache auf einer anderen Ebene liegen kann: Linux-Serverressourcen, PostgreSQL-Parameter, Storage, Hintergrundjobs, Sperren, Netzwerk oder ein bestimmter Arbeitsplatz.
Deshalb betrachte ich einen 1C-Server als vollständiges Produktionssystem. Applikationsserver, Datenbank, Backups, Logs, Updates, Ressourcenüberwachung und Client-Arbeitsplätze müssen als ein zusammenhängender Betriebsverbund geführt werden.
Der Ansatz beginnt mit Messung: zuerst feststellen, wo die Begrenzung tatsächlich entsteht, danach die richtige Schicht ändern. Dadurch wird der Support planbarer, Wiederherstellung testbar und steigende Last führt nicht zu einer Sammlung zufälliger Tuning-Maßnahmen.
