1C:Enterprise for In-House Software Development. Strengths and Weaknesses of the platform

The 1C Company, a Russian leading software vendor, introduces its 1C:Enterprise business-application development platform to the international market. The platform has existed for a long time. It’s very popular in the former USSR countries and has a large developer community. In the same time it isn’t widely known in the global market, while the company has representative offices in Europe, North America, and Asia. This platform is definitely worth paying attention to. However, as is often the case with recently launched products, you usually see advertising materials that are promoted to top positions by marketers, search optimizers, etc. This makes it somewhat difficult to find objective information. Additionally, in the Russian segment of the Internet, you can also come across haters, who often didn’t even read the documentation. Like any long-term solution, 1C platform has strengths and weaknesses. I believe it makes sense to make an unbiased and balanced review of the 1C platform. About what it can do, what it can’t, what it should do, but shouldn’t, and, for last, what it does with a bang while your %technology_name% developers would need years and a significant budget to do the same.

Consequently, you, as a manager or architect, will be able to get a clear understanding of what tasks 1C will be beneficial for and in which case it should be exorcised. As a non-1C developer, you can see what is there in 1C that all the fuss is about. And as a 1C developer, you can compare your system with other language ecosystems and understand where you are on the software development axis.

This article will be dropping some fat, smelly questions at 1C, critics of 1C, Java, .NET, and just generally… The fan is on, you’re welcome!

A few words about myself

I have been familiar with the subject matter since about 2004. I’m probably programming since I was 6, from the very moment I got a book about how a computer works. At that time, I didn’t have a real computer, but there was an image of it on the book spread, and I conscientiously pressed the paper buttons to enter the commands spied on from one of the heroes, the cat programmer.

Next was ZX Spectrum and BASIC at school, C++ and assembly languages in the University, then 1C, and then there were so many things that I’m too lazy to recall. For the past 15 years, I have mainly been engaged in the 1C platform, and it was not only in terms of coding but rather 1C in general. It was also about setting goals, administration, and Dev/Ops. For the last five years I have been engaged in socially useful activities, including building up development and automation tools for other 1C developers as well as writing articles and books.

Decide on the Subject of Discussion

To begin with, let’s decide what we’ll discuss here. The term “1C” can mean a software manufacturer, 1C:Enterprise Framework/Platform, and specific applications developed using this framework. In this case, “1C” characters will be used exclusively to denote the current (eighth) version of 1C:Enterprise development framework. We won’t talk much about the software vendor and its policy (but have to say something about it). We won’t discuss specific business applications based on 1C:Enterprise. Let’s separate technology from the applications, (a.k.a. Configurations).

1C:Enterprise High-level Architecture

I have a good reason to use the word “framework” because that’s what the 1C platform is, at least from the developer’s perspective. So, you’d better treat it like a framework with its own programming language. Consider it as Spring or ASP.NET executed over a certain runtime (i.e., JVM or CLR, respectively). It so happened that in the conventional (“non-1C”) programming world , platforms are naturally separated into frameworks, virtual machines, and specific applications due to the fact that these components are usually developed by different software manufacturers. In the 1C world, they don’t separate a development framework from a runtime. Moreover, specific applications written in the framework are basically also developed by the 1C company. Consequently, some confusion arises. So, in this article, we need to consider 1C from different perspectives and classify it using several directions. And we’ll be shoveling and examining these directions thoroughly, their peculiarities, as well as the benefits and drawbacks of existing solutions.

1C from Various Perspectives

1C for Customers

A customer buys an automation system that can quickly solve their business problems. No matter whether it’s a small stall or a large holding company. Despite apparent differences in the needs of these businesses, both are supported by a single code base of the platform. For a customer, 1C is a fast time-to-market solution. On average, the time-to-market with 1C will be shorter than it would be with Java, C#, or JS, if it makes sense to average at all. Clearly it’s better to use React for a landing page, but a Warehouse Management System project will be launched faster on 1C.

1C as a Tool

Each technological solution has its applicability limits. 1C internal language isn’t a general-purpose language. It doesn’t live separately from its framework. It makes sense to use 1C if you need:

