Designing a Microsoft SharePoint 2010 Infrastructure Vol 1 part 4 docx

MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Logical Architecture 1-1
Module 1
Designing a Logical Architecture
Contents:
Lesson 1: Identifying Business Requirements 1-4
Lesson 2: Overview of SharePoint 2010 Logical Architecture 1-22
Lesson 3: Documenting Your SharePoint 2010 Environment 1-31
Lesson 4: Documenting the Logical Architecture 1-37
Lab: Designing a Logical Architecture 1-46
MCT USE ONLY. STUDENT USE PROHIBITED
1-2 Designing a Microsoft® SharePoint® 2010 Infrastructure
Module Overview

This module discusses the importance of using the Microsoft® SharePoint® 2010
products to create a logical architecture design based on business requirements
before you implement a solution. The module covers conceptual content, defining
a logical architecture, and the components of SharePoint 2010 that you must map
to business specifications.
Requirements gathering, and the development of a solution design, are a complex
area of study. There is a range of structured methods for identifying, analyzing, and
documenting systems and business processes. This module reviews some of the
techniques for analyzing and designing business solutions for SharePoint 2010,
rather than any specific structured methodology.
Objectives
After completing this module, you will be able to:
• Identify business requirements and describe how business requirements affect
the logical architecture of a SharePoint 2010 deployment.

MCT USE ONLY. STUDENT USE PROHIBITED

MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Logical Architecture 1-3
• Map business requirements to SharePoint 2010 architecture components.
• Explain the importance of documentation and describe the options for
documenting logical architecture.
• Describe how to document a logical architecture design.


MCT USE ONLY. STUDENT USE PROHIBITED
1-4 Designing a Microsoft® SharePoint® 2010 Infrastructure
Lesson 1
Identifying Business Requirements

This lesson begins by explaining the importance of logical design when you are
planning a SharePoint 2010 deployment. You can only design a successful
SharePoint 2010 solution by gaining detailed knowledge of an organization’s
business requirements. The requirements must include both functional and
nonfunctional business success criteria. By gathering this information, you can
design a logical architecture for the business that is the foundation of more feature-
centered design for individual components such as Search or business intelligence
(BI).
Objectives
After completing this lesson, you will be able to:
• Describe the importance of planning a logical architecture.
• Describe the guidelines for gathering requirements.
• List approaches to requirements gathering.

MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Logical Architecture 1-5
• Describe functional requirements.

• Describe nonfunctional requirements.
• Describe how to organize information.


MCT USE ONLY. STUDENT USE PROHIBITED
1-6 Designing a Microsoft® SharePoint® 2010 Infrastructure
Importance of Planning the Logical Architecture

Key Points
The core capabilities for SharePoint 2010 include:
• Sites. SharePoint 2010 can provide all business Web sites: corporate intranet,
extranet, or Internet sites; project sites; personal sites; and so on. You can base
all of these on a single architecture and even a single farm, which makes
management and development easier.
• Communities or social computing. SharePoint 2010 delivers a range of social
computing functionality and solutions, including personal sites, wikis, blogs,
discussion forums, and tagging. All of these can be delivered in the corporate
farm and corporate security standards.
• Content management. SharePoint 2010 provides document, records, Web
content, and digital asset management that integrates seamlessly with
Microsoft Office 2010, and previous versions of the Microsoft Office system.
• Search. SharePoint 2010 provides a range of enterprise search options for
intranet search and people search, and a platform to build search-driven
applications.
MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Logical Architecture 1-7
• Insights or BI. SharePoint 2010 provides a range of BI tools including Excel
Calculation Services, PerformancePoint Services, and Visio Services that deliver
BI functionality to information workers in the form of dashboards, key
performance indicators (KPIs), and Web Parts.

• Composites. SharePoint 2010 provides functionality for information workers to
develop solutions, often accessing line-of-business (LOB) data to populate
applications.

All of these are enterprise-ready capabilities, so it is essential that you undertake a
rigorous design to ensure that your solution provides functionality that meets
business requirements and is manageable for IT staff. Each capability in SharePoint
2010 is designed to meet the requirements of related workloads, such as enterprise
content management (ECM) and Web content management (WCM), as SharePoint
Server 2010 becomes more business critical in the enterprise.

MCT USE ONLY. STUDENT USE PROHIBITED
1-8 Designing a Microsoft® SharePoint® 2010 Infrastructure
Essentials of Requirements Gathering

Key Points
A common reason for the failure of an IT deployment is lack of effective planning
and design. Technologists seldom fail to install and configure software and
hardware platforms, but deployments often do not match the business goals of the
organization. The first, and probably most important, component of a successful
SharePoint 2010 deployment is a thorough knowledge of the target organization
and its business goals. If a SharePoint architect fails to capture these requirements,
it is highly unlikely that the eventual solution will succeed from the business
viewpoint.
As a solution designer, you must gather key business information to ensure that
your solution reflects the requirements and goals of your organization. There are
several essential dos and don’ts for gathering business information.
Assembling the Right Business Team
The first step is to gather a team that knows the business and has the authority to
make decisions. This should include a business and IT sponsor, key stakeholders,

and business users. You can extend the team to include technical experts,
depending on your organization’s platform infrastructure. If you do not have the
MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Logical Architecture 1-9
correct group in place, you will struggle to discover the real business requirements
and to get effective validation of your analysis.
Preparing Your Questions
You should prepare your questions before you start the information-gathering
process. By doing this, you can direct the discussion to ensure that you get the
information that you require. A common mistake among new architects is to let
users drive the information-gathering process, which can mean that the
information is thorough in some areas, but does not give the designer the
necessary information to map against a later technical design. This can lead to
repeat interviews, which can be difficult to arrange. This may lead to a loss of
confidence from senior business figures.
Focusing on the Business Requirements
Ensure that the design is business-led. A perfect IT implementation that does not
meet business requirements is of little use to the business and will lead to loss of
confidence in IT solutions. The development from technician to designer requires
that you assess technology based on its ability to service business requirements,
rather than reviewing its technical functionality or build quality.
Establishing a Licensing Budget
The logical architecture must reflect business requirements, but it should also
reflect financial possibilities. You should establish the SKUs and options necessary
to fulfill business requirements to ensure that these are realistic within your
budget. This should also reflect the requirement for additional software or
platforms, such as Office 2010 or Microsoft SQL Server® 2008.
Including Functional and Nonfunctional Requirements
A good design may be one that causes least frustration. This means that you must
design to ensure both functional and nonfunctional suitability. Users quickly

become irritated by a solution that is slow or not available when they require it.
You must gather both functional and nonfunctional information because the latter
will have a major influence on your design.
Maintaining Documentation
When you have gathered information, make sure that you document the
requirements and the logical solution. If requirements change, you must update
the corresponding documentation accordingly. Without current documentation, it
will prove impossible for your team to complete the design effectively.
It is often just as important to avoid information-gathering hazards, so you should
make every effort to avoid common requirements-gathering mistakes.