Defining Technical Requirements

Technical requirements (or functional requirements) are the details of your organization’s system needs.

Supporting Existing Usage Patterns

Express existing usage patterns as clearly measurable goals for the deployment to achieve. Here are some questions that will help you determine such goals.

• How are current services utilized?

• Can your users be categorized (for example, as sporadic, frequent, or heavy users)?

• How do users access services (from their desktop, from a shared PC or factory floor, from a roaming laptop)?

• What size messages do users commonly send?

• How many invitees are usually on calendar appointments?

• How many messages do users send?

• How many calendar events and tasks do users typically create per day or per hour?

• To which sites in your company do your users send messages?

• What level of concurrency, the number of users who can be connected at any given time, is necessary?

Study the users who will access your services. Factors such as when they will use existing services are keys to identifying your deployment requirements and therefore goals. If your organization’s experience cannot provide these patterns, study the experience of other organizations to estimate your own.

Regions in organizations that have heavy usage might need their own servers. Generally, if your users are far away from the actual servers (with slow links), they will experience slower response times. Consider whether the response times will be acceptable.

Site Distribution

Use these questions to understand how site distribution impacts your deployment goals:

• How are your sites geographically distributed?

• What is the bandwidth between the sites?

  Centralized approaches will require greater bandwidth than de-centralized. Mission critical sites might need their own servers.

Network Requirements

Here are some questions to help you understand your network requirements:

• Do you want to obfuscate internal network information?

• Do you want to provide redundancy of network services?

• Do you want to limit available data on access layer hosts?

• Do you want to simplify end-user settings, for example, have end users enter a single mail host that does not have to change if you move them?

• Do you want to reduce network HTTP traffic?

Answering yes to these questions suggests a two-tiered architecture.

Existing Infrastructure

You might be able to centralize servers if you have more reliable and higher available bandwidth.

• Will the existing infrastructure and facilities prove adequate to enable this deployment?

• Can the DNS server cope with the extra load? Directory server? Network? Routers? Switches? Firewall?

Support Personnel

24-hour, seven-day-a-week (24 x 7) support might only be available at certain sites. A simpler architecture with fewer servers will be easier to support.

• Is there sufficient capacity in operations and technical support groups to facilitate this deployment?

• Can operations and technical support groups cope with the increased load during deployment phase?