MCT USE ONLY. STUDENT USE PROHIBITED 1-10 Designing a Microsoft® SharePoint® 2010 Infrastructure Avoiding Technology-Based Design You should not focus your logical design on a given technology. Even if you are designing a SharePoint 2010 solution, you may find that there are business-critical components that require additional solutions or integration. Failure to identify these may lead to a solution that does not meet business requirements. You should identify requirements that may be out-of-scope for this particular project. SharePoint 2010 has a range of great technical capabilities, but you should ensure that your solution is based on business requirements, not solution features. The SharePoint 2010 features may deliver the functionality that solves a business requirement, but your design must always put the requirement before the feature. Avoiding Leading Questions When you prepare your questions, do not make them match your preferred solution, otherwise there is an increased chance that you will miss a requirement that does not fit with your predefined solution. Updating Documentation Design documentation is a set of living documents. As changes occur, you must return and update plans so that you have an ongoing business and technical description of the project. If you fail to do so, the documentation may become a description of the initial design, which you cannot use for sign-off or rebuilds. Additional Reading For more information about SharePoint 2010 licensing, see http://go.microsoft.com/fwlink/?LinkID=200849&clcid=0x409. MCT USE ONLY. STUDENT USE PROHIBITED Designing a Logical Architecture 1-11 Approaches to Requirements Gathering Key Points When you need to find out about business requirements, you must ask managers and staff who work in the business. This may seem obvious, but sometimes computer analysts identify the technical solution and then force the business to fit. Methods of Information Gathering Common approaches to information gathering include: • Sponsor and stakeholder interviews. You must engage with business sponsors and stakeholders. These people have the overarching vision for the business and the solution that they require. Business sponsors and stakeholders often have budgetary control of the project. Questions may include: • What is the business vision for the organization? • What is the budget for the project? • Focus groups. It is often more effective to gather teams together in focus groups to discuss business requirements. You should work with your sponsor and MCT USE ONLY. STUDENT USE PROHIBITED 1-12 Designing a Microsoft® SharePoint® 2010 Infrastructure senior stakeholders to identify the composition of the groups so that you do not get a skewed perception of the business. Questions may include: • What key technology functions are required for your business division? • What benefits do you want to realize from a SharePoint 2010 deployment? • User interviews. With the help of the business stakeholders, identify key users in the organization. These individuals will often have in-depth knowledge of business processes, and may have a big influence in decision-making. Questions may include: • What are the key activities of your department and what functionality do you need to execute these functions? • What are the major productivity issues facing your department that may be resolved through new technologies? • User questionnaires. These can provide an effective means of quantitative information gathering. A questionnaire should be well-structured, enabling you to gather key information for trend analysis. For example, social computing is an end-user solution. It is essential that you understand what the end users expect from any social computing solution. Questionnaires often consist of several closed questions and a few open-ended questions, which may include: • Do you need to use social computing functionality for your work? • What benefits will this offer? • Existing business processes. If there are existing business processes that your solution must supersede or complement, you must review these. From a technical viewpoint, you may need to integrate solutions, but you should first understand the function of any existing systems or processes and how users value them. You should not question existing business processes directly, but you should analyze them to identify elements such as: • Can we re-create or extend this functionality in SharePoint 2010? • What degree of customization is necessary to re-create this functionality and what will be the cost in resources? Rules of Engagement When you organize any business requirements–gathering sessions, you must create rules of engagement. It is particularly important that you establish time constraints. You should generally limit meetings to one hour, although this is MCT USE ONLY. STUDENT USE PROHIBITED Designing a Logical Architecture 1-13 clearly a discretionary figure. Some meetings may require more time, particularly for larger teams or focus groups. The one-hour duration is based on the fact that most people are most attentive in the first 40 minutes of a meeting. If possible, you should get the core business completed during this time and use the final 20 minutes to confirm decisions. You can nominate a mediator to lead the sessions and a note-taker to take detailed notes. All meetings should have an agenda with clearly defined goals of what you want to achieve from the meeting. Without an agenda, meetings may lack focus, and some users may direct discussions to a personal agenda. When users raise topics that are outside the scope of the meeting, you must point out that such topics are extraneous and agree to address them in a separate meeting if necessary. Types of Information The options of qualitative versus quantitative analysis can be important, and both approaches are useful in gathering business requirements. Qualitative analysis takes information from a smaller but better informed group, whereas quantitative analysis draws information from a larger group. The key stakeholders and business managers represent qualitative information because they should have the greater overview of business goals. However, quantitative analysis, which is often in the form of questionnaires or larger focus groups, can highlight business processes that are unknown or unimportant to the business management team. Review existing business processes to ensure that you understand how the business works. Reviewing Documentation Always capture minutes of the meetings and allot time for attendees to review, validate, and sign off your analysis. Make sure that your documentation reflects business language, rather than transposing business requirements into computer jargon. Question: Describe any difficulties you have encountered in gathering user requirement information. MCT USE ONLY. STUDENT USE PROHIBITED 1-14 Designing a Microsoft® SharePoint® 2010 Infrastructure Functional Planning Key Points Functional planning identifies the functions or business actions that you must build into your design. You should define various levels of functionality in your information gathering. These vary depending on the audience that you interview. More senior business leaders tend to highlight overarching functionality, such as usability and increased productivity, which may appear conceptual and vaguely defined. However, your design will be measured by these factors, so you must ensure that you establish metrics by which these may be measured. For example, you can measure productivity by the speed with which a user can perform a task. If there is an existing productivity baseline, you must exceed it. It is useful to find the existing baseline because proving an increase in productivity without this may prove very difficult. Information workers are often more precise in their functional requirements. You must document these functional requirements thoroughly because they may ultimately provide the best proof of overall productivity improvements. You must remember that there is a difference between function and features. The former represents a business requirement, whereas the latter describes an MCT USE ONLY. STUDENT USE PROHIBITED Designing a Logical Architecture 1-15 application or platform capability. Features must meet functional requirements, but individual features may be unnecessary for a business solution. There is a range of common functional requirements, but the most important is the need to perform business processes: • You must map common functionality directly to business processes. The solution must be able to perform a task or achieve a goal. As part of your information gathering, you must list the key business processes that your SharePoint 2010 solution must complete. Ensure that you understand not only the task, but also the scope of the task. For example, there may be a requirement to tag documents consistently across an entire organization. Alternatively, tags may need to be unique in divisions. You may have to deploy a corporate information architecture taxonomy that is augmented by divisionally specific taxonomies. • The administration of departmental or project Web sites may be a core requirement. This can affect options such as site permissions or self-service site creation, for example. • Authentication and authorization are always important in design. You must ensure that security is robust, as corporate governance specifies, but complex layers of security must not impede the individual functions and tasks. • Many organizations require IT solutions to conform to regulatory or statutory audit rules. This may extend beyond the bounds of user applications to include the application platform itself. Make sure that you understand the levels of audit and reporting requirements for regulatory compliance, so that you can apply appropriate policies in SharePoint 2010 for ongoing data management. • Most corporate environments have complex integration requirements, which involve data being generated or collated in one system and visualized or analyzed in others. Your design must identify the potential interaction between systems, including authentication options. • You should also identify any reporting requirements for divisions in your organization. This may be an important element of BI, which may not be a term that anyone in the business uses. You must be aware of the SharePoint 2010 functionality and how it maps to the business language that you gather. There are elements of functional and nonfunctional planning that can merge, such as authentication versus security. It is important not to be overly concerned about whether a requirement falls into either category; if the business requires a capability, you should document it and include it to influence your design. MCT USE ONLY. STUDENT USE PROHIBITED 1-16 Designing a Microsoft® SharePoint® 2010 Infrastructure Question: List some functional requirements that you can identify in your organization. MCT USE ONLY. STUDENT USE PROHIBITED Designing a Logical Architecture 1-17 Planning for Nonfunctional Requirements Key Points It is more common for business users to emphasize functional rather than nonfunctional elements, but failure to include the latter can have a catastrophic effect on your final solution. Although users and stakeholders assume that a system will always be available, you must plan for maximizing availability or performance. In your logical design, elements such as scalability, performance, and security may have a major impact on whether you deploy a single farm or multiple farms for an organization. The most common nonfunctional requirements focus on system capability, availability, performance, and so on. These may have a greater impact on physical design, but you usually only have one period of requirements gathering, so you must make sure that you get all of the information that you require. Key areas of nonfunctional planning include: • Performance. Ensure that your design identifies performance issues such as the number of users who access the environment at peak times. MCT USE ONLY. STUDENT USE PROHIBITED 1-18 Designing a Microsoft® SharePoint® 2010 Infrastructure • Capacity. Your design must provide sufficient capacity over an effective hardware management period, which is normally two years. This means that you have to specify systems that provide adequate storage for this period. In addition to the base systems, you must analyze the goals of the business to enable capacity for forecast growth. You must also be conversant with requirements that are specific to SharePoint, such as software boundaries, to ensure that data volumes do not exceed your logical architecture. For capacity planning for SQL Server, you may want to enlist expertise from a database administrator. • Scalability. Your design must ensure potential for growth through scalability. This may involve scaling up, by upgrading the initial systems, or scaling out, with the addition of systems to share workloads. Your logical design should also provide options for extensibility through scaling. It is rare for an environment as rich and varied as the environment that SharePoint 2010 offers to remain static. You will often find that you must add or extend functionality such as social computing, BI, or Search in an organization. • Availability. Users assume that systems will always be available for them to use, so you have to build this resilience into your plan. No system can guarantee 100 percent availability, so any service-level agreement (SLA) should establish the percentage of downtime that is acceptable for business continuity. This relates closely to availability solutions such as database clustering and network load balancing. However, your logical design must ensure adequate availability through the division of logical components across Web applications. • Security. Security is an overarching goal, so your design may have to integrate with organization-wide standards. Secure authentication may also affect your logical design. You must ensure that you accommodate secure authentication requirements by identifying the division of site collections and sites. • Manageability. If your deployment requires self-service provisioning, you must ensure that both administrative staff and delegated users can manage your solution. • Interoperability. SharePoint 2010 provides a user environment that can visualize external data sources, for example, through out-of-the-box Web Parts. Your design must accommodate these requirements. • Business continuity. As an extension to availability, you must address business continuity, or disaster recovery, options. This is often an organization-wide strategy, but you should review the SharePoint 2010 requirements. MCT USE ONLY. STUDENT USE PROHIBITED Designing a Logical Architecture 1-19 There is no default priority for these nonfunctional requirements. You must prioritize each one based on the business requirements of your organization. When you have established the requirements for each one, review your results with the key stakeholders to establish the priority. . aware of the SharePoint 2 010 functionality and how it maps to the business language that you gather. There are elements of functional and nonfunctional planning that can merge, such as authentication. but failure to include the latter can have a catastrophic effect on your final solution. Although users and stakeholders assume that a system will always be available, you must plan for maximizing. PROHIBITED 1- 10 Designing a Microsoft SharePoint 2 010 Infrastructure Avoiding Technology-Based Design You should not focus your logical design on a given technology. Even if you are designing a SharePoint