Planning for Scalability

Before deploying your portal, you need to make preparations for its growth. You need to ask some serious questions, and catalog your current and proposed infrastructure. Let's assume that you do not have a portal in place, but that you have an existing IT infrastructure.

The first step in the process is to understand the baseline. You should assess the current infrastructure, cataloging your assets, capacity, and usage. Determine current availability statistics, maximum loads, and performance parameters. Do you have excess capacity or a shortfall? How much are you spending on the current infrastructure?

For each component of a solution, performance is a function of factors including:

• Amount of information retrieved from and sent to the browser

• Complexity and resulting time required to process requests

• Resources allocated per user (memory, data connections)

• Location of processing (client, server, or both)

The less work a component has to do, the quicker it can do it. The closer the processing occurs to the user, the better, in terms of reducing communication time and taking advantage of distributed computing power. A t-shirt popular at university physics departments reads "186,000 miles per second isn't just a good idea. It's the law." The more electrons have to move and the farther they travel, the more you need to be concerned about performance. If you can locate related components close to one another, performance will benefit.

Identify the business and functional goals for your future architecture. Do you have a target for response time, throughput, or some other metric? Must your portal be available to outside business partners such as trading partners , banks, or others? What is the impact of this new group of users? What degree of availability do you require?

What is the budget for your project? Which resources could be upgraded or replaced and which must remain as they are? What are your schedule constraints?

Next, create an architecture for the portal you are building. This chapter contains some guidelines and resources for understanding the architecture of the portal. Be sure to factor in any anticipated growth in users or transactions. Will the portal create new demands for certain groups of users, such as content authors, discussion moderators, or site visitors ? Will the storage requirements expand dramatically for new content? Are you planning separate environments for development, testing, staging, and production?

Develop a migration plan to get from your current architecture to the bold new portal. What is the business impact of the migration? How can you mitigate disruption to employees and other users? What risks should you consider?

Test the new architecture, using pilots and labs as necessary to guarantee that the actual performance will measure up to theoretical performance. Feed the testing results back into the design and make changes as needed.

Deploy the new portal environment, developing management and maintenance procedures along the way. Next, migrate data and users to the new environment. Finally, go on vacation to a beach far away from Internet access and cell phones.

Microsoft offers these steps to scalability as a nine-step program in a slightly different context at www.microsoft.com/business/reducecosts/efficiency/consolidate/steps.mspx.