Small number of developers can hardly cover a large number of applications

Issue

The problem arises, for any company, and IT within it, if we approach such a large number of applications in the usual way, which is to make special applications for every research / project. It may then happen that applications are developed on different platforms (VB, C ++, C #, .Net, Java ...), that data is stored and processed in different places, from the server to the local machine, in various formats, from relational database to text files. For many years, the SORS has been a user of a mainframe computer and that further complicated data processing on 2 platforms.

Things are further complicated by writing technical documentation and it is easy to lose control of the work process if even a single developer drops out. This kind of development environment largely depends on technological changes.
Data processing and process automation, not only in statistics, but anywhere, always consist of 3 main phases: the entry of data, data editing and processing, and report generation. Looking at things this way, we realize that we constantly write the same 3 programs. Tired of writing endless lines of code for data input, data edit and processing, and report generation, we decided to take a look at the problem from a completely different angle.

Approach
We needed a development environment in which there is no programming, in which the applications are uniform, standardized, easy to make and not dependent on constant technological changes (new development tools, programming languages, platforms). This is the goal that we have set for ourselves, now we have to find a way to achieve it.
How about, besides storing data in databases, we also stored applications themselves in databases?
Solution

We decided that the basis of everything should be what we know best - relational databases. Certainly the data are entered into the databases and reports are made against them. How about, besides storing data in databases, we also stored applications themselves in databases? We came up with the idea that it would be best to somehow describe the application in detail, to keep this description in a base (metadata database), and to develop a program that will interpret this knowledge base and in real time generate (based on descriptions from that database) entry, editing, advanced search, reporting and data processing.
As an important goal, we set a requirement for the metadata to be extremely user friendly oriented because it would serve developers to develop applications through description, and a requirement that a program which interprets metadata, must also be extremely user-friendly because it needs to serve end users of our applications - statisticians, companies and individuals who delivered data to us.
So we came to the following concepts:

  • A simple metadata database - IST metadata
  • A program that interprets metadata - IST program