• Server application
• Application for finance, inventory, personnel, customers, accounting systems, etc.
• Application with out-of-the-box UI, ORM, reporting, XML/JSON/COM/PDF/your data-transfer format
• Application that supports background workers and tasks
• Application with a role-based security
• Application with scriptable business logic
• Application with a quick prototyping tool and fast time-to-market

You shouldn’t use 1C if you require:

• GPU calculations
• Computer graphics
• Scientific and engineering calculations
• CAD system
• Signal processing (sound, video)
• High workload of HTTP requests with hundreds of thousands of RPSs

1C as a Manufacturer

It’s worth understanding what the business of 1C as a software manufacturer is about. 1C sells solutions that answer business problems through automation. Whether it’s a big or small business, 1C has a solution for the challenges that arise. In this scenario, business applications are the key, particularly for accounting, payroll, etc. To build these applications, 1С company uses its own business-application development platform. It’s tailored for the common tasks of these business applications:

• Accounting for finance, goods, and money in general
• Easy customization of business logic
• Wide-ranging opportunities for integration into heterogeneous IT landscapes

As a manufacturer, 1C believes its strategy is a win-win for partners and customers. You may feel compelled to argue the point, but that’s how the company promotes itself: 1C provides out-of-the-box solutions that solve business problems. They can be quickly customized by partners and built into any IT environment.

All claims or desires regarding 1C as a framework must be considered from this perspective. “We want OOP in 1C,” developers say. In return, the 1C company asks, “How much will it cost for us to add OOP support to the platform? Will it help us increase box sales?”

Here is how it looks like from the selling of business solutions perspective:

— “Hey business, do you want to have OOP in your 1C?”

— “Will it help me solve my problems?”

— “Who knows…”

— “Then, no, I don’t.”

Such an approach may be good or bad, depending on one’s point of view, but it’s just that. If you say there is no X feature in 1C, you need to understand that it isn’t there for good reason, meaning the choice between implementation cost and profit.

Technological Classification

The 1C platform makes use of the traditional three-tier architecture, at the center of which is an application server (or an inexpensive emulation for small businesses). Either MS SQL or Postgres is used as a database management system (DBMS). Oracle and IBM DB2 are also supported, but such usage is relatively rare because those database management systems are less prevalent in the mass market.

The frontend is either a web client or a thin client installed on the user’s machine. The key feature is that programmers don’t code two different versions of GUI. They write one application, in one language, and you can make it available in a browser if you’d like. Hey, who was dreaming about true full-stack and a single language for the frontend and backend, node.js, aren’t they?? They hadn’t managed to do it completely. A true full-stack exists, but you’ll have to write in 1C. Fate is ironic, isn’t it?

For example, their 1C:Fresh SaaS solution works in a browser and written completely in 1C language. You can simply rent a small database and keep a record of kebab sales there. You can work in a browser without having to install or configure anything.

Additionally, there’s a legacy client, which is called a “regular application” in 1C. The legacy is a legacy, welcome to the world of applications of 2002, but here we’re talking about the current state of the ecosystem.

1C backend supports clustering and scales by adding new machines to the cluster. There’s been a lot of lances broken over it, and we’ll talk about this in a separate section of the article, later. In short, this isn’t quite the same as adding a couple of the same instances behind HAProxy.

The application development framework uses its own programming language, which is akin to a slightly upgraded VB6 with the more common comment character “//,” the index operator enclosed in brackets and a semicolon at the end of each operation.

It’s the programming language, which is the main reason for hate towards 1C as a platform. Frankly, it isn’t without reason. The language was designed to be as simple as possible and to fulfill the mantra “DEVELOPERS, DEVELOPERS” at least in CIS countries. In my opinion, the commercial background of such a decision is clearly visible — if more developers are involved, the market share will be greater. According to various estimates, this has been true for 45% to 95%.

Well, let’s start with the language.

1C Programming Language

