Planning your Communications Suite deployment requires that you first analyze your organization’s business and technical requirements. This chapter helps you to gather and assess your requirements, which you then use to determine your Communications Suite design.
This chapter contains the following sections:
For detailed information on the deployment process for Communications Suite, and Java Enterprise System components, see the Sun Java Enterprise System Deployment Planning Guide.
Before you purchase or deploy Communications Suite hardware or software, you need to identify your deployment goals. Deployment requirements can come from various sources within an organization. In many cases, requirements are expressed in vague terms, requiring you to clarify them towards determining a specific goal.
The outcome of your requirements analysis should be a clear, succinct, and measurable set of goals by which to gauge the deployment’s success. Proceeding without clear goals that have been accepted by the stake holders of the project is precarious at best.
Some of the requirements you need to examine before you can plan your deployment include:
Your business objectives affect deployment decisions. Specifically, you need to understand your users’ behavior, your site distribution, and the potential political issues that could affect your deployment. If you do not understand these business requirements, you can easily make wrong assumptions that impact the accuracy of your deployment design.
Express operational requirements as a set of functional requirements with straightforward goals. Typically, you might come across informal specifications for:
End-user functionality
End-user response times
Availability/uptime
Information archival and retention
For example, translate a requirement for “adequate end-user response time” into measurable terms such that all stake holders understand what is “adequate” and how the response time is measured.
A deployment needs to take into account your corporate culture and politics. Demands can arise from areas that end up representing a business requirement. For example:
Some sites might require their own management of the deployed solution. Such demands can raise the project’s training costs, complexities, and so forth.
Given that the LDAP directory contains personnel data, the Human Resources department might want to own and control the directory.
Technical requirements (or functional requirements) are the details of your organization’s system needs.
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.
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.
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.
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?
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?
Financial restrictions impact how you construct your deployment. Financial requirements tend to be clearly defined from an overall perspective providing a limit or target of the deployment.
Beyond the obvious hardware, software, and maintenance costs, a number of other costs can impact the overall project cost, including:
Training
Upgrade of other services and facilities, for example, network bandwidth or routers
Deployment costs, such as personnel and resources required to prove the deployment concept
Operational costs, such as personnel to administer the deployed solution
You can avoid financial issues associated with the project by applying sufficient attention and analysis to the many factors associated with the project requirements.
You should develop SLAs for your deployment around such areas as uptime, response time, message delivery time, and disaster recovery. An SLA itself should account for such items as an overview of the system, the roles and responsibilities of support organizations, response times, how to measure service levels, change requests, and so forth.
Identifying your organization’s expectations around system availability is key in determining the scope of your SLAs. System availability is often expressed as a percentage of the system uptime. A basic equation to calculate system availability is:
Availability = uptime / (uptime + downtime) * 100
For instance, a service level agreement uptime of four nines (99.99 percent) means that in a month the system can be unavailable for about four minutes.
Furthermore, system downtime is the total time the system is not available for use. This total includes not only unplanned downtime, such as hardware failures and network outages, but also planned downtime, preventive maintenance, software upgrade, patches, and so on. If the system is supposed to be available 7x24 (seven days a week, 24 hours a day), the architecture needs to include redundancy to avoid planned and unplanned downtime to ensure high availability.
Your investigation and analysis should reveal your project’s requirements. Next, you should be able to determine a clearly measurable set of goals. Specify these goals in such a manner that personnel not directly associated with the project can understand the goals and how to measure the project against them.
Stake holders need to accept the project goals. The project goals need to be measured in a post-implementation review to determine the success of the project.
In addition to determining what capacity you need today, assess what capacity you need in the future, within a time frame that you can plan for. Typically, a growth time line is in the range of 12 to 18 months. Growth expectations and changes in usage characteristics are factors that you need to take into account to accommodate growth.
As the number of users and messages increase, you should outline successful guidelines for capacity planning. You need to plan for increases in message traffic for the various servers, a larger volume of users, larger mailbox sizes, more calendar appointments, and so forth. As growth occurs in the user population, usage characteristics change over time. Your deployment goals (and therefore deployment design) must respond accordingly to be viable into the future.
Ideally, you should design your architecture to easily accommodate future growth. For example, use logical names for the Communications Suite services themselves. See Using Logical Service Names for more information. Monitoring the deployment, once it enters its production phase, is also crucial to being able to understand when and by how much a deployment needs to grow.
Total Cost of Ownership (TCO) is another factor that affects capacity planning. This includes choosing the hardware upon which to deploy your Communications Suite. The following table presents some factors to consider as to whether to deploy more smaller hardware systems or fewer larger hardware systems.
Table 2–1 Considerations for Total Cost of Ownership