The Realities of Software Distribution within the Enterprise
The purpose of this document is to briefly discuss the resource requirements (Tasks, Tools, Labor and Time) for an effective software distribution process to work within a corporate environment. It is also anticipated that by describing the phases and some of the associated tasks, it shall become clear where the majority of challenges originate from, and hence, where the majority of resources should be assigned.
Introduction
The software distribution tool marketplace is presently full of vendors promoting solutions based on their individual product offerings – meaning the solutions are tied to the product’s strengths and any product weaknesses are sidestepped by bringing emphasis back to these strengths. These types of marketing strategies inevitably lead to a failure to meet customer expectations, and are undoubtedly why so many tools have had such poor implementation success records (₁). These products have almost exclusively been engineered around a feature list – as opposed to being engineered around a process. So, rather than follow the traditional convention of describing a tool and then wrapping a process around it (square peg in a round hole syndrome), this document shall briefly describe a software distribution process and then allow the reader to determine which tools fit which requirements best.
Software Distribution Life Cycles
Software Distribution is the mechanism for deploying software to workstations through the use of automated tools. The purpose of automation is to increase service levels for the business by improving response times and not increasing costs. Additionally, TCO reductions can be directly attributed to automating the Software Distribution process. The typical corporate software distribution mechanism can usually be broken down into several distinct phases. This mechanism may vary from company to company, however the goals and objectives as well as most of the concepts remain surprisingly universal.
Receive initial request
The request for a software distribution job usually comes from one of three sources within an organization (listed below): Business requirement (e.g. a Line of Business enhancement) Technical requirement (e.g. a new messaging client) Maintenance requirement (e.g. a support patch) It is also at this early point in the process that the recipients for the software distribution job are usually defined. All requests for software distribution come into the same point. At this stage, the anticipated resource requirements are collected. Additionally, the life cycle stages this distribution job should participate in are defined. Some of the deliverables requiring completion for this life cycle phase to be complete would be as follows: Description of distribution job List of recipients Testing requirements (what type of testing and how much) Quantified benefits of the application to be rolled out (sometimes declared as a value – for example a screen blanker has a quantified business case of 1, while a new mission critical banking application might be a 10)
BA business acceptance (if relevant)
In this phase the business confirms that the application and its components conform to the requirements initially presented to either the development group or the internal IT group. Although most organizations will probably have a BA process as part of their internal development process, this apparently redundant process serves to lock down the application and its components to be submitted for distribution and rollout. Preventing or at least minimizing the chances of last minute changes. It is at the end of this life cycle that a pseudo “Bill Of Materials” be created. This “BOM” contains a list of all of the components that are part of the distribution job, to include file components, file and registry level, configurations and finally unique settings anticipated for location and organization (for example, drive mappings and font types). Some of the deliverables requiring completion for this life cycle phase to be complete would be as follows: Documented acceptance by the business of the distribution job. A Bill of Materials containing every item within the distribution job.
EIT Enterprise integrity testing
This life cycle phase is responsible for identifying any conflicts that may arise with corporate level Enterprise standards. These could include Operating system dependencies, network conflicts, security liabilities and so on. Some of the deliverables requiring completion for this life cycle phase to be complete would be as follows: Enterprise Base line liabilities Enterprise network liabilities Enterprise security liabilities
SIT Site (business unit) integrity testing
This life cycle phase is responsible for identifying any conflicts that may arise with business unit level environment standards. Specifically, if there are any conflicts with configurations unique to the business unit. These could include unique Line of Business applications, a unique type of hardware device, etc. Some of the deliverables requiring completion for this life cycle phase to be complete would be as follows: Business Unit application integration liabilities
Risk Assessment – Go/No Go
This phase is responsible for assessing all the liabilities and the declared benefits of the distribution job. Typically the liabilities are compounded into a value, and that value is assessed against the value declaring the benefit. Some of the deliverables requiring completion for this life cycle phase to be complete would be as follows: Documented assessment of the risks moving forward with the distribution job. Approval to continue with the distribution. Notification and acceptance from parties involved, the business unit, IT network group, the help desk and so on.
Scheduling
Once the green light has been given to deploy the new application, a schedule must be defined between the IT group and the owners of the target machines. Due to the significance of the deployment, it might require a pilot rollout to sample the results. This is also the last valid opportunity for the business to raise any concerns or considerations. Some of the deliverables requiring completion for this life cycle phase to be complete would be as follows: Deployment schedule
Pilot rollout yes/no decision Any special considerations that may have arisen
The pilot rollout/full rollout
The pilot/full rollout phase should consist of merely placing the distribution job into a channel assigning the recipients and having the propagation continue automatically.
Monitoring/event management
This phase in the life cycle usually happens in parallel to the pilot/full rollout phases. This phase consists of monitoring for any unanticipated anomalies, such as an inordinate amount of network bandwidth utilized, or for failure events returning from the desktop unpackager and verifying that the rollback procedure worked successfully and that the workstation is back to its original working condition.
Post rollout assessment
The purpose of this phase is to review and document the accuracy of the testing and risk assessment cycles. Any lessons learned are applied to the next time the software distribution process is used. This phase assists in maintaining the integrity of the overall process as the organization’s needs evolve. One of the deliverables requiring completion for this life cycle phase to be complete would be: An assessment of the predictive accuracy of the testing and risk assessment cycles – with recommendations for future enhancements.
Tools / Points of the solution The packager
The packager is the tool for building the software package to be installed on to the target workstation. The packager can be a scripting language (e.g. MS Test, Install Shield) or a snapshot builder (e.g. WinInstall).
The testing tool
The testing tool is used to determine conflicts between software components on the target workstations before a distribution job is deployed. Conflicts can be found using several methods, these methods vary in scope and intensity depending on the size of the environment, number of recipients and the dependence upon technology by the business.
The Truck
The “Truck” is the tool for deploying a software distribution package across a large enterprise. A truck is able to accommodate for bandwidth limitations, connection failures and provide a comprehensive set of event based information to a central console or SNMP framework.
The Unpackager
The Unpackager, is the mechanism that deploys the software package onto the workstation. If an application’s install program were not being run, it would typically be the Unpackager that creates folders, copies files, modifies registry keys etc…
The Installer
This is a new category, more people are beginning to distinguish between the Unpackager and the mechanism that actually makes changes to the workstation. Examples of Installers are an NT Service and the Microsoft Windows Installer .
The undo / rollback mechanism? Failure / disaster recovery?
Critical to the success of any Software Distribution solution is the ability to reset the configuration of a target workstation in the event of a failure. The effectiveness of this component can play a major part in deciding if software distribution is to be a money saver.
Resource requirements Many different disciplines
Many of the tools/point solutions required for completing software distribution have their own unique skill sets and knowledge requirements. Building application images for deployment requires intensive application and operating system experience. At the other end of the spectrum, deployment using the “Truck” may require Wide Area Networking experience. Therefore it is essential that the tool selection process is conducted using input from people representing the various disciplines. Tool selection can easily become misguided by vendor claims and unclear objectives. The decision to select best of breed against an all-encompassing solution can sometimes be affected by time constraints during the evaluation phase. The pressure to accomplish this task and move on and start on the implementation phase can be tremendous. However, any of the perceived time savings generated by accelerating the tool selection phase and not building an complete process will cost significantly more in the long term due to delayed implementation cycles, custom integration and missed customer requirements.
Resource by life cycle stage (tables with steps and hours)
The following tables below review several stages of implementing and using a software distribution tool within a sample customer environment containing four thousand (4000) desktop computers.
Resource and Time requirements for installation and setup of functional configuration
Packager Knowledge Required Application and Operating System Time Required 100 hours (includes building application images for existing legacy of applications) 40 hours
Business needs and extensive application knowledge WAN and Server configuration 20 hours Truck Application and Operating 10 hours Unpackager System Operating System (incl. Registry) 20 hours Installer Operating System, Application, 10 hours Undo / Rollback Network and specific job knowledge * In today’s marketplace, none of the software distribution products cover all of the aforementioned disciplines. This lacking invariably leads to either purchasing a combination of products or extensive customization of a single product by the customer. It is this customization that takes the majority of time to complete. Additionally, any functionality that is engineered beyond the scope of the “out of the box” product, is prohibitive to maintain and usually forces the customer to place a high dependency on the employee responsible for engineering the custom solution. Most organizations view this type of dependent relationship as a liability. Testing Tool
For daily operation (over a one month period)
Packager Knowledge Required Application and Operating System Time Required 30 hours
Business needs and extensive 30 hours application knowledge WAN and Server configuration 4 hours Truck Application and Operating 0 hours Unpackager System Operating System (incl. Registry) 0 hours Installer Operating System, Application, 5 hours Undo / Rollback Network and specific job knowledge * Once the Software Distribution process has been engineered and the point tools have been implemented, the labor requirements become even more one sided. Almost exclusively, the majority of resources are centered on creating images or determining the liability of any new application changes. Testing Tool
Conclusion
Software Distribution is probably the component of desktop management with the greatest opportunity for ROI. However, as presented within this document, Software Distribution consists of several diverse disciplines. Often Companies reviewing their Software Distribution needs misunderstand the significance of the disciplines and the relationships between the distinct components (for example, very few customers place enough emphasis on process engineering). The other issue is that vendors cover up their weaknesses’ with their strengths – further confusing the issue (for example, many vendors cover up their packaging shortcomings by emphasizing the need for a robust truck). It is fair to say that, in most environments the major software distribution challenges are package creation and testing related, yet the amount of focus placed upon these tasks is disproportionate to the resource requirements.