1С programming language is the strong and weak side of the system simultaneously. It is easy to learn, readable. On the other hand, it hasn’t been updated since the release of version 8 in 2002, so it’s outdated. Someone will say, “the main flaw is that there’s no OOP,” but that would be wrong. First, not only the head of 1C dislikes OOP, but also Torvalds does too. Second, OOP is still there.

From the developer’s viewpoint, they have a framework with the base classes mapped to the database. The developer can take the base Catalog superclass and inherit the Customers class from it. They can add new class fields to it, for example, TIN and Address as well as override methods of the base class, e.g., OnWrite.

The framework is designed in such a way that deeper inheritance is rarely needed, so, in my opinion, the OOP limitation makes sense. 1C focuses on Domain Driven Design approach to software development and makes you think, first of all, about the domain of the solution being developed, and this is good. There is neither temptation nor need to write 10 different DTOs and ViewModels just to show some domain data somewhere. A 1C developer always operates with a single entity, doing so without cluttering the perceptual context with dozens of classes, all with similar names, that represent the same entity but from a different angle. For example, any .NET application will necessarily contain a bunch of ViewModels and DTOs for serialization in JSON and data transfer from the client to the server. Approximately 10% to 15% of your application code will be written just to move data from one class to another. This can be done manually or with a tricky-hacky solutions like AutoMapper. Anyway this code needs to be written, so you’ll need to pay programmers to create and maintain that code.

It turns out that the 1C language is difficult to improve without complicating it at the mainstream language level and losing the advantage of simplicity. In fact, the vendor fulfills its primary objective — to provide a standard solution that can be customized with the proper level of quality by any student you meet If you’re a stall operator, you can use a student. If you have a factory, you borrow a guru from an implementing partner. From the architecture point of view, the framework should solve the problems for both of them, i.e., the code of standard applications (which we sold to the business with the promise of customization) should be understandable to the student, while the guru will understand anything you want.

Here are some things that, in my opinion, are severely lacking in the language. They force me to write more code than I would want or otherwise need to, thus forming a waste of the consumer’s time:

• Typing at the level of, for example, TypeScript (which, of course, gives you enhanced tools for code analysis in the IDE, a refactoring option, and fewer annoying bugs).
• Functions as first class citizens: It’s a slightly more complicated concept, but it makes it possible to significantly reduce the number of boilerplates from the standard codes. IMHO, it would even make the code easier to understand by the student due to the reduction in its volume.
• Literals of universal collections and initializers: Again, it reduces the volume of code to be written and/or viewed. For corporate software, filling out collections takes up more than 90% of the programming time. Collection literals could significantly enhance the concision of code.
• Finally blocks. I know you can get along without it, but I like to use them because they’re convenient. Finally blocks reduce the volume of code and make it more readable.
• Own data types (without OOP), something like the Type in VB6: This saves you from having to provide documentation comments for the data structures being created and magic methods that build these structures. What we get is less code, autocomplete suggestions after the dot, a faster resolution to the problem, fewer errors due to typos, and fewer missing structure properties. For now, the Standard Subsystem Library development team is responsible for typing custom structures, and, to their credit, they carefully write comments on the expected properties of the passed parameter structures.

I’ve mentioned just the most pressing issues, though. The list can be much longer, but you should remember that this isn’t a general-purpose language. There’s no need for multi-threading, lambda functions, access to the GPU, and fast floating-point calculations. This is a business logic scripting language.

A programmer who has already worked a lot with this language and has looked into JS or C# is getting bored with this language. It’s a fact. Language needs to evolve. However, the vendor has the cost of implementation of these features to be weighed against increased revenue after their implementation. I have no idea about what is outweighed in the eyes of the company.

Development Environment

The development environment isn’t exactly smooth. In fact, there are two environments. The first is the built-in Designer, and the second is the Eclipse-based environment, Enterprise Development Tools (EDT).

The Designer provides the base for a wide range of development tasks. It supports all of the features and is the main development environment for 1C. However, it hasn’t evolved. It would be helpful to open the internal API, but that hasn’t happened. The practice has shown that the community will code features in the IDE on its own as long as the vendor doesn’t interfere. Nevertheless, we have what we have. The Designer was a great solution in 2004–05. It was very similar to Visual Studio of that period. It was somewhat cooler, but it hasn’t progressed and in some cases behaves not so friendly.

