Three ways a system can be wrong
A business system can be wrong in three different ways. The rules can be wrong. The order in which work moves between people can be wrong. Or the software can fail to do what the rules and the order say. Siege keeps these as three separate layers, and each layer is checked against the other two.
Layer | What it holds |
|---|---|
The Ontology | The rules: what each action changes, and what must be true before it can happen. |
The Choreograph | The order of work across the business's teams, drawn by Siege with the business, from how the business actually works. There is one for each kind of work the business runs (a standard order and a rush order, for example). |
The application | The running software that the business's people and agents use every day. |
Each layer can change as the business learns. The moment two of them stop agreeing, the cross-check says so, before the disagreement reaches a customer.
The cross-checks
Between | What is guaranteed | What a reviewer could watch happen |
|---|---|---|
Ontology and Choreograph | Every disagreement between the rules and the order of work is raised. The comparison runs again every time a change to the model lands. | Each disagreement is written in plain words, one line each: "The Choreograph says this; the Ontology says that." Siege resolves every one. Where the answer turns on a fact about the business that only the client knows, Siege asks, and records the answer with who gave it and when. Until it is settled, that order of work cannot be run against the software. |
Ontology and application | Every change to the client's database names the model revision it comes from, and the client's deploy refuses one that was not written from the client's own Ontology at a revision on its live model. Before a new action is offered in the client's instance, it is tried against a sample of the client's real data, read through a read-only login that the client issues and can revoke, and the trial reports what came out right, what did not, and what it could not prove. | The deploy refuses a database change that does not match the client's live model. A trial leaves live data untouched, and shows it: the live tables' row counts are the same before and after. |
Choreograph and application | The order of work is walked through the running software from start to finish. Places where work gets stuck come back as named gaps to close. | The gaps are listed step by step, in the business's own words, and each one is closed before the work is called done. |
Guarantee
A contradiction between the rules, the order of work and the software is caught when someone introduces it, and Siege resolves it before it reaches a real order in front of a customer. The client is never handed an engineering call; it is asked only for facts about its own business.
Guarantee
Every condition the business states is written so the cross-check can test it. A condition that only a person can judge is marked as such. The cross-check names it as a person's call and never reports it as passed.