The Lord of Fields Awakens – Origin of the A12-Tools

The original concepts and early versions of a software often leave traces that remain visible even after years of further development. This also applies to our Enterprise Low Code Platform A12. But what did the beginnings of tool development look like? What continuities are there to this day? A software-archaeological look at our tool factory.

Unlike physical tools such as hammers and chisels, digital tools change shape much more quickly and drastically. Nevertheless, a core often remains. There are continuities that extend from the original version to the present. This is also the case with the Enterprise Low Code Platform A12’s modeling tools, which business analysts can use to design parts of an application without programming knowledge.

We set off in search of clues and initially land in 2013, a time when Pope Benedict announced his retirement, Edward Snowden revealed the NSA affair and Avici stormed the charts with “Wake me up”. mgm had already gained initial experience with model-based software development through a software project in the tax field and recognized the enormous potential of this approach for complex business applications.

By specifying a significant part of the business functionality in models and having engines interpret them or generate code from them, the effort required to adapt the software drastically decreased. In this way, a major cost driver of complex business applications could be effectively tamed. Based on this realization, mgm started a development initiative to open up the advantages of model-based development for further customer projects in a more comprehensive and structured way. The first modeling tools were also developed in this context.

From manually created models to the first editors

We edited the first models manually as XML files

In the early days of XYZ, modeling tools were more of a niche product. The platform under development was mainly used by mgm employees. Almost all the people who came into contact with it were software developers who could create the necessary models without special editors. “We still edited the first models manually as XML files”, recalls Erik Neumann, who was involved in the development of A12 at an early stage. „Even years after the first modeling tools appeared, some colleagues preferred to edit their models directly in XML“, adds Baschir Jaghoori, who today leads the Engine & Client-Team of A12.

Although modeling tools initially had a rather optional character from the developer’s perspective, their importance for the concept of model-driven software development was clear from the beginning. Even if the development team relies on models and does not have to program out the modeled content, there are clear productivity advantages. However, if those business experts responsible for the software can then also edit the models themselves, further communication, coordination and translation efforts are eliminated. This vision, which was popularized a few years later in the low-code environment by the term “Citizen Developer”, motivated from the very beginning the tool development of A12.

Data and Form Modeling: One Tool per Model

A12 initially focused on the model-driven implementation of online forms. There were two types of models. One described how the form was structured. This was the Form Model. Another defined the underlying data structure and validation rules, i.e., which fields with which data types existed and which values were allowed for these fields. This model type was called Document Model, because the technical handling was document-oriented. The separation between the data and the form was also promoted by XForms being used – a W3C standard for online forms.

We deliberately made the tools very similar so that users could quickly find their way around

The initial tool landscape of A12 followed the principle of “one tool per model.” “First, we created the editor for the Form Model, which was significantly more complex than the Document Model,” says Erik. “Then we took a copy of the editor as the basis for the Document Model editing tool. We deliberately made the tools very similar so that users could quickly find their way around.” Technically, they were based on Eclipse RCP (Rich Client Platform), which allowed them to be quickly implemented in a platform-independent way – for Linux, Mac and Windows.

Originally, the tools were named after legendary figures and historical celebrities. The editor for Document Models was called Picus – like the Roman god of fields and forests. The form editor was named Melies – in reference to the French film pioneer Georges Méliès, who founded one of the first film studios near Paris in 1896. A few years later, when the tools were increasingly used by external parties in the context of software projects, more descriptive names came into use. Picus became the Data Modeler and Melies became the UI Designer.

Blueprint for Model Representation

The first versions of the tools still offered a fairly clear range of functions. “You could create model elements, nest them inside each other, and save the whole thing. And there was a rudimentary support for entering rules,” Erik explains.

The basic structure of how we represent models is still the same today – even though there are additional visual perspectives now

But even from those first versions of Picus and Melies to the current generation of tools – the Simple Model Editor (SME) – there are continuities. “The basic structure of how we represent models is still the same today – even though there are additional visual perspectives now. We have a tree view for the model structure. If you click on elements in it, they become editable,” says Baschir. “Other representations and editing options would have been thinkable here. But users apparently found and still find this structure very clear and easy to use.”

Growing Functional Scope and User Base

In the years starting in 2013, the development of both tools was strongly driven by the requirements of the projects that were already using A12 at that time. A first significant enhancement was the support of so-called includes. They allow existing Document Models to be embedded in new Document Models. This supports a more modular data modeling and reduces the cases of copy & paste.

As of 2015, a technological shift occurred for A12: the move from XForms to JavaScript. More functionality shifted to the client side. As a result, models were persisted in JSON. While editing XML files manually was still comfortable, this is not the case with the JSON format. Those who edited models without the editors were at a disadvantage anyway. The increasingly mature tools offered a lot of convenience functions and simplified model creation – for example, with validation tests and a preview function for forms that could be called up at the push of a button.

A New Model – Not a New Tool

Also in 2015, a new model was added for the first time: With the help of the Overview Model, table-like overviews could now also be modeled. Compared to the Form and Document Model, however, it was significantly smaller and did not justify a separate new tool. The editing options of the Overview Model were integrated into Melies or the UI Designer. This was the first time there was a tool that supported multiple model types at once – and a taste of what was to come.

In the following years, the modeling concept of A12 was continuously extended – both in terms of data modeling and the model-based design of parts of the user interface. The Lord of the Fields grew up and reached the autumn of its life cycle. With the SME, a new tool joined in 2019 that was to usher in the next tool generation – and which is the subject of the following part of this series.