As an alternative, there’s the Eclipse-based IDE written from scratch. As in any other software project, it processes source codes in the form of text files and stores them in GIT. It supports pull requests, branches, advanced error analysis, and a much smarter hint system. I won’t write about the cons of EDT because today’s cons can easily become a fixed feature tomorrow. Such a description will quickly become irrelevant. EDT is actively expanding its pool of features, offering an up-to-date user experience for the developer, linter, in-depth code analysis, etc.

If you look at the situation from the 1C perspective, you get something like this: the new IDE release doesn’t increase the boxes sales but can reduce the DEVELOPERS outflow. It’s difficult to say what awaits the ecosystem in terms of developer comfort, but Microsoft already missed the opportunity with mobile developers because its services were offered too late in the game.

Development Management

The situation with development management is much better than with code writing, particularly in recent years when community efforts exposed the problems with administration automation, and some prototypes were launched, offering to throw the old 1C’s proprietary code storage away and instead use Git, quick blame, code-review, static analysis, auto-deployment, etc. Many features have been added to the platform for a higher level of automation in development tasks. However, all these features were added solely and exclusively for the development of 1C company’s own large products, when it became apparent that it was no longer possible to move forward without automation. There were auto-merges, three-way comparisons with KDiff, etc. On Github, the GitConverter was launched, which, it must be said, was ideologically ripped off from the gitsync project but was then adapted for the processes of the vendor company. Thanks to the stubbornness of open-source geeks, development automation in the 1C world has moved forward. IMHO, opening the Designer API would allow the community to create a library of plug-ins for the IDE, but such an API exists only for the new development environment (EDT).

Today, the storage of 1C sources in Git with commits bound to tasks in Jira, a review in Crucible, deploy with a button via Jenkins, Allure reports for code testing in 1C, and even SonarQube static analysis are no longer news. In fact, they’ve become commonplace in companies with many 1C developments.

Administration

I have a lot to say about the administrative aspect. It is, of course, a server (1C server cluster). It is a wonderful thing, but because it is an entirely black box, which is sufficiently documented in great detail but in a specific way, it’s only a real “expert in technological issues” who can cope with the launching of continuous operation in high-load mode on several servers. It should be mentioned that, in principle, administering the 1C server is basically the same as with any other server. This is a multithreaded network application that consumes memory, processor, and disc resources. It provides ample opportunities for telemetry collection and diagnostics.

The problem is that the vendor doesn’t offer anything special in terms of out-of-the-box solutions for such a diagnosis. Yes, the vendor offers a tool kit for the corporate sector, it’s even not bad, but not everyone has it because of its price. The community has a number of developments for connecting Grafana, Zabbix, ELK, and other standard admin tools, but there’s no single solution that will suit most people. The task is waiting for its hero. If yours is a business that plans to deploy its solution on a 1C cluster, you’ll need an expert. Whether internal or external, that expertise will be essential. Usually, there’s a separate role with competencies in server operation. Not every 1C developer should have them, so you just need to understand that such a role is required. Consider SAP as an example. An SAP programmer probably wouldn’t bother to leave the chair if he or she were asked to configure something on the application server. Such a programmer might not know how to do it, but there’s little shame in that because the SAP methodology, for example, has a separate employee role for that task. For some reason, in 1C it’s commonly assumed that all these competencies should be combined in one employee for the same salary. That’s delusional.

1C Server Cons

