> > > PhilosophyPhilosophyWhyCaseDies

Why CASE Tools Die: The Case for SOTER

Thesis

Business is not a picture — it is not static — it is a complex network of dependencies, intentions, and flows. Classic CASE tools (Sparx Enterprise Architect, Visual Paradigm) treat a model like a technical drawing from the 1990s. SOTER treats it as a dynamic, text-first data system, and this difference is what lets it survive where CASE tools eventually die.

Problem

In tools such as Sparx Enterprise Architect (EA) or Visual Paradigm (VP), model creation begins with placing a box on a canvas. This looks fast, but it is a trap: in traditional CASE, the diagram is the model. When you move a box, you change the formatting, not the logic. You spend 80% of your time ensuring arrows do not overlap and text remains readable.

This pattern repeats across several dimensions of the tooling:

Model files (.vpp, .eapx) are treated essentially as binary files. Storing them in version control systems — or in relational databases — is a nightmare. You cannot run diff on binary files; you cannot see exactly what a colleague changed in Tuesday's version, and querying a relational database to find specific changes is inefficient and time-consuming.
Traceability becomes tedious manual work — remembering to draw connecting arrows and link requirements by hand.
Consistency across diagrams (e.g. keeping a renamed element correct everywhere it appears) has to be maintained manually.

Argument

Ontology first, presentation second

In SOTER, you focus on the ontology. You write a relationship in Logos, and the system handles its presentation. If you rename a Subject in one place, the change propagates automatically to every view (GDPR, legal, operational) without any manual effort. In traditional CASE you are a DTP graphic designer. In SOTER you are a Business Architect.

Separation of model from view (M ≠ V)

This is the foundation of MDA (Model-Driven Architecture), which traditional tools have forgotten.

Feature	Traditional CASE	SOTER (Logos)
Definition	You draw a diagram to record data.	You define data to generate a diagram.
Consistency	You must manually synchronise diagrams.	One `.model` file drives an unlimited number of `.view` files.
Perspective	Diagrams are "rigid."	Views are dynamic (filters, transformations).

In SOTER a model can exist without diagrams, but a diagram cannot exist without a model. This enables the generation of "views on demand" — for example, an audit view that is produced in a second from the same code as the operational process.

Traceability as an intrinsic property of the code

In SOTER, traceability is not "drawing relationships" — it is indexing reality. Because global identifiers (UUIDs) and the use: keyword are used throughout, the model always knows:

Which established rule (Object: Memory) affects which Action.
Which Subject is a bottleneck in 15 different processes.
Exactly where energy (cost) is leaking across the entire organisation.

Git flow: history, not just a save date

Real analytical work in large teams means version conflicts. In SOTER, the model is pure text (Logos). You can see every changed attribute, every new action in standard git diff output. You can run Code Reviews for business processes — something a binary CASE file format cannot offer.

From SBVR to executable architecture

If you appreciate SBVR, SOTER is SBVR that stopped being dead letter. Thanks to the triad structure (Subject-Action-Object), your model becomes the database for the Organisational Daemon (see Milestones 2 and 3). You can "query" your model for a simulation — "What happens if we remove Subject X? How many Actions become orphaned?" — as a graph query, where in traditional CASE you would have to search for and count this manually.

Implications for SOTER

SOTER's architecture must preserve the model/view separation and text-first storage as non-negotiable properties: they are the direct answer to each failure mode diagnosed above (visual debt, manual traceability, unreviewable binary history). Any feature that reintroduces diagram-as-model editing would reopen the same failure mode CASE tools suffer from.

Boundaries

This argument does not claim that diagrams are worthless — generated views remain useful for communication and audit. It claims only that the diagram must not be the authoritative artifact. It also does not claim that moving to Logos removes all analytical effort; it relocates that effort from formatting to ontology design.

Operational Consequences

Diagrams and other views are always generated from .model/.view source; they are never hand-edited as the source of truth.
Renames and structural changes are made once, in the model, and must propagate to every view automatically.
Model changes go through the same review discipline as code: git diff and code review, not file comparison tools for binary formats.

Open Questions

Moving from click-based modelling to Logos is the same evolution that developers went through when they moved from visual form builders and drag-and-drop RAD tools (like Delphi) to writing code in a modern IDE like VS Code and managing it in Git — what onboarding path minimises the pain of that transition for analysts used to CASE tools?