Nowadays, constantly improving business processes is essential to a company's success. To stay competitive, companies must keep up with rapidly changing markets, technologies, and trends, which is hardly possible without changing and modifying companies' operations. Naturally, such changes impact corporate software that supports these processes.
Changes in legislation and regulatory requirements are other factors causing modifications to corporate systems. For example, a new procedure to pay taxes or social security charges.
Thus under the impact of an increasing number of business tasks, growing markets, and new regulations by state authorities, the development of an advanced large-scale corporate system turns into a never-ending process. The system requires constant updates and improvements to enable smooth operation and further development of a company. For this reason, it is critically important that a business automation strategy allows seamless changes when necessary.
Let us consider the challenges developers face when they handle changes to a system in use, discuss ways to minimize these challenges and cut the financial costs associated with the changes.
What Kinds of Issues to Expect When Changing Business Applications On-Site?
An initiative to modify a corporate system might come either from a vendor or a customer. As vendor releases are intended for all customers, there is a good chance that such an update fails to take into account the specific needs of a particular company. To customize the system so it meets the needs of a specific company, it might be necessary to modify the business logic within the respective software product. To do this, we either need to be able to access the source code or acquire tools allowing customization and adaptation of a proprietary code.
On the one hand, open source code applications give much flexibility in modifying code compared to closed source software. On the other hand, installing an update on an open source code product previously customized for a specific customer is a challenging task and, in some cases, may result in errors or faulty operation of a respective product.
Since such systems get modified both by customers (to comply with corporate business processes) and vendors (to add new functions, fix bugs, and ensure compliance with the current legislation), installing an update is a process of merging the source code of the updated application with the previous version modified on the customer side. The challenge here is to acquire the new functionality included with the vendor's update and still retain customizations added to earlier versions.
This situation is well known to everyone who was in a developer team and had to merge own source code with modifications introduced by other team members. Even in a single unit where members follow the same coding rules and principles, merging source codes can be difficult. And with business applications, it gets even more complicated because developers on the customer side rarely can reach vendors (and vice versa) to get advice regarding the code.
Also, if we are talking about massive customization on the customer side, a vendor might decide to end the support of the customer product.
All of the above describes one of the most complicated tasks within the life-cycle of an opensource code business system The market success of a product largely depends on how efficiently the software vendor manages this task.
The Strategy for Customizing Applications in the 1C:Enterprise Ecosystem
The architecture designed by the 1C Company makes it possible to easily customize business logic in final products.
To create applications, we use the 1C:Enterprise platform, which is both a development and runtime environment. An application, also called a configuration, comprises the source code and metadata. Metadata makes up the structure of the 1C:Enterprise database. That same structure that describes application components, including catalogs, documents, registers, and others. All 1C applications built on the 1C:Enterprise platform come with open source code. It means that developers, using the platform's Designer mode, can view and modify both metadata and the application source code.
Such an approach yields a vital advantage. Practically every person who has a computer with the 1C:Enterprise platform installed can enjoy a complete set of tools for developing and managing 1C:Enterprise applications. It allows customers not only to fine-tune products they use but modify and customize them as necessary.
To make the support of customized applications more efficient, the platform offers a built-in support mechanism that allows vendors to specify application components (like catalogs, documents, and others) that customers can and cannot change. The reason for it is that modification of some components can crush the system or make centralized support impossible.
At the same time, customers can use this mechanism to define how their customized applications should be supported. For example, they might want to give up the vendor's support for a specific component in case they do not need it and wish to further support and improve it themselves. Moreover, it is possible to prohibit a vendor from modifying a specific component in the customized configuration and thus prevent accidental disruption in the operation of the component.
In an ideal world, it is good to have customer customizations outside vendors' standard configurations, so customized parts come into operation only when a specific piece of code is required. In this case, installing vendor updates becomes an automatic process requiring no human assistance. To make the above possible, the 1C Company has developed two approaches that cover a significant portion of customization scenarios.
Approach #1 is using external data processors and external reports. These mechanisms allow adding extra functionality on top of existing applications without modifying the configuration source code. In fact, these are scripts fitted with a graphical interface. These scripts are designed to run within a specific application.
The second approach is using extensions. The strategy with extensions assumes that customers do not have to change standard configurations. Developers make all customization in a so-called extension that, in its essence, is also a configuration separate from the vendor configuration. In such a case, a business application (final configuration) combines the vendor's standard configuration and the customer's extension. When running such a business application, the platform automatically combines the standard configuration with the customer extension.
At that, it is possible to update vendor configuration automatically, as the support mechanism treats it as the original non-modified one. With the final configuration running, the platform attaches the components contained in the extension, thus retaining all customized functionality the customer expects. This way, even with significant modifications introduced on the customer side, standard configurations still retain the original vendor support.
Extensions have become particularly popular with products offered as a service where the data separation mechanism is used. Thus, if a customer needs additional reports while others wish to keep the standard configuration, it is only required to develop a small extension to address particular customer needs and attach it to the standard configuration. It is worth mentioning that existing data separation rules apply to any extension (though you can make an extension available to all users if needed), and other customers will not even know that someone is using one.
Such an approach to the architecture has made the 1C:Enterprise platform extremely popular as it ensures high flexibility of the platform-based products and their cost efficiency throughout the whole life cycle.
Got interested in developing flexible, future-proof business applications? Start free with 1C:Enterprise!