It has exactly one minus: sophistication. To understand the reasons for a strange behavior of the server or overclock it for the increased load, you need to have certain competencies and pass a rather tricky exam, although it seems that I repeat myself… 1C server contains quite a few components, and in order to distribute all services correctly across different cluster machines, configure interaction properly, configure collection of metrics, logs, and analytics, you need to dive very deep into the documentation and know how it all works. In most cases, admins install the 1C cluster simply by clicking “Next,” “Next” in quick succession. They don’t go beyond the initial installation instructions. As soon as the system requires scaling (the business gains traction, the number of users, transactions increases), negligence on the part of the admin will immediately be apparent. Yes, the vendor offers additional corporate support, but for large deployments only, so it’s better to have a person on hand who can open the hood and understand what is under it. So, 1C performance experts are rare stuff, which means they’re costly. It’s also worth saying that if your system isn’t highly loaded and your transaction flow isn’t very significant, such difficulties will probably not affect you. For advice on the customization, you could, for example, visit a manufacturer forum, chat with developers and solve simple administrative issues.

The 1C server, however, is the same as any other application and is administered in almost the same way by reading documentation and using a bit of magic.

Docker

The usefulness of a containerized 1C server in the production environment has yet to be proved. The server can’t be clustered simply by adding nodes behind the balancer, which negates the benefits of containerization of the production environment, and the best practice for the successful operation of containers in high-load mode hasn’t been developed yet. Therefore developers use 1C with Docker only to get their test environments up and running. It’s exceptionally useful for this purpose because it lets you play with cutting-edge technology and take a break from the gloom of the Designer.

Commercial Component

From the investment point of view, 1C lets you kick-start business ideas by using wide capabilities of applied classes. A boxed version of 1C gives a very decent reporting functionality, integration with anything, a web client, mobile client, mobile application, support for various DBMSs, including free ones, cross-platform as a server, and installable frontends. Yes, the application UI will be yellow. Sometimes — but not always — that’s a con instead of a pro.

Choosing 1C, your business receives a set of software solutions that allow you to build a wide range of applications as well as a framework with a low entry threshold that makes it easy to learn.

For example, the novice developer needs about an hour to send a bill in PDF format to your client. With .NET you can do the same thing by purchasing a proprietary library or having a brainy developer spend a couple of marathon days, even weeks, on coding. Sometimes, you can do both at once. Yes, it’s only about creating a PDF. We didn’t say where this bill came from at all. The web frontend developer should make up the form an operator will type the data to, the backend developer has to create DTO models for passing JSON, models for storing into the database, the structure of the database itself, migration to it, a graphical layout for this bill, and only then is the PDF generated. At 1C, the complete task is done in exactly an hour.

A complete accounting system for a little stall with one buy/sell business process will be ready in just three hours. It will contain sales reports, accounting for goods at the stated purchase and selling prices itemized by warehouse, access control, web client, and mobile application. Well, as for the mobile application, I’ve exaggerated somewhat. With the mobile app, it would take six hours instead of three.

Consider the .NET developer. How long does this task take from the installation of Visual Studio on a clean computer to the demonstration of results for a customer? How much does the development cost? That’s it.

Pros of 1C as a Platform

The power of 1C isn’t in something special that is the best in the world. Instead, you can find a more interesting analogues for each individual subsystem in the global software. However, adding up all the factors, I can’t find a platform similar to 1C. This is where its commercial success lies. The pros of the platform are scattered in various places and aspects, but they’re easiest to discern when you see how it’s done on other platforms. Basically, it’s not even features but instead freedom from features in favor of one particular paradigm. Here are some examples:

