Analysis and Design Considerations

SharePoint Portal Server can be remarkably easy to install. In fact, if you follow the single-server deployment strategy, you can have SharePoint Portal Server up and running in 30 minutes. However, that does not mean that it is simple to create an effective business solution using SharePoint products and technologies. The key to properly designing a SharePoint solution is to spend the required time to identify the business problem to be solved and the expected result. Once you understand the solution, then you must document the roles, policies, and systems that constitute the solution. Finally, you must design a solution that incorporates all of the elements in a way that solves the original business problem.

Documenting the Business Vision

For as long as I have been involved in designing software solutions, teams have always agreed in principle that identifying the business problem and understanding the return on investment (ROI) were critical to the success of every project. However, I have rarely seen a team actually engage in these activities, and in the end, this often was a leading factor in the failure of a project.

Shortcutting required analysis is a fact of life in the information technology world, and it is driven equally by managers and engineers . On the management side, project sponsors are frequently unable to articulate the expected return from a technology project. When interviewed, managers are incapable of explaining the productivity increases or cost savings that are expected from a technology effort. Instead, they rely on a vague feeling that the mere presence of a tool, or portal, will surely help the organization be better. This is what I'll call the tool-only approach .

On the technical side, most engineers are not trained to look at technology issues as essentially business problems. Instead they look at business issues as primarily technology problems. The typical technical thought process asks the following question: What data does the end user need? Then it asks this: What application provides that data? The solution then is to deploy the application that provides the data and declare the problem solved.

A portal solution based on SharePoint products and technologies is a web of solutions to a myriad of problems. Organizations considering such an implementation would do well to begin by interviewing key project sponsors to document the expected company benefit from such an effort. Sponsors should be clear about the expected productivity increases or cost savings associated with the effort. Use this exercise as a litmus test for the entire project. If a significant return cannot be envisioned for the project, then it may not be worth the effort.

If the return is determined to warrant the project effort, then the correct process is first to create a vision document. The vision document is the first deliverable of the project. This document articulates the business problem, proposed solution, and expected benefit. This document is the highest-level guidance for the project. It acts as the beacon to which the team is headed. In well-run projects, the vision is periodically revisited to ensure that no extraneous effort is expended and that the team is correctly implementing the vision and achieving the desired results.

Documenting Policies and Practices

Once the vision document is completed, the next step is to document the policies and practices that will constrain the use of the solution. Policies and practices act as boundary conditions for the solution. Successful projects exist within these boundaries while solving the original business problem.

Policies are restrictions placed on the organization by its management and articulated as simple statements. For example, the statement "company credit cards are not to be used for personal expenses" is a policy that restricts the use of a company credit card. Similarly, the statement "only port 80 will be open on the firewall" is also a policy. This policy restricts the use and configuration of the company infrastructure. Policies are not easily changed; therefore, a successful project must identify the policies that constrain it.

Practices are similar to policies in that they act as boundary conditions on the solution design. However, practices are more closely associated with the tactical processes used by the organization to do business. For example, the use of an approved vendor list to simplify the purchase process is a practice. Practices are less formal than policies, but they can easily be just as limiting on the final design.

Policies and practices exist at many levels in an organization. Some policies may apply to an entire organization whereas others may be specific to a single process. Initially, you should try to identify the policies and practices that are most likely to constrain the general use of a portal solution. As the portal effort matures, you will identify departmental processes constrained by additional policies and practices. As a starting point, consider the following common areas where policies and practices may affect the initial portal deployment.

Allowing External Access

Determine whether or not personnel will be allowed to access the portal externally. If external access will be allowed, then document the policies for authentication. Determine if a simple user name and password will be sufficient, or whether stronger measures will be required. Specifically, you should determine if Secure Sockets Layer (SSL) and certificates will be required.

