Designing a Microsoft SharePoint 2010 Infrastructure Vol 1 part 5 pdf

MCT USE ONLY. STUDENT USE PROHIBITED
1-10 Designing a Microsoft® SharePoint® 2010 Infrastructure
Avoiding Technology-Based Design
You should not focus your logical design on a given technology. Even if you are
designing a SharePoint 2010 solution, you may find that there are business-critical
components that require additional solutions or integration. Failure to identify
these may lead to a solution that does not meet business requirements. You should
identify requirements that may be out-of-scope for this particular project.
SharePoint 2010 has a range of great technical capabilities, but you should ensure
that your solution is based on business requirements, not solution features. The
SharePoint 2010 features may deliver the functionality that solves a business
requirement, but your design must always put the requirement before the feature.
Avoiding Leading Questions
When you prepare your questions, do not make them match your preferred
solution, otherwise there is an increased chance that you will miss a requirement
that does not fit with your predefined solution.
Updating Documentation
Design documentation is a set of living documents. As changes occur, you must
return and update plans so that you have an ongoing business and technical
description of the project. If you fail to do so, the documentation may become a
description of the initial design, which you cannot use for sign-off or rebuilds.
Additional Reading
For more information about SharePoint 2010 licensing, see



MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Logical Architecture 1-11
Approaches to Requirements Gathering

Key Points

When you need to find out about business requirements, you must ask managers
and staff who work in the business. This may seem obvious, but sometimes
computer analysts identify the technical solution and then force the business to fit.
Methods of Information Gathering
Common approaches to information gathering include:
• Sponsor and stakeholder interviews. You must engage with business sponsors
and stakeholders. These people have the overarching vision for the business
and the solution that they require. Business sponsors and stakeholders often
have budgetary control of the project. Questions may include:
• What is the business vision for the organization?
• What is the budget for the project?
• Focus groups. It is often more effective to gather teams together in focus groups
to discuss business requirements. You should work with your sponsor and
MCT USE ONLY. STUDENT USE PROHIBITED
1-12 Designing a Microsoft® SharePoint® 2010 Infrastructure
senior stakeholders to identify the composition of the groups so that you do
not get a skewed perception of the business. Questions may include:
• What key technology functions are required for your business division?
• What benefits do you want to realize from a SharePoint 2010 deployment?
• User interviews. With the help of the business stakeholders, identify key users
in the organization. These individuals will often have in-depth knowledge of
business processes, and may have a big influence in decision-making.
Questions may include:
• What are the key activities of your department and what functionality do
you need to execute these functions?
• What are the major productivity issues facing your department that may
be resolved through new technologies?
• User questionnaires. These can provide an effective means of quantitative
information gathering. A questionnaire should be well-structured, enabling
you to gather key information for trend analysis. For example, social

computing is an end-user solution. It is essential that you understand what the
end users expect from any social computing solution. Questionnaires often
consist of several closed questions and a few open-ended questions, which
may include:
• Do you need to use social computing functionality for your work?
• What benefits will this offer?
• Existing business processes. If there are existing business processes that your
solution must supersede or complement, you must review these. From a
technical viewpoint, you may need to integrate solutions, but you should first
understand the function of any existing systems or processes and how users
value them. You should not question existing business processes directly, but
you should analyze them to identify elements such as:
• Can we re-create or extend this functionality in SharePoint 2010?
• What degree of customization is necessary to re-create this functionality
and what will be the cost in resources?

Rules of Engagement
When you organize any business requirements–gathering sessions, you must
create rules of engagement. It is particularly important that you establish time
constraints. You should generally limit meetings to one hour, although this is
MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Logical Architecture 1-13
clearly a discretionary figure. Some meetings may require more time, particularly
for larger teams or focus groups. The one-hour duration is based on the fact that
most people are most attentive in the first 40 minutes of a meeting. If possible, you
should get the core business completed during this time and use the final 20
minutes to confirm decisions. You can nominate a mediator to lead the sessions
and a note-taker to take detailed notes.
All meetings should have an agenda with clearly defined goals of what you want to
achieve from the meeting. Without an agenda, meetings may lack focus, and some

users may direct discussions to a personal agenda. When users raise topics that are
outside the scope of the meeting, you must point out that such topics are
extraneous and agree to address them in a separate meeting if necessary.
Types of Information
The options of qualitative versus quantitative analysis can be important, and both
approaches are useful in gathering business requirements. Qualitative analysis
takes information from a smaller but better informed group, whereas quantitative
analysis draws information from a larger group. The key stakeholders and business
managers represent qualitative information because they should have the greater
overview of business goals. However, quantitative analysis, which is often in the
form of questionnaires or larger focus groups, can highlight business processes
that are unknown or unimportant to the business management team. Review
existing business processes to ensure that you understand how the business
works.
Reviewing Documentation
Always capture minutes of the meetings and allot time for attendees to review,
validate, and sign off your analysis. Make sure that your documentation reflects
business language, rather than transposing business requirements into computer
jargon.
Question: Describe any difficulties you have encountered in gathering user
requirement information.

MCT USE ONLY. STUDENT USE PROHIBITED
1-14 Designing a Microsoft® SharePoint® 2010 Infrastructure
Functional Planning

Key Points
Functional planning identifies the functions or business actions that you must
build into your design. You should define various levels of functionality in your
information gathering. These vary depending on the audience that you interview.

