It is vital that the project team has a full understanding of what is in place, what the pain points are for the end users, what end user requirements are related to SharePoint, what nee
Trang 1126. Chapter 6 Gathering the Resources for SharePoint Implementation
• An installation guide that uses all of the preceding documents to install SharePoint
2010 according to the topology defined in the first document listed It should also cover the actual steps from start to finish; from basic server SharePoint 2010 installa-tion through site collecinstalla-tion and service applicainstalla-tion configurainstalla-tion
• Testing documents to verify and validate the installation completed These seven documents are also used in the creation of the SharePoint 2010 Requirements and System Specification document
Chapter.12.provides.more.information.on.this.topic
Summary
The key success factor for recording the resource data for SharePoint 2010 is to standardize the approach Resource gathering for SharePoint 2010 starts in the Plan phase of the imple-mentation project Configuration management also comes into play during the Plan phase and allows you to standardize how data is gathered
As discussed in this chapter, the problem is not just building the resources; it is making sure those resources are defined, prioritized, and scheduled correctly Therefore, this chapter provided a task list that states the jobs required to gather the requirements and indicates who the key people are who need to be responsible for doing that As each of the Work Breakdown Structure (WBS) tasks are collated, the relevant project managers and leads need to sign off on them
When you have completed defining the vision statement and the success criteria, only then can you assemble your project teams To gather your technical requirements, you need your project teams To design the environment, you need to know what hardware and software
is available, what the licenses look like, and so on It’s vital, therefore, that you get a handle
on this so that your project goes smoothly and you meet all the project requirements Each
of these tasks can and should be signed off on as completed and all should have reviews There will be many instances where the requirements of the client cannot be fulfilled on day one of SharePoint 2010 being released to the client This can happen for any number of reasons: budget, timeframe, lack of resources, and so on Configuration management pro-vides procedures to use to ensure that the client is aware of what to expect from the final product These procedures capture information about the project history: how the product was created, what data was made available from the end users, how it was tested, and so
on It’s a key facet of the SharePoint 2010 Quality Plan
Trang 2Summary 127
of business and technical data—any additions, alterations, or deletions of that data needs
to be controlled
In this chapter, I described the importance of SharePoint 2010 planning and the tasks that need
to be done It is vital that the project team has a full understanding of what is in place, what the pain points are for the end users, what end user requirements are related to SharePoint, what
needs to be done, and what resources need to be sought to deploy SharePoint 2010 (which is
the next phase) This means gathering and building resources, both business and technical
I also described where best to get online information (by using resources such as TechNet
and Microsoft sites) However, what is clear is that you need the skilled human resources
(critically, the SharePoint architect and business analyst) to ensure data has been gathered
correctly and relates to SharePoint 2010
What follows is the Deploy phase This is discussed further in Chapter 14, “Releasing
Share-Point to the Client ” Before that, we need to concern ourselves with more areas related to
planning: customization, governance, configuration management, user requirements,
sys-tem specification, and making sure there is somewhere to store planned data
More.information.on.this.topic.can.be.found.in.Chapter.11,.“Making.Sure.SharePoint.Meets.
User.Requirements ”
Trang 4Chapter 7
The Business of SharePoint Architecture
Describing.SharePoint.Business.Architecture . 129
Hardware.Architecture 130
Software.Architecture . 131
Information.Architecture 132
Further.Reading . 134
Summary . 134
Describing.SharePoint.Business.Architecture
Probably, the most understood meaning is “the art of constructing structures such
as homes and buildings ” The architect designs the blueprints of the home or build-ing, taking into account factors such as design, space, light, materials, stability, load, and future needs
Architecture is important because it accounts for the functional and nonfunctional require-ments early on Microsoft Office SharePoint Products and Technologies are powerful tools that increase collaboration and sharing of content If implemented correctly, SharePoint can store and serve a vast quantity of information very well However, without proper archi-tecture and governance, a SharePoint deployment can become a disorganized collection of sites, links, users, and documents that hamper productivity, which makes it harder to find information
Good architecture and governance plans (discussed in Chapter 9, “SharePoint Governance”) lay down guidelines for deploying SharePoint as a solution to common business challenges The architecture of SharePoint includes:
• Designing and allocating the hardware infrastructure needed to support the site
• Listing out the sites and site hierarchies that will serve the needs of the business
• Establishing users and roles that will be given permissions to the sites
• Establishing the relationships between sites
• Planning for the needed site features, site customizations, and site and list relation-ships (which include how data will be rolled up and aggregated from sites and lists to provide an overview of information)
Trang 5130. Chapter 7 The Business of SharePoint Architecture
A good governance plan outlines the administration, maintenance, and support of the SharePoint environment The governance strategy seeks to ensure that SharePoint is used
in accordance with the designed goal and that the best practices are followed to keep the portal manageable and usable Best practices include processes for operation in the portal for tasks such as creating sites and lists, assigning permissions to users, using consistent naming conventions, and generally enforcing the guidelines
Information.architecture,.which.is.discussed.in.Chapter.9,.provides.an.important.input.to SharePoint.governance
When creating a building, architectural concerns include data gathering, planning, and the design of that building The SharePoint architect must design the SharePoint building to
withstand the test of time (meaning the architect must future-proof the implementation by
building in robustness and resiliency) and, based on future client requirements, be able to expand easily (in other words, scalability with an eye on future upgradeability of SharePoint installation based on factors such as business need, hardware, software resources, and so on) For SharePoint, there are three levels of architecture: hardware, software, and information
Hardware.Architecture
To deliver a robust SharePoint 2010 environment, it is necessary to carry out technical design, which looks at all areas of SharePoint 2010 concerning the equipment it will run on
or be connected to and systems and processes it will interface with The following is a list of planning requirements:
• System requirements Determining what is required to deploy SharePoint 2010 You.can.read.more.about.the.minimum.hardware.and.software.requirements.for.
installing.and.running.SharePoint.Server.2010.at.http://technet.microsoft.com/en-us/
library/cc262485.aspx To.read.more.about.deploying.SharePoint.Foundation.2010,.go.
to.http://technet.microsoft.com/en-us/library/cc287737.aspx
• Services architecture Determine what service applications are defined and how
they are structured For further discussion, see the sections titled, “Concept” and
“Topology” in Chapter 12, “Producing the SharePoint Specification ”
• Logical architecture Presents the design in terms of isolation This planning task
Trang 6Software Architecture 131
• authentication Examines authentication methods, such as claims-based
authenti-cation topologies
• Server hardening This task focuses on server snapshots, ports, protocols, and the
Web Server, Application Server, and Database Server roles
• Business continuity Examines the business decisions, processes, and tools put
in place to handle a crisis A crisis can affect the organization or be part of a local, regional, or national event Business continuity and disaster recovery are huge areas
in SharePoint and planning for them is an important part of ensuring a resilient and robust platform
Find.out.how.to.apply.business.continuity.to.SharePoint.at.http://sharepointbcp
.geoffevelyn.com.and.how.to.apply.disaster.recovery.planning.to.SharePoint.at.
http://sharepointdr.geoffevelyn.com
• performance and capacity Determines the process of mapping the design for
SharePoint 2010 to a farm size and the hardware needed to support the business goals
Performance.and.capacity.are.discussed.further.in.the.section.“Performance.Require-ments,”.on.page.199,.in.Chapter.12
• Virtualization SharePoint 2010 is fully supported when deployed in a Windows
Server 2008 Hyper-V environment This task examines the licensing and topology This topic is further explained in Chapter 8, “SharePoint Customization ”
Software.Architecture
The software architecture of SharePoint is the structure or structures of the system, which
comprise software elements, the externally visible properties of those elements, and the
relationships among them So decisions to be made include determining what components
of SharePoint are needed, what will be visible, and the structure of SharePoint For example,
is SharePoint going to be treated as an out-of-the-box solution, slightly modified with inter-nal applications, or will it include third-party additions? Will it simply need just team site
components (for example, the free SharePoint Foundation version), or do you need more
service application, enterprise content management, or metadata features, such as those
provided through SharePoint 2010 Enterprise?
Software architecture examines SharePoint from a site and solution planning perspective,
taking into consideration site components, security, governance, enterprise content
man-agement, Web content manman-agement, managed metadata, business intelligence, data and
processes, access services, quota management, and social computing
Trang 7132. Chapter 7 The Business of SharePoint Architecture
As an example, suppose that you’re going to implement SharePoint in an organization that already has SharePoint but needs to expand They have a third-party tool providing some functionality that the client finds useful From scoping the information architecture, you found how much usage it gets, how the data is used, how it flows, and so on From further investigation of the software architecture, you find that the relevant tool cannot grow with the service This means revisiting the functionality in terms of the information architecture and finding an alternative, which then drives the software architecture
Information.Architecture
Information architecture involves studying the type and amount of information used within
an organization, organizational structure, information flow, process flow, and more This is
an extremely important aspect of the Plan phase Without it, SharePoint is not defined to meet the client requirements, because information architecture leads to SharePoint user strategy in terms of content management Identifying the organizational information and management information goals combines the work of information analysts and business analysts, coordinated by the project manager and feeding back to the SharePoint architect Large organizations have documentation plans and methods of managing their data across the organization (for example, retention plans and archive plans), and some use informa-tion analysts to manage, coordinate, and categorize how members in the organizainforma-tion deal with information Additionally, organizations face legal and regulatory compliance requirements that directly influence how data is retained long term In the United States, for example, the Sarbanes-Oxley (SOX) Act established record-retention rules in July 2002 It
is highly recommended that companies have a records-retention policy that complies with regional and national laws
Note
If.you.keep.too.much.data.and.are.sued,.the.plaintiffs.have.the.right.to.go.through.all data.retained However,.if.you.have.a.policy.that.adheres.to.both.regional.and.national retention.policies.under.SOX,.you.are.only.liable.to.retain.the.information.within.those guidelines,.and.that.information.is.all.that.can.be.used.in.a.lawsuit
Another benefit of a good records-retention policy is a decrease in storage costs The infor-mation analyst details from the ground level the organizational data concerning informa-tion standards and policies set out by the business (The informainforma-tion analyst is described
in Chapter 5, “Building Your SharePoint 2010 Team ”) Information architecture establishes
Trang 8Information Architecture 133
SharePoint 2010 provides enterprise content management tools that can help lower costs
associated with the control and storage of information, decrease complexity, and increase
user participation relating to content control Combining SharePoint 2010 with Office 2010
takes information management to a higher level by extending information control from the desktop environment to SharePoint 2010 sites and content
The aim of information architecture in SharePoint is to reduce the manual end user actions
related to metadata, to scale policies and processes across all types of content in an
orga-nization, and to increase compliance and transparency To meet this goal, there must be
an examination leading to the creation of an organizational taxonomy During the design
phase of the SharePoint project, the information analyst (working with the SharePoint archi-tect) creates an organization taxonomy by examining metadata and information policies
The business analyst can provide, through the collection of user requirements, an
under-standing of what the typical content life cycle is in the business This shows how end user
content becomes managed content Typically, managed content begins its life as temporary information created by the individuals in the organization, leading to work in progress (and this means multiple individuals working on the same content) and in the backdrop of reten-tion and disposireten-tion (business teams or individuals deciding on whether documents should
be archived and what their state is, either approved, published, or other) SharePoint 2010
provides tools to ensure the content life cycle can be designed and adhered to Enterprise
content types, document sets, information management policies, metadata, term sets,
and content organizers can be established using SharePoint 2010 document management
features
How.Is.Information.Architecture.Defined?
Here are some basic steps for setting the information architecture for SharePoint 2010:
• Carry out an investigation and inventory of existing content
• Classify the content by performing the following tasks:
❍
❍ Look for definitions of structure, policy, and defaults
❍
❍ Identify organizational-level content by enterprise, department, and team
❍
❍ Define what “general use” content is
• Organize content into enterprise content types and document sets, keeping the fol-lowing factors in mind:
❍
❍ Content types contain definitions of structure, policy, and defaults
❍
❍ Content types can inherit from other content types
❍
❍ Document sets exist when work spans multiple documents
Trang 9134. Chapter 7 The Business of SharePoint Architecture
• Decide where information management policies apply When doing this, be sure to consider access permissions, auditing, user restrictions (for example, no printing), retention, and deletion
• Decide on applicable metadata by performing the following tasks:
❍
❍ Define customized columns, and associate them with documents and lists
❍
❍ Define any cases where the system or user might take different actions based
on the characteristics of an item Note that the characteristics of the item are metadata
❍
❍ Find out what common things users will want to sort or filter items on
❍
❍ Find out what words or phrases users are likely to tag items with
❍
❍ Use Choice or Lookup columns in SharePoint 2010 sites
❍
❍ Use the existing taxonomy if the organization has one
• Map the physical flow of the document, including the sites, lists, and libraries where the content will be physically located throughout the document’s life cycle
Further.Reading
SharePoint 2010 architecture is a massive topic, and this chapter covers the basics of three areas I suggest you pursue further understanding of this topic because to address it will result in a successful SharePoint 2010 platform
You.can.read.more.information.about.information.architecture.in.a.governance.overview.on.
TechNet.at.http://technet.microsoft.com/en-us/library/cc263356.aspx You.can.also.find.a.gen-eral.perspective.on.planning.and.architecture.at.http://technet.microsoft.com/en-us/library/
cc261834.aspx
Summary
This chapter described the three types of SharePoint 2010 architecture as applied to the implementation of SharePoint in an organization: information, software, and hardware
Information architecture is known as SharePoint business architecture because it is the
Trang 10Summary 135
Once information architecture requirements are agreed upon, the project team can focus
on ensuring the technical components required to meet user requirements and flow are
mapped to the SharePoint 2010 Requirements and System Specification document The
content of this document comes from an examination of hardware and software (for
exam-ple, hardware and software architecture) The SharePoint architect, among others (such
as business analysts and information analysts), works closely with the interfacing team to
detail the three architectural levels
Hardware architecture is a physical topology and a road map indicating the structure of the equipment needed to deliver SharePoint and connectivity to internal and external services,
such as e-mail, user directory services, and external file shares It takes into consideration
performance, resiliency, and security
Software architecture relates not solely to the structure of SharePoint applications It can
include internally developed or externally provided applications or systems to provide
fur-ther functionality not present in the SharePoint 2010 implementation