This posting from Greg Lambert details the history of automation in desktop application packaging and the current state of the industry. Viewing that the recent developments from Readiness warrants an additional stage of the well-know maturity model.
I have been involved with desktop management and application packaging for over twenty years. While never professing to be a technical master of the space, I have been working on improving the packaging process and automation literally from my first batch file in 1995. We have moved from highly skilled individuals to global teams to now an industry that has largely remained unchanged. I think it’s worth discussing this change (or lack there of) and the current technical plateau or “automation local minimum“.
Let me walk you through my thinking here.
To improve their software capabilities, organizations need to take five basic steps:
- Understand the status of their development process
- Develop a vision of the desired process
- Establish a list of required process improvement actions in order of priority
- Produce a plan to accomplish these actions
- Commit the resources to execute the plan
One of the key changes that has occurred over the past decade is that IT processes are no longer “hand crafted” or solely relying on individual skill sets. Over the years, much of the skill sets for application packaging has been encoded in software or more seriously, simply lost or forgotten. During the early (and heady) days of Microsoft MSI Installer, packager or “desktop engineer” skill was paramount. Packing to the new database drive format was a real paradigm shift for many packagers and required extensive technical and process training. Gradually over the years, some minor technical improvements were made and early automation appeared in the form MSI Installer CUB files
From watching the desktop management process and packaging, I feel that the industry has progressed through the stages of process maturity. The five levels of process maturity which have been defined are:
- Initial – until the process is under statistical control, no orderly progress in process improvement is possible.
- Repeatable or Managed – a stable process with a repeatable level of statistical control is achieved by initiating rigorous project management of commitments, cost, schedule, and change.
- Defined – definition of the process is necessary to assure consistent implementation and to provide a basis for better understanding of the process. At this point, t advanced technology can be usefully introduced.
- Quantitatively Managed – following the defined process, it is possible to initiate process measurements. This is where the most significant quality improvements begin to appear.
- Optimized – with a measured process, the foundation is in place for continuing improvement and optimization of the process.
“The Capability Maturity Model (CMM) is a development model created in 1986 after a study of data collected from organizations that contracted with the U.S. Department of Defense, who funded the research. The term “maturity” relates to the degree of formality and optimization of processes, from ad hoc practices to formally defined steps, to managed result metrics, to active optimization of the processes.”
Level 1 – Initial
This is the starting level for a new or untried process. Practices may be somewhat effective, but they don’t take advantage of the power of the platform, nor do they consider the multiple use cases which exist in even the smallest and simplest organization. Typically, they are undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled, and reactive manner by users or events. This provides a chaotic or unstable environment for the processes.
Level 3 – Repeatable
Processes are documented or managed by a central group to enable (but not enforce) the preferred ways of doing them. Some processes are repeatable, possibly with consistent results. Process discipline is unlikely to be rigorous, but where it exists, it may help to ensure that existing processes are maintained during times of stress.
Level 3 – Defined
The process is well defined and agreed as a standard business process. There are sets of defined and documented standard processes established, signed off and subject to some degree of improvement over time. These standard processes are in place. The processes may not have been systematically or repeatedly used to the extent needed for their users to become fully competent or the process to be validated in a range of situations. This could be considered a developmental stage – with use in a wider range of conditions and user competence development the process can develop to next level of maturity.
Level 4 – Managed (Capable)
The process is quantitatively managed in accordance with agreed-upon metrics. Effective achievement of the process objectives can be evidenced (using metrics) across a range of operational conditions. The suitability of the process in multiple environments has been tested and the process refined and adapted. Process users have experienced the process in multiple and varied conditions and are able to demonstrate competence. The process maturity enables adaptions to projects without measurable losses of quality or deviations from specifications. Process Capability is established from this level.
“The basic principle of software process management is that if the development process is under statistical control, a consistently better result can only be produced by improving the process. If the process is not under statistical control, no progress is possible until it is. Edwards Demming, Quality, Productivity, and Competitive Position, Cambridge, MA: Massachusetts Institute of Technology Center for Advanced Engineering Study, 1982
Level 5 – Optimizing (Efficient)
Process management includes deliberate process optimization/improvement. The focus is on continually improving process performance through both incremental and innovative technological changes/improvements. Processes are concerned with addressing statistical common causes of process variation and changing the process (for example, to shift the mean of the process performance) to improve process performance. This would be done at the same time as maintaining the likelihood of achieving the established quantitative process-improvement objectives.
This is all great – however, I think that the MSI Installer community has worked hard over the years and reached a point of individual excellence. That was fine for larger, corporate deployments but no longer suits the continual, incremental changes found into today’s modern desktop environments. We now facing constant change, rather than singular monolithic migrations. To cope with this, many organizations are lowering their corporate standards, reducing quality levels, and skipping key deployment steps (. e. g testing).
I would like to add a further 6th stage to the capability model: Industrialization
This stage representations the “scaling out” of the packaging process. With most of the technical process fully automated and most importantly; support for massive parallel processes Industrialization of application packaging represents a new era of IT process and desktop management. Each “Industrialized” stage would be automated, monitored and include a feedback loop for continual improvement. As more people use the process, the levels of automation would increase, quality will improve with few, less sever errors and over time the performance of the system will improve. One of the key aspects of a learning system like this, is that the problems are privatized, but the solutions are shared or socialized.
Readiness has taken the capability model, extended it and create a new vision of application packaging, testing and deployment. In my next posting, I will detail how we have now entered the 6th stage of application packaging. From crafting with artisans to the Readiness industrialization of desktop management.
References:
- S. Humphrey, “Characterizing the software process: a maturity framework,” in IEEE Software, vol. 5, no. 2, pp. 73-79, March 1988, doi: 10.1109/52.2014.Abstract: A description is given of a software-process maturity framework that has been developed to provide the US Department of Defense with a means to characterize the capabilities of software-development organizations. This software-development process-maturity model reasonably represents the actual ways in which software-development organizations improve. It provides a framework for assessing these organizations and identifying the priority areas for immediate improvement. It also helps identify those places where advanced technology can be most valuable in improving the software-development process. The framework can be used by any software organization to assess its own capabilities and identify the most important areas for improvement.<>URL: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=2014&isnumber=122 – https://apps.dtic.mil/sti/pdfs/ADA182895.pdf
Capability Model: https://en.wikipedia.org/wiki/Capability_Maturity_Model
Microsoft Maturity Model: https://docs.microsoft.com/en-us/microsoft-365/community/microsoft365-maturity-model–intro
