With standards in place, the process confirmed and discovery info beginning to come through, it’s time to start packaging. As it is just a conveyor belt process just grab a couple of cheap resources and lets get cracking…
Ok, so I’m just trying to get your attention, but you wouldn’t believe how many people I have heard use the above sentence. It does make the point though that the art of packaging is a very misunderstood process; indeed it is a repetitive task that’s seems fundamentally easy. You take a clean machine, install some software, take a snapshot and capture the difference between the clean machine and the install. Simple.
What this process doesn’t take into account is the complexity of configuration, the dependency analysis and the understanding from a coding level as to how applications are put together. When an application throws an exception on your new operating system, it is necessary to work out why, by capturing the API calls made by the executable using tools such as Depends, RegMon or FileMon.
This type of knowledge takes years to assimilate and understand and that is why most good packagers will also be pretty proficient coders, web developers, and SQL Server admins. They will understand how applications interact on a code, operating system, network, database and protocol level.
This sort of knowledge comes at a cost; not only from a financial perspective but from a management perspective too. A good packager will be able to work autonomously and rattle through the newly discovered applications while ensuring they are following the standards and quality criteria. You would think that this would be great news for the project. Unfortunately you have to balance this potential speed with the realisation that this is a highly skilled yet fundamentally boring process. Some applications provide challenges while others won't.
The challenge then becomes one of keeping your best packagers focussed while not letting them get bored: either by getting them to mentor your weaker packagers or allowing them to use their skills to benefit other sides of the project. This is going to sound counter intuitive, but some of your better packagers will want to help out with some of the more technical challenges to the project.
You may need to build a web based request portal, work out a technical installation process for your operating system or even help the developers to understand how to integrate their applications with other systems. Giving your packagers additional smaller challenges are all good ways of keeping the packaging process moving along while keeping interest high. As long as everyone is completing their quota, you can use the spare cycles to keep moral high and work out some of your more technical issues.
I guess one of the questions you may ask is: “Why can’t I just use cheaper resources and push harder?” and that’s a good point. However it’s always going to cost you in the long run. From an outsource perspective it's an easy call. Many of these companies will just pile up the packagers and get the process churning through the applications like the conveyor belt I mentioned at the start of the article. The challenge here is to understand your future costs.
Here is an example of what I am talking about: an in house packager will spend a number of days creating a multi configuration package to suit many different departments. An outsourced packaging company will undoubtedly be charging on a per package basis and will want their resources to get through the process as quickly as possible and therefore produce multiple packages for each configuration. Either way is not bad practice it’s just a case of balancing outsourced companies business drivers with the client companies business drivers.
Also, cheaper resources will not have the experience that you may be looking for to package some of your more complex applications. This can leave you with the choice of having to recruit a technical trouble-shooter to assist the packagers when they get into difficulties.
Packaging isn’t just a technical process however; it is also a chance to capture knowledge about your application portfolio in a way that may help resources further along in the migration process. You will therefore want you packagers to be able to annotate the application knowledge base as they go along. This is often valuable information captured outside of the formal discovery documents such as pointers on what to expect on first launch or who is a good person to talk to if there is an issue etc.
So where does AppTracker fit in to all of this. AppTracker provides the ability to annotate the knowledge base whichever process you are working in. Adding notes, further discovery information, document attachments, and screenshots are all possible using AppTracker’s easy to use interface. In addition, a historical record of all changes to the knowledge base is kept to ensure data integrity.
I’ve also talked about how talented yet difficult to manage most good packagers are. An important function of AppTracker is it's ability to report extensively on process, user, workflow and discovery information right out of the box. It's no good thinking you have a great team, and have collected loads of valuable date if you can’t report on it.
This hasn’t been the longest post but there isn’t much to say about packaging from a business perspective. I’ll finish here and summarise:
- Packaging can be a complex yet repetitive process
- Use highly skilled packagers where possible to save costs in the long run
- Chose a strong team leader to keep both moral and throughput high
- Balance your team and allocate applications where appropriate
- Understand that highly skilled packagers can add value outside of the project to tackle challenging issues when they arise
- Make sure you can report on how well your team is doing
- Ensure that all of your valuable data is accessible and reportable