Mixing levels of abstraction puts a bomb at the base of your project

Over the years as an architect, I have seen different customers, and one of the most common mistakes in formulating technical specifications and customer wishes is mixing different levels of abstraction. A person comes and says:



- I need a piece of hardware that will control the drive of the doors and show the current state on a seven-segment screen, and always with an external server for remote control, so that it can communicate with this server via TCP, and take VueJS for the control panel.



It seems that it is clear what the person wants. Someone even has such TK causes enthusiasm - a person, it would seem, clearly understands what he wants. Often it even points to specific controllers / components / frameworks / protocols.



And for such an order, of course, you can make the necessary piece of iron. And it will even work if the selected components do not contradict each other. But if the calculation is not for a project, but for a product, and then it will need to be supported, then it is much more useful to spend time and carefully divide these wishes into levels, to understand why such a screen, why TCP, and where does VueJS come in. It may well turn out that these are technologies for which the customer has pleasant feelings due to the duckling syndrome. Or he just doesn't know that there are other types of screens.



In this case, we first talk about the first level: the device that controls the drive, with indication and remote control.



Then we begin to specify the requirements (but not specific technologies).

A device in an IP68 case, with a 230V power supply, controlling an 800W asynchronous drive through a frequency drive via modbus, having a clearly visible indicator, the four states of which (open / closed / in progress / breakdown) must be recognized by a person from 10 meters, with remote control, available from modern browsers over the Internet.



And only after that you can begin to select the level of implementation for the requirements. Here is such a controller, here is such an rs485 transceiver, here is such a power supply, here is such an indicator.



Separating these two levels (requirements and implementation) is easy - in most cases, you can choose different implementations for the same requirements, and this will not change the level of requirements in any way. The level of requirements may change due to the fact that the implementation is too expensive, or you do not like it visually, but it should not change due to the choice of a controller that is more convenient for the developer, otherwise you looked too deeply into the requirements or were simply too lazy to find out why it was formulated such a requirement.



Let's say a customer wants a screen with 8 cm characters. At this point, the architect or product manager should ask why exactly 8 centimeters? In most cases, it turns out that the customer has a requirement “visibility from 10 meters” inside, but he decided to simplify the task and immediately expressed a specific requirement. Or he simply cannot look abstractly, because he thinks about the project in more understandable objects: an abstract “screen visible from 10 meters” is more complicated than “a large, well, you know, such a display of segments, in a box, I’m here I'll hang it on the wall. "



But the customer, by definition, does not have the competence to develop projects, otherwise he would not have come to you. And even if he possesses these competencies, he cannot apply them in the development of this specific project, because why did he come to you then?



Decisions in projects should be made by the one who will be responsible for them. If the customer is not responsible for the timing of the development of the code for a specific screen that he has chosen, then he should not select this screen. The task of the customer is to say what requirements, in his opinion, the chosen screen model implements.



The challenge for the architectural decision maker is to select the most appropriate solution to meet these requirements. It can be an LED screen, an LCD, or just a traffic light of 4 colors, and a board with pasted inscriptions.



But the architect should not take everything that the customer says as a given: if in this way it was possible to draw up a technical specification sufficient for development, then the customer would not need intermediaries between him and the development.



The description of requirements not at the level of architecture to which they belong is a dangerous thing that is guaranteed to bury the architecture of the project, reducing it not just to a description of wishes, but to a dangerous mixture of gases that are safe alone, but ready to explode when mixed. And the system implemented according to this architecture will sooner or later explode - with current abstractions, complex modifications or falling crutches with any change in functionality.



Imagine you are building a house. The basic element of the house is brick. You cannot buy half a brick, but by buying five dump trucks of bricks, you are not buying a house. And even a hundred bricks don't turn into a wall. To build, at the lowest level, you will have to operate with exactly one brick, no more and no less.



But designing a house in bricks, and even in brick conglomerates, is a very bad idea.



First, complexity grows. Any memory and resources are finite, and it is better to spend less than more. The house, which describes the location of each brick, is too difficult to perceive, consists of too many elements. It is difficult to draw (instead of quickly drawing individual rooms, we draw each brick), drawings are difficult to read, 3D models take a long time to render, purchase lists operate with the exact number of bricks instead of tons.



Secondly, flexibility is lost: shifting one brick is already a mistake. We do not give room for maneuver at a low level of development, which forces us to do someone else's work, and receive error messages that are not critical to us. If we set the task as “to make a wall of bricks 30 centimeters thick”, then the builder has the opportunity to lay the bricks as he wants, as long as it does not violate the strength or other restrictions. If we give him an exact drawing of the location of the bricks, then at the next check, the accumulated difference in the thickness of the seam of a couple of millimeters will give us an error of half a centimeter in the location of a particular brick, which will lead to a mismatch between the wall and its TK. Sometimes this is a mistake, but in most cases, the incorrect position of one brick does not affect anything, and is dictated by the circumstances,which we could not take into account when designing: for example, incorrect dimensions of bricks from production. You can return, you can build from such, it will be easier and cheaper. Designing at the level of individual bricks robs us of this choice, forcing us to either match the ideal result or throw out all the work.



Thirdly, we cannot move to another level, start thinking about rooms, as long as we only have conglomerates of bricks infinitely flowing into each other and some kind of spaces between them. Bricks are more important for us than the space between them, it is just the absence of bricks, and not a place for life. It seems that the house is being built for the sake of the rooms, but every desire to change the wall in the room is so difficult, leads to so many operations on moving bricks and building a new order of masonry that we almost stop doing this: it is easier to agree with an uncomfortable wall than to constantly move bricks there -here on the plan.



Fourth, the idea of ​​replacing the base element is unbearable. Everything is built on bricks, you count the distances in bricks, you count the cost in bricks, you count the weight in bricks, you count the thermal conductivity of the wall in bricks. This is convenient, since it does not create unnecessary units of measurement, unnecessary abstractions. Thermal conductivity in bricks is easily translated into distance, and cost is easily derived from distance.



But it's impossible to tackle a house made of other materials: you have to stop focusing on bricks, and this destroys the whole picture of the world. Although, with the correct separation of the abstraction layers, you will perfectly design rooms in meters, calculating the cost in rubles, the load on the piles in tons, calculate the thermal conductivity in W / (m K), and only at the last design level you decide what to take - bricks , aerated concrete or concrete panels. And if the customer doesn't like the solution, change it without touching the rest of the project.



Working on architecture is about walking through levels of abstraction. The vision of these levels is an essential property for a good architect.