Ideal World

Picture this: Your performance group VP is creating a new program for your top field producers. She has created a series of client letters and presentations that will be used in the new program. But first they need to pass through legal, compliance, sales, and marketing. The first set of documents is e-mailed to legal, and the chase is on. With conflicting priorities, vacation schedules, and personnel changes, the process gets hopelessly bogged, and soon we have no idea where the definitive, corrected documents are. What we need is an easy-to-implement collaborative workspace that provides for check in, check out, tracking, and a notification process. OK, now dont accuse me of being a paid shill, because Im not, but Microsoft does provide an out-of-the-box solution for this problem using its SharePoint technologies. The latest version of SharePoint (2003) and the Office 2003 product line extends the desktop across the enterprise and provides some pretty slick collaboration tools. Lets take a quick look at them.

SharePoint: What Is it?
The Microsoft collaborative technologies collectively known as SharePoint are offered in two products: Windows SharePoint Services (WSS) and Share-Point Portal Server. Windows Share-Point Services actually are part of the Windows Server 2003 operating system and are installed as an add-on. Share-Point Portal Server 2003 is a separate product used to build portal sites on top of the WSS framework.

Windows SharePoint Services are configured on the Windows Server 2003 operating system. The OS first is set up as an application server by enabling Internet Information Server (IIS) 6.0 and ASP.NET, which, in turn, relies on the Microsoft .NET framework. If you are familiar with Windows 2003 Server, you already know almost everything is disabled or locked down out of the box. Getting the box ready for WSS is easyjust remember not to enable Front Page server extensions. SharePoint installs its own special server extensions and will not work if Front Page extensions are running.

SharePoint stores all data in a SQL database. Current requirements are SQL server 2000 with Service Pack 3 or the MSDE (Microsoft SQL Server 2000 Desktop Engine; MSDE 2000 is the free, redistributable version of SQL). The WSS predecessor, SharePoint Team Services (STS), used a file-based storage system, and thus it suffered from serious scalability issues. (STS had other major drawbacks, including a proprietary ISAPI extension instead of being built on the now-standard .NET framework.) The database requirements are interesting: Two SQL server databases are requireda configuration database and a content database.

Configuration and Content Database

The configuration database contains all deployment information for a specific physical instance of a Web server-WSS Web site-virtual Web site instance. This is a little unnerving at first. One is accustomed to using IIS manager to create or examine virtual Web sites and thus determine the actual physical location of the files (in this case, we usually are talking about .htmx files).
Virtual and real Web site configurations traditionally have been stored in the IIS metabase. This has made it difficult to back up, store, or replicate complex Web sites easily. Now, we have WSS storing the configuration data in a SQL server database. This presumably makes for easier maintenance as far as backing up and restoring data (and thus metadata). But it also makes for some real consternation. Dont expect to find your WSS virtual sites in the IIS manager.

Most users will find they need a mix of real as well as virtual Web sitessome of which are configured via WSS and stored in SQL, and some of which are configured via IIS Manager and stored in the new Windows Server 2003 XML metabase. In addition to the configuration database, WSS requires a content database. WSS makes it easy to configure SQL. All you really need is to configure a default database for SharePoint and provide log-on and database information to WSS, which handles all other configuration.

Scalable?

Windows SharePoint Services is highly scalable. A small organization can be up and running quickly and efficiently on a single box. It even can be done relatively inexpensively using the MSDE (although there are limitations imposed on an MSDE configuration). Scalability can be handled many ways. If the primary use and means of access for your WSS site is via Web clients, then a server farm can handle and load balance all incoming traffic. If your system is using Microsoft Office to read and write large numbers of documents (that must be cycled in and out of the database), then you may need only a single Web server handling a SQL server farm (which requires Enterprise edition SQL server 2000). The accompanying diagram shows a typical WSS configuration.

Now What?

OK, you now have Windows SharePoint Services running and configured on a Windows Server 2003. What do you have that you didnt have before?

First, you have the ability to create and manage administratively shared WSS sites. You notice I said administratively. That means business users have the ability to create and work within collaborative workspaces. Shared document libraries, calendars, and lists are available. All core functionality of WSS is integrated with Microsoft Office 2003. Let me provide a few examples. I use Outlook 2003 and have SharePoint technologies running on a Win2K3 server in a domain of which I am a member. If I use Outlook to send an e-mail with an attachment, I am asked whether I really want to send the attachment or whether I would rather upload the attachment to the SharePoint Server and just send the virtual link to the attachment. Now, of course, we already can do this after a fashionwe can upload a file to a shared folder, then send an e-mail telling folks the file is out there. I find I really dont use this process very often. It is too easy just to send an e-mail with the attachment. Plus, we lose all the other benefits of SharePoint.

If I let WSS handle the document, my recipients receive an e-mail with a click-through link to a shared workspace where they have many options. They can view the document, or they can check out the document (to ensure no one else can modify the document while it is checked out). WSS also provides the ability to set alerts. An alert tells me if a document has been modified, changed, checked out, checked in, whatever. Versioning also is controlleddocument changes are tracked and assigned different version numbers for auditing and rollback. Doesnt this provide a really nice way to track a document through the system (like those documents for the performance group we were talking about earlier)?

I currently am composing this article at home using MS Word 2003. I also am using VPN to connect to my SharePoint domain at the office. In the MSOffice task pane, the shared workspace pane is enabled. I have the ability through MSOffice to interact directly with SharePoint. I can see who else is logged in, I can save documents to a shared workspace, I can create a shared workspace, and I can fetch documents from a shared workspace. The possibilities are intriguing and endless.
We have become accustomed to working in islands of information, whether those islands are locally shared network folders or My Computer. Information islands are not efficient. We need to learn new ways to work collaboratively, and out of the new ways will come increased efficiency.

If my editor were plugged into the SharePoint world, she could preview my article in a few minutes (after she received an alert, it would be ready for her review). Suggested changes could be made in the collaborative environment, and then I would be notified of those changes. In our current system, someone will walk into my office and hand me a hard copy of this article fully flowed onto the printed page. Ideally, a PDF would be dumped into SharePoint, and I would do my final proof on that document. Seem like a lot of sound and fury signifying nothing? I dont think so. We all are so busy even small efficiencies will result in more useful work being accomplished. Not only that, but attachments frequently are lost or stripped by e-mail filters.

All of this functionality is delivered on a platform based on standard .NET technology with a fully exposed object model API for SharePoint, a series of predefined templates for user customization, and Web Parts, a new paradigm. Web Parts are reusable plug-and-play modules that literally can be dropped into a Web-Part- ready Web page from the WSS site library. Web Parts contain all the functionality necessary to perform all provided WSS functionality (like shared document libraries, rich text or html editing, list creation, etc.). What makes Web Parts even more exciting is they can be built using .NET to provide any desired functionality that isnt available in the base WSS.

I have barely had enough space to cover the major functionalities provided by WSS, and I havent even discussed SharePoint Portal Server.

It doesnt matter whether you run a Microsoft Office shop or are using open-license productivity software. There is a clear need for collaborative work environments similar to those provided by Microsoft with its SharePoint products. Whether it is SharePoint or another solution, we all will be playing in this ballpark soon. With SharePoint Services, it appears Microsoft perhaps has earned the right to hijack the expression: The network is the computer.