Along with system policies, determine if users will be required to access the portal utilizing a two-factor authentication system such as RSA SecurID. SecurID tokens act as virtual ATM cards for the portal. In order to access the portal users must possess the token and know a personal identification number (PIN) number. The passcode generated by the token changes every 60 seconds so a user must be in possession of the token at the time of log-in. The PIN number is a fixed set of numbers known only to the user. The combination of these two elements to complete a log-in request is why it is called two-factor authentication. When combined with SSL and certificates, such access schemes are exceedingly hard to hack.

In addition to considerations about personnel access, you should document policies for system deployments. Determine what parts of the system will be deployed behind the firewall or in a Demilitarized Zone (DMZ). All of these issues arise early in a portal development project and will affect the final design significantly.

Negotiating Service-Level Agreements

Based on the business vision, you should determine the expected uptime for the portal. If the portal is functioning as little more than an intranet, perhaps no significant impact occurs if it goes down. On the other hand, some organizations are utilizing the portal as the primary workspace for employees . In this case, a formal service-level agreement should be negotiated for the system.

Along with a service-level agreement, the portal may have to be part of the disaster recovery/business continuity plan. Again, based on the business vision, determine if the criticality of this system warrants a replicated site on the disaster recovery network. If so, make disaster recovery an integral part of the project plan. We have seen many organizations ignore this point and roll out a portal as "just a pilot." These same organizations turn around a few months later and realize they have a single point of failure in their system architecture and a gaping hole in their disaster recovery plan.

Accessing the Application

Determine the policies and practices you will use to provide application access. As I stated earlier, the Microsoft vision of SharePoint solutions incorporates tight integration with Office 2003. If this is in line with your company vision, then you must evaluate your current Office deployment. Give thought to any planned upgrades and how you will handle installation and maintenance on the client machines.

Because the Microsoft vision requires client-side deployments of Office applications, many organizations are combining SharePoint Portal Server with server-based technologies like Windows Terminal Services. Terminal Services is a technology that allows a Windows desktop running on a centralized server to be viewed and operated on a remote computer. Using this technology, organizations can develop significant cost savings by nearly eliminating all client-side installation and maintenance. These server-side installations are then accessed through the Remote Desktop client. Figure 1-6 shows the Remote Desktop client configured to access a server running a SharePoint portal.

Figure 1-6: Preparing to access Windows Terminal Services

Managing Content

Documents and other content are a significant part of a SharePoint solution. Therefore, organizations must document the policies and practices that determine how the content is created, posted, and managed. Determining the policies and practices surrounding content will have a lot to do with the culture of the organization. In its heart, SharePoint is a distributed solution. This means that it is structured to allow easy content creation and posting. Additionally, sites and subsites can be created without necessarily requiring centralized approval. Many organizations find this philosophy incompatible with the traditional centralized approach to information technology.

Administrators do have significant control over permissions granted to portal users through the use of SharePoint Roles ; however, every organization will have to determine which people will be responsible for creating and maintaining content. This may be a formal system where each department has a content manager, or it may be a freewheeling approach that lets nearly anyone create a site on the fly and populate it with relevant content. In any case, you should consider these issues carefully before you begin designing the portal.

Working with Audiences, Processes, and Web Parts

One of the most-common mistakes organizations make when deploying a SharePoint portal solution is to structure the constituent sites in a hierarchical fashion that mirrors the departmental structure of the organization. In this design, each department is given a site within the solution and users are expected to find what they need within the site associated with their department. The challenge with this approach is that most people do not work in such a narrow concept. Instead, effective companies are most often organized into cross-discipline teams that consist of members from several departments.

Although somewhat limited in SharePoint Portal Server, the concept of audiences is a powerful mechanism for delivering targeted content to people involved in cross-discipline teams. Instead of thinking of people as belonging to a department, classify them by their common needs. A simple example of an audience would be the set of all employees who use company daycare. Obviously this group is independent from any formal organizational hierarchy.