More senior business leaders tend to highlight overarching functionality, such as
usability and increased productivity, which may appear conceptual and vaguely
defined. However, your design will be measured by these factors, so you must
ensure that you establish metrics by which these may be measured. For example,
you can measure productivity by the speed with which a user can perform a task. If
there is an existing productivity baseline, you must exceed it. It is useful to find the
existing baseline because proving an increase in productivity without this may
prove very difficult.
Information workers are often more precise in their functional requirements. You
must document these functional requirements thoroughly because they may
ultimately provide the best proof of overall productivity improvements.
You must remember that there is a difference between function and features. The
former represents a business requirement, whereas the latter describes an
MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Logical Architecture 1-15
application or platform capability. Features must meet functional requirements,
but individual features may be unnecessary for a business solution.
There is a range of common functional requirements, but the most important is the
need to perform business processes:
• You must map common functionality directly to business processes. The
solution must be able to perform a task or achieve a goal. As part of your
information gathering, you must list the key business processes that your
SharePoint 2010 solution must complete. Ensure that you understand not
only the task, but also the scope of the task. For example, there may be a
requirement to tag documents consistently across an entire organization.
Alternatively, tags may need to be unique in divisions. You may have to deploy
a corporate information architecture taxonomy that is augmented by
divisionally specific taxonomies.
• The administration of departmental or project Web sites may be a core
requirement. This can affect options such as site permissions or self-service site

creation, for example.
• Authentication and authorization are always important in design. You must
ensure that security is robust, as corporate governance specifies, but complex
layers of security must not impede the individual functions and tasks.
• Many organizations require IT solutions to conform to regulatory or statutory
audit rules. This may extend beyond the bounds of user applications to
include the application platform itself. Make sure that you understand the
levels of audit and reporting requirements for regulatory compliance, so that
you can apply appropriate policies in SharePoint 2010 for ongoing data
management.
• Most corporate environments have complex integration requirements, which
involve data being generated or collated in one system and visualized or
analyzed in others. Your design must identify the potential interaction between
systems, including authentication options.
• You should also identify any reporting requirements for divisions in your
organization. This may be an important element of BI, which may not be a
term that anyone in the business uses. You must be aware of the SharePoint
2010 functionality and how it maps to the business language that you gather.

There are elements of functional and nonfunctional planning that can merge, such
as authentication versus security. It is important not to be overly concerned about
whether a requirement falls into either category; if the business requires a
capability, you should document it and include it to influence your design.
MCT USE ONLY. STUDENT USE PROHIBITED
1-16 Designing a Microsoft® SharePoint® 2010 Infrastructure
Question: List some functional requirements that you can identify in your
organization.

MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Logical Architecture 1-17

Planning for Nonfunctional Requirements

Key Points
It is more common for business users to emphasize functional rather than
nonfunctional elements, but failure to include the latter can have a catastrophic
effect on your final solution. Although users and stakeholders assume that a
system will always be available, you must plan for maximizing availability or
performance. In your logical design, elements such as scalability, performance, and
security may have a major impact on whether you deploy a single farm or multiple
farms for an organization.
The most common nonfunctional requirements focus on system capability,
availability, performance, and so on. These may have a greater impact on physical
design, but you usually only have one period of requirements gathering, so you
must make sure that you get all of the information that you require.
Key areas of nonfunctional planning include:
• Performance. Ensure that your design identifies performance issues such as the
number of users who access the environment at peak times.
MCT USE ONLY. STUDENT USE PROHIBITED
1-18 Designing a Microsoft® SharePoint® 2010 Infrastructure
• Capacity. Your design must provide sufficient capacity over an effective
hardware management period, which is normally two years. This means that
you have to specify systems that provide adequate storage for this period. In
addition to the base systems, you must analyze the goals of the business to
enable capacity for forecast growth. You must also be conversant with
requirements that are specific to SharePoint, such as software boundaries, to
ensure that data volumes do not exceed your logical architecture. For capacity
planning for SQL Server, you may want to enlist expertise from a database
administrator.
• Scalability. Your design must ensure potential for growth through scalability.
This may involve scaling up, by upgrading the initial systems, or scaling out,

with the addition of systems to share workloads. Your logical design should
also provide options for extensibility through scaling. It is rare for an
environment as rich and varied as the environment that SharePoint 2010
offers to remain static. You will often find that you must add or extend
functionality such as social computing, BI, or Search in an organization.
• Availability. Users assume that systems will always be available for them to use,
so you have to build this resilience into your plan. No system can guarantee
100 percent availability, so any service-level agreement (SLA) should establish
the percentage of downtime that is acceptable for business continuity. This
relates closely to availability solutions such as database clustering and network
load balancing. However, your logical design must ensure adequate availability
through the division of logical components across Web applications.
• Security. Security is an overarching goal, so your design may have to integrate
with organization-wide standards. Secure authentication may also affect your
logical design. You must ensure that you accommodate secure authentication
requirements by identifying the division of site collections and sites.
• Manageability. If your deployment requires self-service provisioning, you must
ensure that both administrative staff and delegated users can manage your
solution.
• Interoperability. SharePoint 2010 provides a user environment that can
visualize external data sources, for example, through out-of-the-box Web Parts.
Your design must accommodate these requirements.
• Business continuity. As an extension to availability, you must address business
continuity, or disaster recovery, options. This is often an organization-wide
strategy, but you should review the SharePoint 2010 requirements.

MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Logical Architecture 1-19
There is no default priority for these nonfunctional requirements. You must
prioritize each one based on the business requirements of your organization.

When you have established the requirements for each one, review your results with
the key stakeholders to establish the priority.