I sometimes explain that one of The-Data-Box interesting characteristic is to have its features managed at the record level. But what does it mean exactly? As I often find myself in trouble to explain this clearly, I’ve decided to make 2 small pictures that summup the difference between common applications and The-Data-Box. First, here is, in a very simplified way, a common application paradigm :

In short, the application manages a collection of features that interact with application data.

This model has at least two consequences :

1. If you add or delete a feature from the application, all the data is impacted by this change
2. The data is not aware of what’s happening at the higher level : for example, if a record is following a workflow, and suddenly this workflow was deleted from the application before the end of the process, then the record becomes dead, or at least it falls into a non-consistent state (unfinished workflow).

With The-Data-Box, the central idea is to keep data self-consistent and state-consistent.

To achieve the state-consistent goal, we plug the features at the record level, like this :

This principle has many advantages :

1. A record is aware of the features it uses
2. A record is the guardian of its own state regarding these features (for example : a record could start its workflow in a system A and go on its workflow in a system B)
3. Deleting a feature which is currently in use by one or more records will not happen because each record provides a lock mechanism over the feature(s) it uses. Here is what’s happening in The-Data-Box if you try to delete a feature used by some records :

In another article, I’ll try to explain how The-Data-Box records are also self-consistent.