01SYSTEM THINKING
Why an IT project should not start with the stack
Technology choices matter, but they are not the first architectural decision. If a database, framework or deployment model is selected before the process is understood, the project can quickly start serving its tools instead of the business problem.
I usually begin with the process and data map: who creates data, where it changes, what the source of truth is, which operations are time-critical, what can operate independently and what must survive the failure of one component.
The stack then becomes a consequence of requirements. This reduces accidental dependencies, makes upgrades more predictable and lets architecture be discussed in terms of outcomes: processing time, operating cost, availability, recovery and the ability to evolve.
02OFFLINE-FIRST
Offline-first is not simply “works without Internet”
For field, GIS and distributed systems, opening the application without connectivity is only the visible part of the problem. The real architectural complexity begins when the same entity can change in two independent replicas.
Identifiers, versions, change journals, synchronisation rules and conflict policy need to exist by design. It is equally important to explain to a user why two versions differ and what decision the system is going to make.
Offline-first is therefore better treated as a property of the data model and project lifecycle rather than an extra UI mode. Designed this way from the start, a system can tolerate unstable connectivity without silently losing control of its data.
03PRIVATE COMMS
Private communications infrastructure: what matters beyond installing a server
Deploying a messaging server is a relatively small part of a corporate communications system. Production introduces identity, client applications, voice and video scenarios, storage, backups, monitoring and controlled upgrades.
Migration is another layer. Moving users, rooms, message history and attachments requires a frozen source state, controlled batches and validation before the entire organisation changes over.
The value of private communications infrastructure comes from operational and data control, not simply from installing software. The organisation knows where information lives, how the service is restored, who governs access and how the platform can evolve.
041C / OPERATIONS
1C is more than application configuration: stability starts with infrastructure
When a 1C environment becomes slow or unstable, investigation often starts inside the application configuration even though the actual bottleneck may sit elsewhere: Linux server resources, PostgreSQL settings, storage, background jobs, locks, networking or a particular workstation.
I therefore treat a 1C server as a complete production system. The application server, database, backups, logs, upgrades, resource monitoring and client workstations need to be operated as one coherent environment.
This approach starts with measurement: identify where the constraint actually occurs, then change the appropriate layer. Support becomes more predictable, recovery can be tested, and increasing load does not lead to a collection of unrelated tuning changes.
