This is the part of the project where you either begin to smash your budget or settle down to some serious work. By this time you should have established your packaging standards, developed your core build, understood your test and quality criteria and have established a cast iron upgrade policy. Please tell me you have…..
While the audit phase will define your project and give you the size of challenge you have ahead, the discovery phase will define your approach to the whole project. I’ll go through the points I made above first and then move on to the meat of the discovery process.
Your packaging standards are an incredibly important part of the project. They will define how you interface with the other technologies in your programme. I’m assuming that with this packaging project will come a new desktop, software delivery mechanism, some form of testing etc. With any project that is over 200 applications will come the requirement to automate some of these steps: with automation comes the need for consistency and that means standards.
Your core build defines the platform on which you will install all of your new application packages. It will consist of an operating system, drivers, key security products and a number of productivity applications such as Microsoft Office. It’s important to lock down the core build early on and establish change control as this creates the baseline upon which all your applications will be tested.
Testing and quality criteria
I’ll cover testing and quality criteria at a later date as they create their own set of processes and management challenges but it’s enough here to say that testing and quality are the two components that directly impact your relationship with external suppliers and business users. If you get this wrong you will be punished both financially and reputationaly throughout the project.
You might think the other points can create a headache but this is where your financial director could start to squeak. Lets take a couple of examples to understand the challenge:
1) You have 500 users who require some sort of file compression utility. During the audit you found that you have half the users with version 7 and the rest with version 9. You’ve already calculated that the packaging cost for each application is going to be around £1000. You also find out that the upgrade cost to move the users from version 7 to 9 is £2 per user. It’s a no brainer. To keep both versions is going to cost you £2000 in packaging costs. To upgrade and package just one application is going to cost you £1500. Easy
2) You have some sort of widget manufacturing design software. Used by 200 people in the business it is a critical piece of software. Recently one of the business units upgraded 50 users to version 2 at a cost of £50k for additional functionality. The other users didn’t need that extra functionality. During discovery you find that both applications work perfectly well on the new operating system. The manufacturer only supports version 2 of course and your compatibility software points out a couple of minor issues with the previous version.
You can see where the second example is going. If your upgrade policy contains any of the following:
- All users must use the same version
- All errors with the compatibility will be dealt with through upgrade
- If the manufacturer says upgrade then we have to for support reasons
Then you’re committed to spending a lot of money. You have to be pragmatic about this and you have to look at the external costs whenever you come up against these questions. If you’re not careful your upgrade policy can turn your £1 million project into a £10 million nightmare.
On to Discovery
Discovery is the process by which you learn how an application works, how it’s connected to the outside world and how it’s configured within your organisation. You will often have to search for the relevant person within the business who installed the application five or ten years ago. It is very important at this stage to capture your knowledge in a format that can be mined for information at a later date.
For example you may wish to keep a track of all applications that act as Add-Ins to Microsoft Excel, or all applications which cannot be virtualized. You may wish to detail which servers the application connects to so that you can build a dependency tree at a later date.
The knowledge and information that you collect at this stage is going to be crucial to the outcome of the project. The accessibility and security of this data is also of paramount importance. It’s no good having fantastic discovery documentation if no one knows where it is. You will also wish to collect notes as you carry along through the processes that will be pertinent to other people who come across the application. It’s at this point you may start to realise that an Excel spreadsheet just won’t cut it for gathering information. You will also start to appreciate that having a folder structure and collection of documents for each application is just going to obfuscate the valuable knowledge that you have collected.
With AppTracker, we have created the ability to dynamically build your own discovery knowledge base through the use of questionnaires. These forms can be used to create very powerful reports across your whole application portfolio. Your installation documents can also be stored as attachments for easy access by your packaging, testing and deployment teams.
From a workflow perspective, it is important to understand that the discovery phase will overlap with the packaging and testing processes. Discovery will not only act as a driver to the rest of the processes, it will also be required to capture change during the natural life of the project. Applications will always require updates throughout the project in a similar way to BAU packaging. There will also be cases where applications fail UAT due to configuration issues that will need to be rediscovered. There is nothing more frustrating than having a stack of rejected applications waiting for further configuration details while your packaging team struggle to churn through the current list of applications they have.
Application compatibility provides a means of rapidly checking your application estate for issues likely to affect your migration project. Be warned though, this is a danger point for your upgrade policy and you have to be pragmatic about what you are trying to achieve. There is always a battle here between technology led purists who want to make sure the new environment is pristine, and the business led managers who want to keep the costs as low as possible. It is therefore necessary to define a compatibility workflow that is right for your company and understand which issues are acceptable from a risk and impact perspective.
The last point I want to make about discovery is that it is a process that has a direct interface with your business. It is therefore important to choose the right people: they must be technical enough to understand the software dependencies, intelligent enough to make decisions based on risk and cost, and friendly enough not to frighten or annoy the business users. This is important because many of the business users who are contacted during the discovery phase are also going to be the people you will ask to test the applications during UAT.
This has been quite a long post, but this process is incredibly important to the outcome of the project as a whole. So, finally, to summarise:
- Make sure all of your standards and policies are in place
- Make sure you have defined your quality criteria
- Have an upgrade policy that matches what you are trying to achieve
- Make sure you overlap your resources
- Do not let your toolset drive your project, rather use it to make decisive choices.
- Chose the right people for the job
- Make sure the knowledge you have collected is centralized, accessible and secure
I hope you find these posts useful. I have put them together based upon the knowledge I have gathered over the years carrying out application migration projects. Please feel free to leave comments or ask questions.