How to keep up with ever-changing demands for a business automation system and still maintain its cost-effectiveness
Companies try to keep up with highly dynamic markets, technologies, and trends by frequently changing their business processes. The evolving nature of business management makes changing the requirements for a business automation system unavoidable.
Another thing forcing a company to modify its software is regulation. Changes in federal policies such as how taxes are paid, or insurance premiums are deducted, must be reflected in the corporate system.
Because of changes to both an organization’s management processes and regulations, a large, complex system can never be completely perfected. The software will need to be periodically adjusted, and that can happen so often that the costs incurred to make the adjustments can minimize the cost-effectiveness of automation.
Let’s take a look at the challenges developers face when supporting changes to a system in use, and how to minimize these challenges, and the financial costs that come with them.
What kinds of problems arise from “on site” changes to a business application?
If you need to change a system’s business logic, either the application’s source code must be obtained, or techniques must be utilized for changing and adapting closed-source applications. Providing an application with source code access offers much greater flexibility when trying to change it “on site” than software that does not grant source code access to the client (this is not open source in its usual meaning, but providing access to the source code of the application, including for a fee).
However, for systems provided with source code access, installing vendor updates where the business logic has been changed “on site” based on the client’s needs is often no trivial task and can be fraught with bugs.
Since the system will be changed by both the company’s IT personnel, by adapting the solution for the enterprise’s business processes, and the solution provider, by adding new functions, fixing bugs, and supporting regulation changes, the process for installing updates consists of merging the source codes of the latest application from the provider with the client’s altered application (compared to the previous provider version). The application should gain new functionality from the provider’s update without losing the changes the client has made.
This task is quite familiar to anyone who has worked on a software team and merged their source code changes with those of other team members. Even if all the developers on a team use the same set of rules for developing and formulating code, merging source codes can be difficult. But for business applications it is further complicated because the provider’s and client’s developers work in different organizations and often do not have the opportunity to communicate if there are problems understanding the code.
Keep in mind that for changes made by the client that are too large in scale, the software provider may decide not to provide further support for the client’s solution.
Described above is one of the most complex tasks in the life cycle of any business system with source code access. The success of software on the market largely depends on how successfully the software manufacturer resolves this task.
Application changes in the 1C ecosystem
The 1C company and its partners provide all their solutions with the source code and strive to offer quick, high-quality customization “on site” at the lowest possible cost. 1C offers special methods and tools to accomplish this.
What is a 1C application?
The 1C application is a business application implemented on the 1C:Enterprise platform. It is comprised of not just the source codes, but also metadata. Metadata forms the structure of the 1C:Enterprise database. That is, the structure in which the application components are described-catalogs, documents, registers, etc.
The client gets the 1C application along with the 1C:Enterprise platform. And the metadata and source code of the 1C application can be viewed and edited in the platform’s special Design mode. This achieves an important outcome-any client on any PC with the 1C:Enterprise platform installed has access to a full spectrum of tools to administer and develop 1C applications. This allows them to fine-tune the application when implemented and make changes to the working application “on the fly” (without shutting down the system).
Terms used in the picture:
Designer — a specific 1C:Enterprise platform mode for the rapid development and administration of business applications.
Configuration or 1C application — an application developed on the 1C:Enterprise platform.
Components — metadata-driven objects of the 1C:Enterprise platform (catalogs, documents, registers, etc.) that the developer uses to build an application (configuration).
How are 1C applications supported?
In order to be able to support application changes, the platform has a built-in support mechanism that allows the solution provider to determine which application components (catalogs, documents, etc.) the client can change, and which ones they cannot, as changing them would interfere with the system’s operations or render its further centralized support from the provider impossible.
In turn, the client can also use this mechanism to define the rules for supporting the objects of its 1C application. For example, they can refuse provider support of a specific component if they take on the responsibility for further modification of that component or do not need that component in their work. Or they can restrict provider editing of a component in “their” configuration to ensure against the accidental interruption of that component’s operation.
Ideally, you want the client changes to exist “apart” from the provider’s standard configuration and only be engaged when the code is directly executed. In this case, installing updates from the provider becomes automatic, without the need for any human interference. To allow this, 1C offers two approaches that cover a significant percentage of customization scenarios.
The first approach is using external data processors and external reports. These mechanisms allow for additional functionality “on top of” the system, without changing the configuration’s source code. These are essentially scripts with a graphical interface designed to launch on a specific application solution.
The second approach is using extensions. The strategy of extensions is that the client does not have to change the standard configuration. All developer changes on the client side are made in the so-called extension, which is also essentially a configuration but is separate from the provider’s configuration. The business application (end configuration) consists of a combination of the provider’s standard configuration and the client’s extension. The 1C:Enterprise platform automatically merges the extension and the standard configuration when launching the business application.
This means provider updates will install automatically, since from the point of view of the support mechanism, the provider’s standard configuration has not changed. But the end configuration will run with the components added to the extension, and the business application will be altered according to the client’s desires. Thus, even with significant changes to the solution from the client side, support for the standard configuration does not stop.
Note that extensions are widely used when a business application operates on a service model using a data separation mechanism. For example, a client wants to receive several additional reports, but other clients wish to continue working with the unchanged standard configuration. In this case, a small extension can be developed strictly to meet the demands of the individual client and connected to the standard solution-then everyone is happy. It is essential to have all extensions connected and run in the context of the current values of the separators (although you can also apply an extension for all areas of separated information in the database), that way other clients will not even notice that a client has connected an extension.
These approaches have made 1C:Enterprise platform and solutions very popular. They ensure the functionality and flexibility of solutions while allowing you to maintain a high level of cost-effectiveness for the implemented solution throughout its life cycle.
Originally published at https://1c-dn.com.
