System Architecture
Data model, interfaces and technology choices in writing — with the reasons, not only the outcomes.
- Data model
- Interfaces
- Reasoned
How it works
Our architecture documents are short and written for people, not for a filing cabinet.
The data model
We settle what things exist and how they relate. It sounds dry and it is the most consequential decision in the project: a data model can be changed later, but only with a migration and downtime.
Interfaces
Wherever your software talks to something else, we settle it up front: which data flows, in which direction, how often, and what happens when the other side is down. Especially that last one. Foreign systems are not always reachable, and what happens then deserves to be decided rather than endured.
Technology choices with reasons
We write down not only what we chose but why — and what we rejected. In two years someone will ask why it is like this. Without the reason on record, the decision either gets inherited blindly or overturned blindly.
What we deliberately leave open
Not everything has to be decided now. We mark what comes later and make sure the decision is still possible when it does.
- Access to systems that will be connected, with a contact on their side.
- Your expectation of load and growth: ten users or ten thousand changes everything.
- Constraints we are bound by — server location, existing contracts, in-house standards.
An architecture document covering the data model, interfaces, technology decisions and the reasoning behind them.
If you skip this
Architecture happens with or without a document — without one it accumulates out of individual decisions. That usually carries the first version and rarely the third, and the rebuild then costs more than the original project.
Questions about this step?
A conversation costs nothing and takes half an hour. Afterwards you will know whether we are a fit.