Modelling, what is that actually?
In my previous post about low-code and no-code platforms , I discussed what these platforms can and cannot do. In short, their goal of making code superfluous by replacing it with a graphical editing environment, is useful for certain types of applications and developers. However, it does not help if you have to create more complex applications. The point is that the modeling language(s) under the hood should actually be better. And that has not changed significantly with these platforms.
Ask developers of complex applications what makes it so complex and you can take for granted that they will not say it is because they have to write code instead of dragging and selecting in a graphical editing environment. In fact, I suspect that most would find it a terrible idea to have to do that. It sounds slow and inefficient and it would probably be true.
What makes the development of large applications so complicated is that you have to keep all kinds of different components (gui, data model, processes, several interfaces) in synch, while not having certainty about where a certain functional aspect has already been recorded and whether that might have happened several times in different locations. And that you do not know after each modification whether the application still starts and works as intended.
You will probably hear anecdotes like: “I remember the discount calculation that had to be adjusted; it was included in the GUI, in the external interface towards invoicing and somewhere else in a batch process that was run at night to calculate the forecasts. It took us a lot of time to find, adjust and test that. And it had to be repeated a few times.” Many similar projects fail or are never even started. Instead, an extra layer is created around the existing software to add the changes without affecting the original application. And so, of course, complex software is becoming increasingly more complex.
That is why the focus in the development of Alan has always been on developing a better modeling language, which keeps the important functional aspects together, so that you can always find them in one place. This can be fully checked during modeling, including external links and UI, so that bugs can be prevented and unit testing is not required. And from which a fully functioning user interface can always be generated. The graphic shell around the modeling language will also be added later on, because in certain cases it is simply useful.
To model
Because I have already used the terms model, modeling and modeling language a number of times, I think it would be wise to go one step further and make clear what I mean by those terms.
Modeling is about capturing certain aspects of a more complex domain, for a certain function and an intended type of user. The modeling language provides you with the basic elements, much like the axioms in mathematics.
A model contains as few elements as possible, but no less than that. You want all important functional aspects (think of the discount calculation) to be described in one place, so that everything that depends on it depends on the same thing. And everything that is not essential must be left out of the model, because that is only noise and subject to change, for example technical details about data storage and display in the user interface: with the next generation of data storage method (in the cloud) and user interface technology (touch, voice), those details are already obsolete. They therefore do not belong to the essence.
Modeling therefore has a lot to do with separation: what are the essential elements of a domain and what are not? As stated above, it is also important to take into account the function and user(s) of a model, also described as a ‘domain’. It might be that it has intersections with another domain, but it is better not to confuse it, if possible. That reduces complexity. Formal interfaces to describe these intersections help a lot here.
An example
Take a car for example. As a driver of a car you already have a certain underlying model of a car in mind. Let’s assume a car with an automatic gearbox. With a fuel engine. I briefly describe below how such a model could be described in plain English.
1. The car has an engine. It can be turned off or on. If it is on, it will normally propel the car.
2. The engine uses fuel, so there has to be enough of it to keep on driving.
3. There is a possibility to disconnect the motor so that it can run ‘freely’. The engine then no longer influences the speed of the car.
4. The motor can run faster or slower and accelerate and decelerate. If the engine is not disconnected, the car will also accelerate or decelerate
5. There is a pedal that you can press to influence the engine speed. The deeper you press the pedal, the more powerful the engine will run, causing the car to drive faster and vice versa
6. There is a pedal that you can press to brake. The car will slow down if you press this pedal, the harder, the more it slows down.
7. There is a steering wheel that has an effect when the car is moving. if you turn to the left, the car will turn to the left and it will turn to the right if you turn to the right.
You see that such a model can already contain some features, but it is still manageable. There are, of course, a number of other issues that are important for a driver: lighting, refueling, the slope of the surface still has influence, reversing is still somewhat underexposed, and at some points it is very brief. But all in all you have the most important functions in it. As an exercise, I leave it to the reader to improve it further.
What you can also see: this model goes deeper than the ‘graphical user interface’ of the car. If you take a picture of the inside and outside of a car and show it to someone, they will not be able to reproduce the above immediately. In fact, this model applies to almost all cars, regardless of how they look exactly and where the engine, steering wheel and pedals are located. That is precisely the power of it, because every manufacturer who makes a new car that works according to this model ensures that a driver is quickly acquainted. And vice versa: as a driver who has been driving all kinds of cars for the past 40 years, you could do well with this model.
You also see that this is specifically a model for the driver of a car. A mechanic looks at the same car in a completely different way. And a car manufacturer again in a completely different way. They do have common ground, but luckily as a car driver you don’t have to know everything about the technology in the car.
Conclusion
The modeling language in this example is English. This is of course not a formal modeling language and a computer cannot do anything with this. With Alan we have made a modeling language that is as small as possible with which you can formally describe models, which can then also be executed immediately. For example a model that describes your business processes very precisely.
It is difficult to objectively determine how well we have succeeded. It is special that with just a few modellers in a few years we have already developed an MES system and an ERP system and also several complex systems for specific purposes. While the platform on which it was developed was itself constantly in development as well. And most of those systems are still in development now, without any loss of speed in them, in fact, it seems that development is going faster and faster. If you want to know more about that, please contact me.
