Microsoft Office Group

Microsoft Office Group

In the grassroots of portals, demand comes from knowledge workers or information workers. This is the market served by Microsoft desktop products such as the Office suite. Nearly all activities of such users have a place in the portal. In many instances, Microsoft product literature lumps together portals and intranets, such as in the Microsoft Solution for Intranets (www.microsoft.com/solutions/msi). The target market covers users who need these features:

• Rich tools to create content and documents. Despite the hype around network computing and browser-based applications, the browser is not yet the place where these are created. Instead users still rely on rich, 32-bit Windows programs such as Word, PowerPoint, or Excel for much of their work.

• Interfaces to line-of-business applications, including accounting, customer information, manufacturing, contracting, and more. Many of these interfaces have already moved to the browser, but the portal can provide additional levels of integration and ease of navigation.

• Real-time collaboration. Once they have tasted instant messaging, users are reluctant to give it up. Presence detection is a valuable asset in the corporate portal and is an additional benefit of this technology.

• Content management. Content owners should be able to create and maintain their own web content without the bottleneck of HTML programmers and webmasters. This requires a workflow process for editorial review and approval. The user interface should be either a browser or Office application.

• Messaging and scheduling. Some workers, especially managers, spend the bulk of their time reading and writing email. While browser-based email is widely used and has its advantages, a rich client such as Outlook supports offline use and offers higher performance than email relying on a network connection.

• Virtual communities and collaboration. Teams need virtual locations to store shared documents and work products. These are useful inside an organization but even more critical when a virtual team spans multiple organizations and geographical boundaries.

• Search tools. Information is not truly at your fingertips if you cannot find it. Search tools that can reach all repositories of data, information, and knowledge are required. For instance, users need to search against the intranet, external web sites, Internet search engines, documents, other files (such as metadata on images and video), and messages. Advanced search algorithms to improve the success of searches are desirable, as are agents that periodically update search results and notify knowledge workers.

Figure 3.1 shows a vision of a unified view of information from the user perspective.

Figure 3.1. Unified User View of Information in the Portal

In the final analysis, end users do not and should not care whether these capabilities are part of the operating system, office productivity suite, or server platform or are custom-built. What they seek is a reasonably pleas-ant experience that helps them be more productive. IT managers may not care where these services reside either, although they will care intensely how much they cost and how much effort is required to design, build, integrate, and test them.

Part of Microsoft's portal offering ”in fact, the only Microsoft product with "portal" in its name , SharePoint Portal Server ”has grown from the grassroots level of the Office product development team. Rather than start with an enterprise architecture perspective and craft an overarching portal that would replace all the end-user applications that came before it, Microsoft started from the perspective of the end user in a corporate department, and this is how SharePoint was born.

By the late 1990s, several products were on the market that provided a browser-based view into documents and applications. One of the most popular of these was Plumtree, a product originally developed for the Microsoft platform. A Plumtree portal consists of elements called gadgets that provide access to content such as HTML or applications such as SAP or Siebel. Microsoft took a similar approach with SharePoint Portal Server, calling these portal elements web parts , based on the digital dashboard feature of Outlook that originally appeared in Outlook 97. The digital dashboard grew out of Outlook Today, a combined view showing calendar and schedule items in a single window. It could be extended and customized with dynamic HTML (DHTML).

SharePoint web parts were based on ActiveX and required Internet Explorer. They can be downloaded and placed where desired within the browser window. Developers can create their own web parts as well, and many are available from third parties that provide access to their applications. For instance, you can install a stock ticker or news web part that receives content from MSNBC.

SharePoint provided a quick fix for the lack of a corporate portal in the Microsoft product family. Version 1 of the product combined the search engine that grew from Site Server version 3.0 with the digital dashboard from Outlook (Figure 3.2) and a document repository borrowed from Exchange 2000. As we will see in Chapters 9 and 12, SharePoint Portal Server has come a long way in its second version.

Figure 3.2. Outlook Digital Dashboard: A Precursor of SharePoint Portal Server

The first version of SharePoint Portal Server (SPS) had two main problems. First, it had not been designed as an enterprise product, and it would not scale for large numbers of users or massive repositories of documents and data. The rule of thumb was a maximum of 1,000 users on a single SharePoint server. In version 1, scalability was not a primary design goal. It was impossible to simply add more servers to a SharePoint portal to share the document management load. Instead, you had to create separate SharePoint installations and invent your own creative ways to connect them. This shortcoming was not as limiting as it might first appear, as document collaboration typically occurs at the workgroup level anyway; but customers were concerned with such performance limitations.

Second, SharePoint Portal Server was still a bit more complex and expensive than Microsoft would have liked it to be to reach the mass of its users. With a client access license price of $60 “$70 per seat, large organizations were thinking twice before adopting SPS. Therefore Microsoft created a new product in the SharePoint family called SharePoint Team Services. This product has been replaced in the current SharePoint generation with Windows SharePoint Services (WSS).

SharePoint Team Services (STS) solved the problem of price objections to SharePoint Portal Server. It was essentially a free product that came with Office XP and FrontPage 2002. STS version 1 steered clear of the Exchange Web Store repository, relying on a relational database (SQL Server and its variants) as its repository. It was essentially a collaboration web site in a box, providing a document library, threaded discussion, shared calendar, and contacts. Perhaps to justify the difference in pricing, STS was stripped of document management capabilities such as version control and check-in, check-out , as well as the powerful SharePoint Portal Server search engine. In place of the digital dashboard and web parts, STS provided a canned web site design that could be administered through forms and further tweaked with FrontPage 2002. For Windows XP users, STS allowed integration such as drag-and-drop from Outlook contacts.

STS also overcame the licensing issues with SPS to allow easier collaboration with users outside the enterprise, because STS did away with the need for client access licenses. STS is easy to deploy inside and outside the corporate firewall and lends itself to quick, disposable collaboration site creation.

Today, with version 2 of SharePoint, most version 1 shortcomings have been addressed, as described in detail in Chapter 12, "Collaboration in the Enterprise Portal." SharePoint now scales to support larger numbers of users and can be deployed on multiple servers for this purpose. The attractive features of STS that were lacking in SPS version 1 have been subsumed by the version 2 product. These include the ability to easily generate team collaboration sites, built-in web page templates for threaded discussion, news, calendars, and other popular intranet features. The line between SPS and STS has also been blurred, with WSS gaining version control, for instance. Most important of all, SharePoint has now been migrated to .NET, offering tremendous power and scalability to developers versed in this platform.

The Microsoft Office Product Group is likely to continue its efforts to add more collaboration functionality in Office itself, as well as related desktop products, and some of these technologies will end up in the operating system. Microsoft had already made Windows XP a real-time communications (RTC) platform, supporting voice, video, instant messaging, application sharing, and collaboration. Products such as InfoPath and OneNote extend desktop collaboration capabilities even further than Office alone, and this progress is likely to accelerate as Microsoft turns its pure research into product reality. And don't forget Exchange 2003 Server for extending your portal to support mobile, wireless devices.