MCT USE ONLY. STUDENT USE PROHIBITED
1-30 Designing a Microsoft® SharePoint® 2010 Infrastructure
• Hardware and IT costs. Each environment, which is sometimes referred to as a
property, requires unique configuration and thus hardware and management
resources.
• Self-management. Users can manage their own environments, rather than have
a central department provision all services.
• Financial resource management. Multi-tenancy, which is designed primarily for
hosting companies, is easy to define for the purpose of internal cross-charging.


MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Logical Architecture 1-31
Lesson 3
Documenting Your SharePoint 2010
Environment

Documentation is a key element of design. Commonly, documentation follows the
development of a solution, whereby developers document the technical aspects of
a design. This lesson discusses documentation of your SharePoint 2010
deployment. Documentation is an essential tool for support and ongoing solution
development, so you must understand what you should document in a SharePoint
2010 environment.
Objectives
After completing this lesson, you will be able to:
• Explain why you should document your SharePoint 2010 environment.
• Describe the areas of your SharePoint 2010 environment that you should
document.

MCT USE ONLY. STUDENT USE PROHIBITED
1-32 Designing a Microsoft® SharePoint® 2010 Infrastructure

Why Document Your SharePoint 2010 Environment?

Key Points
Your documentation has several uses and you must direct it to a range of
consumers. This means that you will have several layers of documentation that
build on each other to describe overarching business requirements through to
individual process documents. No single group consumes all of the
documentation, but all of it will be used during the life of your deployment.
Stakeholders and Business Users
The information that you gather defines the business requirements for your design.
It is essential that your business stakeholders, and possibly information workers,
ratify this information. This means that you must make your documentation
consumable by both of these groups, organizing their interviews or responses into
a structured format. Stakeholders and other potentially nontechnical personnel
must be able to view the documentation to map their goals in your solution. The
documentation that you create acts as both a validation tool for sign-off by
stakeholders, and a change control trigger. Of course, the documentation is also
the blueprint for development, deployment, and maintenance.
MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Logical Architecture 1-33
Solution Architects
Solution architects use the logical architecture design to plan a solution. The
logical architecture design underpins all of the work that comes later in the
solution design. You must ensure that you have thorough documentation to enable
them to map the physical architecture in later design processes.
System Administrators
System administrators use your documentation—particularly the physical design
documentation—to build and configure systems so that they meet functional and
nonfunctional business requirements.
Developers

Beyond the base architectural design, developers will use these tables and
diagrams to identify functional components of any customized design. For each
custom component, there will be more detailed analysis and design, but the logical
architecture design represents the environment in which any customization exists.
Living Documentation
One of the benefits of delivering published documentation from the outset of your
project is the ability to manage change. It is naïve to imagine that you, or the
business users, can create an initial set of documentation that gets everything right.
This means that your documentation is a living entity, which you must keep
updated. It may seem that this point is labored, but the single biggest weakness of
most documentation is that it is seldom current.
You must establish documentation change management tasks so that you can be
sure that your final documentation matches the business requirements. For major
changes and additions, this should include validation by business stakeholders. It
can sometimes prove difficult to get the time with sponsors to revalidate
documentation. As part of your ongoing project management meetings, you should
have a standing item to review change requests and sign off amendments and
additions. Use this as the initial task of any project meeting, and it will become a
recognized and valued part of the project.
Current documentation is important because you can then update amendments
and insert new functionality into your design. Note that it is difficult to amend
accurately long or complex textual documentation in the form of reports. You are
more likely to have inconsistencies in a 100-page document than you are in a table
or diagram of one or two pages. It is also much easier to review concise
documentation.
MCT USE ONLY. STUDENT USE PROHIBITED
1-34 Designing a Microsoft® SharePoint® 2010 Infrastructure
Your documentation, and particularly nonfunctional requirements, will become
the blueprint for administration and support. Elements such as performance,
capacity, and security requirements fashion the maintenance and monitoring

schedules that you will establish for your deployment.

MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Logical Architecture 1-35
What to Document in Your SharePoint 2010 Environment

Key Points
Information-gathering processes for documentation run broadly in parallel—you
will gather information that affects your logical architecture, physical architecture,
security, and business applications simultaneously. There is seldom a chance to
run a series of information-gathering sessions for each element of the design. The
logical architecture design is the most important because it is the one that is more
abstracted from the SharePoint 2010 technologies. If the logical design is incorrect,
the implementation will not service the business requirements.
Your documentation must include the following elements:
• Logical architecture design
• Service application architecture design
• Physical design
• Security and authentication design
• Metadata design
• Application design:
MCT USE ONLY. STUDENT USE PROHIBITED
1-36 Designing a Microsoft® SharePoint® 2010 Infrastructure
• Search
• BI
• Content management
• Operations and maintenance
• Business continuity



MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Logical Architecture 1-37
Lesson 4
Documenting the Logical Architecture

Now that you know why and what you should document, the next requirement is
to identify an effective way to create documentation. It is common for
documentation to be long and potentially unwieldy, but this makes information
difficult to locate. You should focus your efforts on creating documentation that
contains all of the relevant information, but remains easy to use.
There are many documentation methodologies, some of which your organization
may use or even prescribe. In this case, you should adhere to corporate
governance. If you do not have such guidance, this lesson provides some effective
documentation options for tabular and diagrammatic documentation.
Objectives
After completing this lesson, you will be able to:
• Describe the process of mapping business requirements to logical architecture.
• Describe the Logical Architecture Planning Worksheet.

MCT USE ONLY. STUDENT USE PROHIBITED
1-38 Designing a Microsoft® SharePoint® 2010 Infrastructure
• Describe how to categorize business requirements.
• Transpose categorized business requirements to the Logical Architecture
Planning Worksheet.
• Describe why you should use diagrammatic documentation.


MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Logical Architecture 1-39
Mapping Business Requirements to Logical Architecture

Requirements

Key Points
Information from a range of sources and in a range of formats arrives for you, as a
solution architect, to document and analyze. It is essential to reformat these to a
consistent model that the business users can validate. The categorization of
requirements should group logical components together so that individuals in the
organization can recognize an end-to-end business flow, which they can then sign
off. Business users often fail to see the importance of this stage because they may
feel that you are telling them what they already know. However, it is essential for
you to ensure that you have a complete picture of the business and the
functionality required for a successful SharePoint 2010 deployment.
Remember that, as part of this process, you can have a more objective view of the
business and may be able to identify potential benefits that you can deploy across
the organization.