The story of Storga

The programming glass wall

If Pliant represents a major advance for exceptional developers in terms of productivity, because of the elimination of inconsistencies and limits in terms of expressiveness that leveled productivity down, on the other hand, we remain in a traditional development system. , so we find the traditional limits:

Storga was born as a complement to this great development tool. When, for the reasons just mentioned, we don't want to launch development, what do we do?

Storga's starting point is therefore specifications aimed at mastering complexity.

Storga's specifications

As we have just said, the goal was to go further than Pliant in terms of reducing complexity. We therefore naturally built the specifications by a simple inversion of the previously encountered limits. Which give :

And we could add a fourth constraint which was found to be satisfied in fact:

What makes these specifications, constructed in a somewhat naive way, valid is that it guided us very effectively, was a good guideline, to move from the initial idea to the operational product that is today Storga.

The birth of Storga

Storga started in 2010 as a simple collaborative word processor to which we added a system of free forms, and simple reporting of these forms.
The originality was that to satisfy the second constraint, we planned from the start that each form could exist independently of all the others, as on paper, that is to say without having its data plunged into tables that would create a dependency between different instances of the same form.
Thus, we can modify a form without having to worry about the recovery of existing forms.

During this first phase, forms and reports were mainly used to deal with the notion of project. What are the current projects, what are the projects managed by each person, who asked what, when, from whom?
What made Storga more interesting than a project management application written in Pliant is precisely that in terms of project management, the variations are endless, and the data to be processed very varied (emails, scans, and office documents exchanged) and that even within a single company, the optimal way to manage a project tends to differ between the many new small projects and the few main projects.

The system of records and reports has turned out to be so practical that we have started to use it everywhere: contact records, expense reports, then accounting entries.
All things that we could have dealt with in specific applications, but for which Storga's flexibility seemed preferable to us as an investment in the future because change became technically possible and economically realistic at any time.

As the use of Storga multiplied, the files were enriched with the notion of under table, and became real small spreadsheets, but always taking scrupulous care not to go beyond the initial specifications.
For this we have given ourselves rules which may seem arbitrary at first glance, but which guarantee effective freedom, via respect for the initial specifications, just as the laws in democracies guarantee effective freedom. For example, in the case of Storga, a record can consult all the others, but not modify them.

Then, in 2014, we started to consider more complex deployments in Storga which showed us that in addition to the elementary files and reports which filter and list them, we also need summary files which allow us to understand the activity at a higher level, and which are therefore the basic tool of consolidation.
To illustrate consolidation sheets, let's take the example of stock management. At the lowest level, we will enter input and output files. At a higher level, we also want for each type of product to have a record indicating the quantity currently in stock, which will be updated automatically, in order to be able to compare it with a desired minimum stock value indicated in the same record and deduce the state of the replenishments to be made.

The automatic management of consolidation files required intense research in order not to depart from the initial specifications, then showed the need to boost the tool in order to be able to manage not thousands but millions of files.
Once these difficulties were overcome, we were amazed to see that Storga was now conceptually capable of processing everything that a classic relational database can handle, and therefore that Storga had become a theory (i.e. a way of representing a complex system of data) competing with the relational model.

From there, the consequences were more or less imposed on us: we managed to develop, by following cross paths, not a niche product, but a central system for the back office IT of tomorrow, since representing a significant improvement in terms of adaptability compared to the relational model currently used almost everywhere. We got there after a lot of work, and we are convinced that we cannot get there directly by a great idea that we have one beautiful morning. We got there by chance all the same, or more exactly by successive trial and error, because we absolutely did not have a clear picture at the starting point of the dimensions of the field of use that we would manage to meet while respecting the initial specifications. .

Today, the theory that supports Storga, in the sense of the representation of things, has been established, and yet we continue to experiment and discover what it allows in terms of automatic storage of data, or automatic processing of files.
Added to this is the optimization of the implementation, which as with the relational model will probably experience significant improvements for many years.