Software Packaging Principles
In my previous article on Software Governance in the Enterprise I gave an overview on how to get a grip of software in your enterprise. I then promised I would dive deeper into some of the areas, and looking at what search results lead people to www.neospot.se, an area of interest is apparently application / software packaging principles. Hence I’m prioritizing this topic.
The purpose of packaging principles is to ensure standards and consistency in how to package software and applications in a way that results in best security, usability, quality and compliance to company code of conduct and other policies. A common scenario is that the software is MSI packaged and deployed via Microsoft SMS/SCCM, but the principles should not be defined for, or dependent on, any specific tool or technology. Consider the principles high-level requirements to packaging technical standards, no matter if the service is in-house or outsourced/offshore (useful if you want to leave the control of detailed packaging standards and tools to the outsourcing/offshoring partner).
The following sample set of principles are based on best practices and experiences from large enterprises, and the principles have – in whole or in part – been adopted by both large and medium sized enterprises as well as a couple of the largest offshore packaging factories. If this is your area of expertise it’s likely you will consider the principles common sense, but even so, it’s useful to have them documented and use as a checklist in the packaging process.
|Auto-update features should always be disabled.||Updates are centrally managed, some users do not have access to install updates themselves.|
|No shortcuts should be placed on desktop or quick launch bar, unless specifically requested.||Should be kept as clean as possible and left to user’s control and preference.|
|Features or links promoting the user to purchase merchandise or pay for services should be disabled/removed/hidden.||Purchases should go through company predefined purchasing processes.|
|Features or links resulting in admin access required should be disabled/removed/hidden where possible/appropriate.||Would otherwise result in access denied issues where users do not have local admin access.|
|Features or links promoting capabilities in conflict with Software Standards and/or existing infrastructure should be disabled/removed/hidden.||Software Standards should be used first and foremost, unless approved exception.|
|Features or links encouraging behavior or usage in conflict with company Code of Conduct or Security Policies should be disabled/removed/hidden.||Minimizes risk and ensures compliance.|
|Microsoft User Experience Interaction Guidelines should be adhered to (re where to put shortcuts etc) unless otherwise justified.||Improved and consistent user experience.|
|Multi-language support should always be installed when available and technically viable.||Global reuse, less need for localised packages.|
|Default language should match the target OS Language (not the Location or Current format).||Otherwise, for example, En-Sv build with English UI and Swedish Regional Settings would result in Swedish UI for that software.|
|Anonymous information should be disabled from being sent/uploaded to vendors via Internet.||Would otherwise cause network load with no business value, potentially expose company information assets and violate employee personal integrity.|
|Memory resident processes should only be installed when deemed necessary.||Improves performance.|
|Icons on system tray should be avoided if not clearly providing any added value.||Keeps system tray clean from clutter.|
|File associations should not be set to override software standards (for example file extensions supported by WMP should remain with WMP).||Improved and consistent user experience.|
|Registration prompts and EULAs should not be shown to users.||License agreements are applicable between the company and the vendor, not the user and the vendor.|
|Prompts that are confusing to users should be preconfigured and not shown to users wherever possible to avoid.||Improved user experience, less support cost.|
|Installation process should be silent but visible to user, required reboot should be confirmed by currently logged on user(s), if any.||Consistent installation, shows user installation progress, and ensures user can save ongoing work before computer is rebooted.|
|Users should not be able to manually uninstall or update client core / mandatory components.||These components are centrally managed.|
|All installation packages should include ability to repair and uninstall itself.||Enables redemption of unused software licenses and facilitates troubleshooting.|
Again, these are just sample principles to get you going. Some of them will not fit your company, some you will customize and you will probably come up with new ones too. Feel free to share your custom principles in the comments field below for others to gain from.
Like the article? Help spreading it by pressing the button below.
|Print article||This entry was posted by Richard Nilsson on February 17, 2011 at 00:01, and is filed under All Articles. Follow any responses to this post through RSS 2.0. You can leave a response or trackback from your own site.|