Quản lý và thực hiện các dự án Microsoft SharePoint 2010 - p 16 docx

Chapter 6 126 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 collection and service application configuration. • 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. Configuration management covers the management of all assets in the project. The data gathered is the most important asset. SharePoint implementation assets are a combination Chapter 6 Summary 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.” 129 Chapter 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 A rchitecture refers to the art of building. The word “architecture” has many meanings. 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) Chapter 7 130 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 looks at farms, service applications, Web applications, content databases, site collec- tions, sites, zones, MySites, and so on. Chapter 7 Software 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 management, managed metadata, business intelligence, data and processes, access services, quota management, and social computing. Chapter 7 132 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 organization 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 information analyst is described in Chapter 5, “Building Your SharePoint 2010 Team.”) Information architecture establishes information control and compliance policies so that accumulating information is done in a well-managed way and does not create data chaos. Chapter.7 Information 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 disposition (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. Chapter 7 134 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/librar y/ 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 con- tent that drives SharePoint. The data to be captured in this architecture requires investiga- tion, process mapping, metadata (data about data), and categorization. Chapter.7 Summary. 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. . 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. 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. 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