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. . 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 design • Application design: MCT USE ONLY. STUDENT USE PROHIBITED 1- 36 Designing a Microsoft SharePoint 2 010 Infrastructure • Search • BI • Content management • Operations and maintenance. the areas of your SharePoint 2 010 environment that you should document. MCT USE ONLY. STUDENT USE PROHIBITED 1- 32 Designing a Microsoft SharePoint 2 010 Infrastructure Why Document Your SharePoint