Humanitarian shift in the training of 1C architects

What is the mission of a 1C architect? By and large, it’s about setting the right direction for the developers’ efforts. A 1C architect must have the ability to look into the future. Clearly imagine the fate and life path of the product being created. What might users want from it? What will those who will refine and develop the product have to face? The 1C architect must make sure that both the first and second are as comfortable as possible with the future product. Quite a difficult engineering problem. Each time it has to be solved anew. What challenges have emerged in this area recently? And where is the place for humanitarian abilities? Let's talk about it below


The situation is changing rapidly. You could say, right before our eyes. Until relatively recently, one of the main concerns of a 1C architect was concern for system performance. Now, if your customer belongs to the category of small or medium, then you still need to try to design something that will frankly slow down on the 1C: Enterprise platform.

It would seem that the 1C architect should make sure that the future system contains all the reports that users need. And since it is impossible to foresee everything in advance, it is necessary to design the system in such a way that adding any conceivable and inconceivable report would be done, as they say, with “little loss.”

But here large language models (LLM GPTs), colloquially referred to as artificial intelligence, appear on the scene. And it turns out that now you can design the future accounting system almost any way you want. Well, you will have some tables with data. The user will come and say what he needs in human language. You will take this question from the user, attach a table structure to it and give it to a large language model. At the end you will receive a completed request. All that remains is to execute it and visualize the result. There will be tables with data like this or that, it doesn’t matter to a large language model up to a certain limit. Do what you like! Artificial intelligence will figure it out.

At this point, some hastened to declare that soon specialists will not be needed. But no. This is not the end of the story for 1C architects, but rather the beginning.

Let's look at this with one specific example. In typical 1C configurations there is such a wonderful table that displays sales data. In UT, CA and ERP, this is an accumulation register called Revenue and Cost of Sales. The good thing about the table is that it contains all the necessary information about sales: product, quantity, amount, buyer, date of sale, cost, manager. Combined with a large language model, this gives us the ability to answer virtually any user's sales question. All conceivable and inconceivable reports, all this Business Intelligence could be obtained easily and simply, if not for one “but”.

It's about the names. The register itself is not called very simply and understandably. But there's more to come. The product in the register is called… Analytics of Nomenclature Accounting. Buyer, Accounting Analytics for Partners. Large language models, of course, can do a lot. They easily “swallow” spelling errors, missing letters, etc. But they can’t chew “this” anymore. Of all that I mentioned above, only the “manager” is called a “manager” in human terms.

In another standard configuration, UNF, the same register already has a normal name, “Sales”. The buyer there is called the “Counterparty”. Well, wherever it goes. For the product, the word “Nomenclature”, beloved by standard developers, is used. And this is no longer acceptable. The manager is questionable. Here he is called “Responsible”. Maybe for a large language model this won’t be a problem, or maybe it will be. And the word “Responsible” will confuse her. Yes, and in all standard ones, the date of the transaction in the register is called “Period”. Which can also be a source of problems.

I think you already understand where I'm going with this conversation. In the very near future, if not already now, a 1C architect will need such a purely humanitarian skill as command of natural language. Everything should be called simple and clear. This, by the way, is not such an easy task. And for some, even unattainable. The ability to express oneself simply and intelligibly is not given to everyone. And, at the same time, certain efforts are required in order to develop it. This topic becomes even more interesting when you consider that “simple and understandable” should not only be understood by humans, but also by large language models. Thus, the need emerges to develop a rather specific skill at the intersection of the humanities and engineering. In addition to language proficiency, you will need knowledge of which language constructs work for large language models and which are best avoided.

In conclusion, I would like to invite you to a free webinar of the course Architect 1C about business process modeling notations. Registration is available via this link.