Most large organizations face difficulties in implementing queuing software. These difficulties are both objective and subjective. The objective difficulty is the heterogeneity of the IT infrastructure, which is impossible to completely overcome. However, IT managers and system administrators do not always pay due attention to this problem. The main subjective difficulty is to treat corporate software as if it were boxed service and, as a result, belief in the existence of a “magic green button”: clicked - and everything was established (updated). In practice, such a scenario, alas, is unrealizable.

What is the difference?
The installation of a boxed product is usually performed according to a rather simple “iterative” scenario: I tried to install → did not work → fixed problems → tried again. For the installation out of the box, such a sequence is justified, because in case of blocking problems, they are localized on a specific computer. In this case, the user may well spend some personal time on installing the missing components, setting up the operating system, etc. In general, we can say that 20 minutes of setting up one workplace is quite an average figure.
Service of corporate software is often also attempted to carry out an iterative scenario, but the “price” of the iteration increases many times. The time spent on setting up the workplace, in the case of mass deployment, must be multiplied by the number of installations, and the harmless 20 minutes already with 10 computers turn into at least 3.5 hours of working time spent, in fact, mechanical (i.e. well automated a) operation.
')

Further, in the case of distributed systems, blocking problems may have arbitrary localization within the network, and to eliminate them, it may be necessary to involve specialists from other departments, since, as a rule, at most enterprises the organizational units responsible for system-wide and product administration are separated. This requires additional time costs. In general, according to our statistics, updating of 30 jobs in one working day by four people is the limit of manual labor productivity.
Effective management of such a process with any significant number of jobs without a proven methodology is impossible. The essence of this technique lies in the fact that problems need to be identified in advance, and eliminated - centrally, and to do this before performing software maintenance. It would seem that everything is simple? But even if such a technique is available, a tool is needed for its implementation, no more difficult than the problem being solved.
To automate IT infrastructure management, a variety of tools and solutions have been created, from the most simple, usually aimed at automating typical repetitive actions in the workplace (let's call them "light class solutions"), to very complex and sophisticated (by analogy, you can say about solutions of the “middle and heavy classes”), covering all or almost all aspects of management.
We are not interested in “light class” solutions: with their help, at best, we can ensure that drivers and a set of frequently used programs such as office, archivers, etc. are installed on the workplace. As a rule, they are based on a simple scripting language, which executes the mechanism can emulate console input, manage windows, processes and other objects. The limitations of such solutions are primarily due to the fact that in the process of giving the script universality (necessary for it due to the heterogeneity of the infrastructure) its complexity increases significantly, requiring from the developer not only good programming skills, but also a rather deep understanding of the OS architecture and application software. In the conditions of chronic lack of time and resources, urgent solution of the tasks that had to be “done yesterday”, the use of “easy” solutions does not lead to a satisfactory result.
On the other hand, there are “heavy class” solutions that usually seek to “crush” almost all aspects of infrastructure management (hardware and software inventory, software usage monitoring, configuration monitoring, virtualization management, etc.). Because of their versatility, such solutions are so difficult to use that their study and proper application sometimes becomes no less laborious than solving the main task. The second thing to say about these systems is that the “remaining” part of the functionality, which is not related to software maintenance, may be an enterprise and not needed. Given the considerable cost, such costs often do not justify themselves.
The structure of the ASCON Solution Complex on the LOTSMAN: PLM platform, the CSC works with itIn order to facilitate the work of the administrators of the ASCON software package, which automates product life cycle management, we developed a solution that can be attributed to the “middle class”. It does not require programming, although it allows you to perform trusted (signed) scripts if additional post-installation actions are necessary. At the same time, it does not contain redundant functionality that is difficult to master and learn. We called it
"Service Center Complex" .
"Service Center Complex". The main distinctive points of the decision
Lightweight tailored to the specific. The product is not overloaded with unnecessary functionality, focused on the most simple solution of the main task - mass service (installation, updating) of ASCON products such as LOTSMAN: PLM, CAD VERTICAL, Materials and Assortments reference book, Reference book Standard products, KOMPAS-3D and others, taking into account their specifics.
Reasonable versatility. The product allows you to service almost any third-party software that uses the Windows Installer mechanism for installation. At the same time, a part of related tasks is also solved, for example, monitoring configurations - but only to the extent that is necessary to solve the main task, and no more. Of course, third-party software configurations are monitored only by basic parameters, but often they are enough to localize and fix the problem.
Centralized diagnosis. Obviously, a successful infrastructure is required for successful software maintenance. The problem is that product administrators often do not have direct access to the central, vital IT infrastructure (AD DS, DNS, DHCP, group policies, etc.). And even if they had it, would it be easy to understand the multi-tier architecture, which, moreover, you hadn’t designed yet? Therefore, the collection, storage and display of diagnostic information about the hardware and software configuration of the workplace and the basic settings of the OS is critical for software maintenance. Again, it is carried out only to the extent that is necessary for practical work. Partially solves the problem of inventory equipment and software.
Localization problems. Our observations show that a significant portion of failures and errors (from 30% to 50%) arising from the operation of corporate software are caused by infrastructure problems. Unfortunately, in large enterprises with a strictly regulated organizational structure (for a number of reasons), there is an implicit flow of that share of responsibility for the inoperability of products, which lies with system-wide administrators, to product administrators. We solve the problem of localization through continuous monitoring of the infrastructure with the accumulation of the obtained data for further analysis.
Integration into the product portfolio. As a rule, large manufacturers of corporate software try in one way or another to solve the problems of mass service of their products. Until now, ASCON did not have such tools. Now we take a step towards meeting the customer and close another segment of the automation of business processes.
In general, we hope that this solution will be in demand in industry and, above all, when servicing complex PDM / PLM-systems. Although, as mentioned above, the range of serviced software is limited only by the mechanism used for deployment (Windows Installer). True, in fairness it should be noted that it is unlikely that anyone would think of using an “easy” NSIS type installer for a corporate system.
Well, as a conclusion a few specific numbers. Tests of the system in “combat conditions” have shown that with its help, even with a minimum level of initial preparation of the production environment, you can update / install from 65 to 70 computers per hour! This is about a minute on one computer, while one person can perform all operations. A comparison with the figures given at the beginning of the article (30 jobs in one working day by four people) confirms an increase in labor productivity by at least an order of magnitude.

Alexander Yukhimenko, head of the development team for the Unified Installer of the Complex.