The company departmental hierarchy does have a place in the design of your portal. You can use the departmental structure as a navigation aid for locating the information you need. This is done through the concept of topics . Topics provide different organizational views of the portal and its sites. Thus customer information might be a link located under several different topics in the navigational structure, but it exists only once as a site in the solution. Figure 1-7 shows a set of topics within a SharePoint portal home page.

Figure 1-7: Topics are a navigation aid.

After the audiences are identified, you should consider any processes that will be automated within the portal solution. In some cases, you may be trying primarily to create an informational site with all processing occurring outside of the site. In other cases, organizations may want to use the portal solution as a complete work environment that makes the traditional desktop obsolete. Both visions are viable within a SharePoint solution, but creating a true work environment requires a significant investment in web part development to bring system functionality to the portal.

If your portal solution will be automating a significant number of processes, organize the effort by audience. For each audience, list the processes that will be automated within the portal. Then for each process to be automated, create a flowchart that shows how the process will work within the portal.

Automating processes within the portal requires a different mindset than creating full-blown traditional applications. Remember that the automation will occur through the use of web parts. Because web parts are limited in scope and functionality, you should never try to rewrite an entire application to run as a web part. Instead, think of smaller, limited process functionality that you can easily achieve within the portal. Rewriting the sales force automation system as a web part is a bad idea, but creating a web part to display the top ten pending deals is ideal for a web part.

Ultimately, you need a strategy for delivering applications to portal users. Again, this depends upon your vision of the portal solution. If they see your SharePoint solution as an informational site, end users may continue to receive their applications outside of the portal in the traditional way. If you are trying to create a more complete work environment, you may provide links to applications from within the portal. Finally, it is possible to run whole applications within the portal ” especially if the applications are web based. Web-based applications can be made to consume an entire page of the portal so that complete access to information and systems is available through a single work environment.

Managing Change

During a presentation, a customer once asked me to describe the most difficult issue surrounding a SharePoint deployment. My answer was immediate. I responded, "It's the same issue as every other project ”managing the change for the end users." Change management is the process that helps end users adopt new ways of doing business, and it is never easy. In fact, I would say that change management issues are responsible for more project failures than nearly anything else.

Despite its ability to affect the success of a project, change management is rarely considered in sufficient detail. In my experience, this is because the team is primarily concerned with correctly implementing the technical solution. What's more, technical teams really are not trained to help users through the change management process. Once, I was discussing a portal rollout with an IT director who told me that he was absolutely convinced of the value embodied in our project. His only concern, he said, was how to get the end users to adopt the new environment. Before I could answer him, he muttered under his breath , "I guess we'll just ram it down their throats." Wow!

Successful change management is about educating and assisting end users. Every good portal project must involve some key elements to help end users adapt and be productive. Scheduling end-user training is an obvious first step, but it is rarely enough to ensure success. Instead, consider the entire group of end users and have a complete plan to manage the change.

Begin by mentally dividing the end users into three groups. The first group is the set of people who are excited about the project. This group can be a strong ally in your effort to bring others through the change process. The second group is the set of people who are neutral about the project. This group is waiting to see if the project will be successful before they get behind it. The last group is the set of people who are openly hostile toward the project. This group does not want to change and is typically very vocal about it.

Although the third group is the loudest and cries for the most attention, they should be largely ignored. Instead, I like to start a pilot with the first group. Don't worry about the traditional approach of piloting your project with a particular department. This approach is too narrow and invites people from all three groups into the pilot. This will surely result in someone from group three declaring the project a disaster. Just locate the most enthusiastic people you can ”regardless of department ”and start a pilot.

Piloting with enthusiastic people guarantees good press. This means that the people in the second group ”the ones who are waiting for success ”will begin to hear good things about the project. This will result in more people from the second group becoming enthusiastic and joining the first group. Now you can expand your pilot to include more people. In this way, you can continue to build momentum for the project. This strategy can save you a lot of heartache when rolling out something with as much organizational impact as a portal.