Custom Software & CMS

An off-the-shelf product brings its own data model with it: the model decides which records are kept, which fields a space has, and in how many steps a transaction closes. When an organisation's way of working only approximately fits that model, the difference is covered by what staff memorise — a field kept in two lists, a table moved by hand, an exception written nowhere. Writing a purpose-built interface takes that difference off the person and moves it into software.

The model itself decides how long the application lives. Building, floor, space and equipment are defined as a hierarchy. Live state and historical record are stored apart, because one is overwritten continuously and the other is never deleted. Measurement series and the event log take different structures: one is read for trend, the other for sequence and reason. Roles separate seeing from commanding and from changing configuration; when every command carries who issued it, the answer to a question asked later stays in the record.

Managing content

The point of content management is that changing a text or an image does not wait for a developer. Once template and field are separated, the page layout stays fixed while the content is updated; version history makes a wrong change reversible and preview shows it before it goes live. Multilingual fields held in the same record make a translation one face of the content rather than a separate copy.

The second year

The second year of an application is harder than the first. Without dependency updates, data migration, a rehearsed restore from backup and a versioned interface contract, a working product quietly falls out of maintenance. Talking to field devices belongs to a separate layer: the application reads the model that layer presents, hands it the command, and never has to know which protocol a device uses.