1. Analyze your requirements - This seems obvious enough, but expect the unexpected. Aside from technical requirements, such as processor and disk utilization, it's easy to make unrealistic assumptions about the size of your user community. Make sure you communicate with your marketing staff to get projected usage numbers for an online promotion, for instance, or with your CFO's office staff when they launch a new billing system to outside contractors.
2. Build--or better yet, overbuild--the system -- Don't just build your system--from the application endpoints to the hosts and network--to meet minimum requirements. The architecture should take both planned and unexpected demand into consideration. And leave some headroom for the natural inefficiencies of underlying technologies such as TCP (dropping packets after a spike and then retransmitting them). This may entail splitting the application into pieces for the database, authentication and logging functions, for instance.
3. Test it -- Testing reveals the flaws in your initial performance analysis, highlights any blatant problems with the technologies you have chosen and provides an opportunity to address the deficiencies. But beware: If you don't find many problems, either your testing or your initial analysis is probably flawed.
4. Deploy it Obscure flaws in your initial analysis and the underlying technology typically arise in the deployment stage, as do problems with your testing methodology. Be ready to deal with these issues immediately. Too many organizations push out a system prematurely and then send the development team on holiday or on to another project.
Even after your system has gone live, you'll still need to monitor it. Think of the deployment/operational phase as live testing with real users banging on the system and giving you vital performance data. You'll find when you go operational that some assumptions you made during the initial analysis and testing were inaccurate. Be prepared to deal with that fallout.
There are two main rules of deployment. First, your original system-development team should be an integral part of the initial support team. That way, the hands-on experts are available to quickly address problems that crop up. It's almost always cheaper and faster to have the original development group fix problems than it is to hire hot-shot repair specialists who have to learn the entire system. Also, with the original experts performing initial monitoring and analysis, you can often detect problems before they occur.