1. Unicode: What in hell could be easier? You shouldn’t use single-byte ASCII encoding in 2020 (except for integration with a backward legacy). For anything. However, no. There’s always someone who uses single-byte varchar in some table, and the application has problems with encoding. In 2015, GitLab dispensed with LDAP authorization due to incorrect encoding. Moreover, JetBrains IDE still doesn’t work with some Cyrillic file names. In 1C, the application code is isolated from the database layer at a high-quality level. You can’t specify types of table columns or detailed indices structure at a low level there, so it’s impossible for incompetent juniors to introduce bugs at the DB level. Yes, there are other possibilities for incompetent juniors to create bugs there, but the variety of problems is much smaller. You’ll tell me now that your application is designed correctly, and the database access layer is isolated properly. Look at your corporate in-house Java application again. Do it intently and honestly. Are you unashamed? Well, then I’m happy for you.
2. Document/catalog numbering: In 1C, it’s definitely not the best or the most flexible. However, the versions used in banking software and in-house accounting systems are horrific. You can stuff identity into the table (and then ask, “Oh, why do we have security holes!?”) or instead create a generator that works with locking at the DBMS level (and will become a bottleneck). In fact, it’s pretty difficult to accomplish the task. It should be a through-entity enumerator with a unique breakdown for a certain set of keys and prefixing that will let you avoid locking a database during parallel data entry.
3. Record IDs in the DB: 1C made a discretionary decision to make all link identifiers absolutely synthetic, and that’s it. And there are no problems with distributed databases and data exchanges. Developers of other systems stubbornly stuff in something like identity (because it’s shorter!), take them into the GUI, and use it until they need to create several related instances (and here they come across a revelation). Don’t you have something like that? Fair?
4. Grids/Lists: In 1C, there are quite successful tools for scrolling through (large) lists and navigating through them. Let me make a reservation. It’s true if you use the tool properly! Generally, the topic is pretty unpleasant. There’s no ideal solution to this problem. It can be simple and intuitive (but with the risk of huge recordsets on the client-side) or can have a relatively poor implementation. Those who do paging often do it wrongly. Those who make a true scrollbar, crash a database, channel, and client.
5. Managed forms: There’s no doubt about it. In the web client, the interface doesn’t work perfectly. Nevertheless, it works. For many other accounting and banking systems, creating a remote workplace is an enterprise-level project. Disclaimer: Fortunately, it won’t affect those who initially used the web applications.
6. Mobile app: Recently, it became possible to write mobile applications within the same ecosystem, but here it’s a bit more complicated than with the web client. Device specifications (such as screen resolution and phone sensors) force you to write code specifically for them, but you don’t need to hire a separate team of mobile developers. If you need an application for the internal needs of the company (when a mobile solution for a corporate problem is more important than the vendor’s yellow UI design), just use the same platform out of the box.
7. Reporting: I don’t mean by this word a BI system with big data and a lag on an ETL process. I refer to the operational staff reports allowing you to assess the accounting status here and now — balances, mutual settlements, re-sorting, etc. With 1C you receive the reporting system out of the box with flexible configuration for groupings, filters, and visualization on the user side. Yes, there are cooler analogues on the market, however, not within an all-in-one solution and for a price that is sometimes higher than for the all-in-one solution. And more often it’s the other way around: you receive only reporting, which is more expensive than the entire platform but poorer in quality.
8. Printed forms: Just try to create a .NET solution for sending PDFs with salary sheets to employees via e-mail. And now solve the task of printing consignment notes. What about saving its copies in the PDF and XLSX? For 1C programmer, an output of any layout to PDFs is yet +1 code line. It means +40 seconds of work time instead of days or weeks when using other languages. Layouts of printed forms in 1C are incredibly easy to develop and powerful enough to compete with paid counterparts. Indeed, there aren’t so many interactive features in 1C spreadsheets, and you can’t use OpenGL to generate a three-dimensional diagram with a scaling feature, for example. But would you really need to do that?

The above are just a few examples when limiting functionality or implementing a solution with tradeoffs turns into an important architectural advantage in the future. Even if it is a tradeoff or isn’t the most effective option, it already exists out of the box and is taken as a given. Its standalone implementation will either be impossible (because such decisions need to be made at the start of the project, and there were more important things, and in general, we have no architect) or can be implemented in several expensive iterations. In each of the above points (in this partial list of architectural solutions), you can foul up and embed restrictions that will keep you from scaling. In any case, you, as a businessman, need to ensure that your programmers creating a system from scratch have competencies and can develop the system’s subtle details without mishaps.

1C, like any sophisticated system, also has solutions that block you from scaling in one aspect or another. However, I repeat: Considering all of the factors along with the cost of ownership and the number of problems already solved in advance, I don’t see a worthy competitor in the market. For the same price, you get a financial application framework, a cluster-balanced server with a desktop UI and a web-client, a mobile application, reporting, integration, and a lot more. In the Java world, you hire a frontend team, backend team, debug low-level problems with the in-house server code and pay separately for two mobile applications for two distinct versions of mobile OS.

