ERROS - A new era?
An invention that turns development on its head.
Last month, we mentioned that something had been brought to our attention that we felt could and should change the way we develop applications, and that that something was ERROS.
This month we look at what ERROS means to us and how the concept holds the above statement true. For this month's introduction to ERROS, we have been allowed access via the Erros PLC web site to conduct an initial investigation.
ERROS is a totally new concept, with plenty to absorb, so I will not go into excessive detail in this article, instead choosing to concentrate on the principles.
This article will draw heavily on the theory of ERROS available through the Erros PLC web site, in papers written by Rob Dixon, the creator of ERROS. These papers provide much of the information as to why and how ERROS was created.
However, to speak objectively, I needed to try ERROS for myself. The way ERROS applications are developed is a new concept to me, and therefore took a little time for me to become familiar with the navigation and functionality.
Once you have become familiar with the application navigation, the steps to build the application are quick and easy to execute as the application builder takes you through logical steps to build your application. Within a little over 90 minutes, I had followed the steps to build the sample "Video Shop" application provided from instructions on the Erros PLC web site. Needless to say I will be tracing my steps again to ensure I fully understand the steps I was taking, as well as conducting the application test which will feature in our next comment on ERROS. However, the sample application was built and initially run without one line of code written, no DDS definitions and not one compilation. All steps added "records" to the Neural Database (more about that later) and was instantaneously available to the application!
The test application was built over the internet through a Work Station Gateway (WSG) interface using my regular browser. Had I undertaken the test using Client Access or another 5250 emulator, I believe I could have completed it comfortably within the hour, even though I had had no training and had not seen a demonstration of ERROS. Even so, the application could have been used over the Internet immediately, and without any modification
Invalid Page Fault
I really did "IPF" at my first reading of the story behind ERROS. On further reading I discovered that it was not my inability to understand, but that it goes against the grain of what I know about application design. For years, we have worked with the Relational Database model, defining database files with the formats of Header, Detail and Trailer types, each linked to the other by a "key" field that allows us to read in one Header and access other records by a key value. Occasionally, we might put all the data in one physical file, identified by a record type, and then revert back to the original model by providing logical views over the data to read Header, Detail and Trailer records. Looking at that database model, we live with the overhead of multiple ODP's, Chains/Reads and whatever, because that is how it is done and any contradiction to that model is illegal, at least in our current mindset.
A huge part of our employment, stems from the fact that there is always a need for change. Nobody can ever envisage all the field definitions that a database will need during its life span. And as soon as a change needs to happen, it is someone like you and I who has to identify areas of use, specify change requirements and make the changes. And then move onto the next change request.
ERROS does not work within the constraints of that model.
ERROS does not conform to the same change procedures to enable applications to grow.
Hence my IPF!
Connectionism as a Concept
ERROS works using the Connectionism concept. On the ERROS web site, the papers illustrate the concept of Connectionism by describing the concept of the Human Brain. In brief, the Human Brain in its developing stages takes on board data and stores it as an entity, for instance recognition of a "Dog". As the brain develops it is able to recognize a "Cat" also. Eventually the understanding of "Dog" and "Cat" are connected to a separate entity "Animals", as well as the fact that animals come in different colors, so "Color" is and entity and "Black" is an entity linked to "Color".
The Human brain continues this process, not just in our developing stages, but throughout our entire lives.
My description above is very simplistic. The papers on the Erros site describe the relationships much more eloquently, as the distinction is made between "entity types" (a collection of "things" having similar characteristics that may conveniently be grouped together) and "entities" (instances of entity types). Putting this into "OO" speak, these may be referred to as "classes" and "instances". So putting my example to work, we see that "Animal" and "Color" are "entity types", because they "contain" other "entities" such as Dog and Black. The terminology used here can be a little daunting, but only explains how the Neural Database is derived, and should NOT make you feel that ERROS must be very confusing!
The example attempts to illustrate that the Human Brain does not store objects in lists, but scatters objects/entities around the "gray disk" and connects them when necessary. This is NOT very much like our standard database models.
This concept, when applied to database design, leads to the birth of a Neural Database. The idea is that the database elements can be dotted around, almost free floating, and only come into play when connections are added. This means that elements can be added when and if they occur and will become active when a connection is added. A huge random pattern of dots, connected up, down, side to side, by bi-directional connectors, and yet no URL's are used for these connections.
In theory, the database has no "fixed" limits in the way we know them today. To put some numbers to that, an implementation of ERROS allows the maximum amount of data in a single logical record to be 130 x 1 Billion to the Power of 2 bytes! And that lower level attribute explosion can be as deep as 999,999,997, each of which can be iterated or repeated the same number of times!
I apologize if throwing those numbers at you clouded your interpretation of the concept, but are necessary to come to terms with the immense scope that is involved with ERROS. There is little given away about the actual physical construction of the Database, but the information provided on the site describes the concept excellently. The concepts of ERROS have successfully been patented by Erros PLC.
One of the examples of the uniqueness is the lack of "white space" created by the application. In a normal Customer Master file, you would have DDS defined for the physical file, containing at least Name, Address and Telephone Number (imagine a very simple design here). At first you may populate the file with 100 Customer names, but at this point you do not have addresses or telephone numbers. You will have 100 records in the file, but a large percentage of each of the record space will be blank.
Where a customer has more than one address or telephone number, ERROS copes without a problem (up to 999,999,997 of each per customer!). You do not need to decide when building your database how many spaces to allow for telephone numbers for each customer.
With ERROS, address and telephone numbers are different entities, which means space is only taken up when used - the concept of a record with fixed field definitions within a physical file becomes redundant!
This is only the tip of the iceberg. As new entities are added, data is stored in the existing database (no new files) within its "context", and is only retrieved by the "context" in which it is stored. Once an entity is created it can be reused throughout the application, and when a new entity is added, it exists in the same database, so there are no program changes or display file changes and it is ready to be used by any application created now or in the future. Most programming becomes redundant!
To quote from the above: 'ERROS allows very complex integrated systems to be developed in simple incremental steps, without any specification, without detailed database design and, most of the time, without any new hand coded or computer generated programs being created. ERROS systems, because of the extreme simplicity of their underlying structure, are very stable and perform much more quickly than others. They can be changed whilst "live". Development is done by staff with much less training and experience than is required for traditional methods, in a small fraction of the time, at much lower cost.'
So how? ERROS is NOT a case tool. It is an application that controls and permits the building of other applications, akin to a Kernel type application, using, essentially, one database for the storing and the retrieval of data. With my still limited understanding, I can only begin to describe it as applications within applications. What has been achieved is the separation of the database logic from presentation logic, which probably makes up 80% of current programming activity. The presentation being handled by the Kernel.
The idea of separating database and presentation logic is not new, nor is it responsible for the breakthrough provided by ERROS, although it helps. The big difference comes from ERROS giving you the ability to store most of the business logic within the Neural Database, where it can be easily changed. Other database methods require coded programs, that make change difficult in both effort and planning.
The footprint of ERROS is incredibly small! Weighing in at an amazing 50,000 lines of code compiling to approx. 4.5mb, and a database of 60mb which is shared for both development and operational environments. This intrigues me even further.
At present ERROS only runs on the AS/400, but if it were ported, the database element would remained unchanged, but code would need to be reworked giving a potentially different size.
In the "Short Description of ERROS" paper, a test at an IBM Lab is described, where the creation of a basic Hospital system, estimated to take 10 man months by IBM experts, was built in just over 2 HOURS on the same model AS/400 by people who had no training or had not seen a demonstration, using ERROS. Words cannot describe!
Further more, all applications on the same AS/400 created using ERROS are automatically integrated with each other, even if the developers do not communicate. At last, companies take control.
Looking to the future, we find that the enhancements required to enable ERROS to be used as a server for Intranet/Internet applications, with "on the fly" HTML generation and the serving of images, required only a small amount of program code to be added.
ERROS is designed to allow you to quickly deploy flexible and future proof applications, but will not eradicate programming entirely. What it does give you is the ability to react to change swiftly and with minimal interruption and risk. This way of working will free up resources who currently spend time reworking standard applications to look more to the future in terms of business projects.
As, an example, during my build of the sample application I made mistake, which at first glance, rendered the application unusable. Rob, who as it happened was not in the UK at the time I conducted the test, was able, also over the Internet, without my knowing, to spot my simple mistake and identify the cause in under 30 seconds. This is because all specifications that I had entered were visible in everyday English (although they could have equally been in French or German or any other language handled by my keyboard). It would have taken considerably longer had my error had been caused by a program bug. It would have been necessary to identify which programs had been created or changed and then to discover the flaw.
To resolve the problem, no programs were changed, and the error pinpointed and resolved within minutes. No debug. No program change. No re-implementation.
An interesting fact about the application I built was that in creating and testing the application no new AS/400 objects were created. As no objects were created no additional or changes were required for backup procedures. Because journalling was being used, if an automatic SAVCHGOBJ procedure was running at regular intervals, the backup would occur whilst the system was live without the requirement of any action or new procedure being needed.
So, as well as future proof, we should also read near Bullet Proof!
Our Next Step
This article is a very potted and a somewhat uneducated view of ERROS. My next step will be to meet the author of ERROS and see for myself the power behind the mask. Our initial investigation has proven that the application of ERROS works well, but look forward to seeing the creation of a new collection of applications, and gain more information on this ground breaking development.
Although my intrigue makes me want to know more about the architecture that makes it all possible, it detracts from the spirit of ERROS in that you really do not need to know. This, if as good as I think it is, could put an end to programming as we know it, and put the control back to the companies to decide how data should best work for them.
In the next feature on ERROS I hope to bring back more information on the concept and potential of ERROS.
Meanwhile, read the papers and maybe try it for yourself at http://www.erros.co.uk