I’m not saying that 1C will fit every case, but what else is needed for an internal corporate application that doesn’t require you to brand UI?

A Rotten Apple

It might seem that 1C will save the world and that all other ways of writing corporate systems are wrong. It isn’t quite so. As a businessman, along with quick time-to-market, you must consider the following disadvantages if you choose 1C:

• Server reliability: You need high-class specialists who are able to ensure continuous operation of the system. I don’t know about a ready-to-use training program for such specialists provided by the vendor. There are courses to prepare for the “Expert” exam, but I don’t think that will be enough.
• Support: See the previous item. To obtain a vendor’s support, you need to pay for it. For some reason, however, that isn’t customary for 1C users. With SAP, the purchase of the support is almost mandatory, and everyone seems comfortable with that. Without corporate support or an in-house expert, you might find yourself left alone face to face with 1C glitches.
• Nonetheless, in 1C you can’t do everything. This is a tool, and, like any other tool, it has limited applicability. In a landscape with 1C, it’s desirable to have a non-1C system architect.
• Good 1C experts aren’t cheaper than good programmers in other languages. Although bad programmers are expensive to hire regardless of the language in which they write.

Time to Come Clear

• 1C is a framework for rapid application development (RAD) for business, having been tailored for that purpose.
• This is a three-tiered system with the support of the main DBMSs, client UIs, quite good ORM, and reporting.
• It provides ample opportunities for integration with systems that can do what 1C does not. If you want machine learning, take Python and merge the result with 1C via HTTP or RabbitMQ.
• No need to eager to do everything on 1C. You need to understand its pros and use them for your purposes.
• Developers who like to dig into technological framework gadgets and recreate their systems every n years to suit a new engine will be bored with 1C. Everything is very conventional there.
• The developers are bored because the vendor has very little concern about them: boring language, conventional IDE. They beg for upgrading and streamlining.
• On the other hand, developers who can’t entertain themselves through applying and studding other technology they like are bad developers. They will whine and moan after migrating to any other ecosystem as well.
• Employers that don’t let their 1C experts create something using %trendy_technology_name% aren’t deserving of such talent. They will lose the talents of inquisitive employees, and in their place will be monkey coders who, having agreed with everything, will drag corporate software into the swamp. You still have to rewrite it, so maybe it would be better to invest a bit earlier in the entertainment for the developers?
• 1C is a commercial company and implements features solely on the basis of its own interests and expediency. It can’t be blamed for this, a business must think about profit, that’s the way.
• All-rounder’s approach will go into oblivion. Modern applications are too oversized to know everything about them in terms of both code and business use. 1C server is also becoming more complicated. So, it won’t be possible to retain all types of expertise in one employee. This should entail the demand for experts, and therefore the attractiveness of the 1C expertise and an increase in their salaries. If earlier Three-in-One John worked for one salary, now you need to hire two Johns and competition between Johns can spur the general growth of their level.

Summary

1C:Enterprise is a very worthy product. In its price range, I don’t know any analogues. Please let me know about them in comments, if any. However, the developer outflow from the ecosystem is becoming more noticeable, and this is a “brain drain,” anyway. The industry is eager for the upgrade.

If you’re a developer, don’t dig in 1C and don’t think that in other languages everything is magic. Maybe, only if you’re just a junior. As soon as you need to solve something bigger, you’ll need more time to look for out-of-the-box solutions, and you should finish it more intensively. By the level of quality of the bricks from which you can build a solution, 1C is very, very good.

And yet, if you came to hire a former 1C developer, then he or she can be safely appointed to the lead analyst position. They have perfectly developed decomposition skills and understanding of the task and subject meter. I am sure that this is precisely due to the forced use of DDD during development for 1C. A person is trained to, first of all, think about the meaning of the task, about the connections between objects of the subject matter, while having a technical background on integration technologies and data exchange formats.

Be aware that there is no ideal framework and take care of yourself.

All the best!