Content Management Server - Accenture Portal Deployment Guide

Article
08/02/2007

Introduction

One of world's largest consulting companies recently undertook efforts to implement a content management capability for its internal portal solution. This is the next step along the path to a final, overall vision for an enterprise employee portal. Future portal capability phases include:

Profile and personalization – portal uses user profile and preference information to present suggested content.
Collaboration – capabilities such as discussion and document libraries that enable interaction with other employees or Web site owners.
Knowledge integration - syndication of internal and external knowledge content from disparate sources.
Enterprise integration - leverage of existing data sources and application functionality.

Accenture's company-wide, employee portal is primarily used as an information delivery mechanism to its 75,000 employees. This portal is very important to Accenture's overall business because it gives employees one central place to go to obtain information necessary to do their jobs. Accenture maintained two prior versions of its portal site before this release: a custom implementation using Extensible Markup Language (XML) and Extensible Stylesheets Language-Transformations (XSLT), and an implementation in Microsoft® Content Management Server 2001. For purposes of this white paper, we will be looking into the advantages of the Content Management Server platform versus the custom XML/XSLT solution, focusing on the implementation of the 2002 product.

Prior to this release, Accenture was using a custom implementation that employed the usage of XML and XSLT in order to deliver syndicated content to the browser. The use of this syndicated content meant that it was able to reuse stories and articles stored in XML on the file system throughout its entire site without duplication of content. In addition, it was able to provide a consistent look and feel, maintaining company-wide user interface (UI) standards by using XSLTs to transform the XML content to be consumed. This solution was not without its shortcomings, however. These included:

Limited resources to facilitate quick update of site content.
Change process for updating the production environment was cumbersome.
Non-technical business users could not easily update/create portal content.
Content owners were not forced to adhere to template in which content was to be added.

Looking to the content management phase of the portal solution, Accenture wanted to be able to address the shortcomings of the current system, as well meet a new set of requirements. Some of these new requirements included providing real-time updates of content to production, reducing the time it takes to create content, providing a more useful searching facility, and providing “I want to…” functionality.

With the hopes of addressing the shortcomings of the XML/XSLT solution, meeting release requirements, and further leveraging their investment in Microsoft technologies, Accenture decided to implement their content management release by using Microsoft Content Management Server (CMS) 2002.

Solution Requirements

During the envisioning and planning process, Accenture identified the requirements for the content management phase of its implementation. The primary goal was to enhance the portal capabilities for information delivery to employees. Detailed requirements include:

The need to provide real-time updates to production. After going through an approval process, content would be automatically updated on the production environment without the hassles that come with traditional deployment.
Ability for non-technical people to update/create portal content. It would not only allow non-technical business users self-service content update/create capabilities, but it would also allow for the content maintenance to happen on the actual portal site itself.
Anytime, anywhere accessibility to edit site content. Due to the fact that the bulk of the Accenture workforce is typically away from the office, and virtual private networking (VPN) access isn't always an option, accessibility for the portal site needs to be able to happen directly over the Internet.
Reduction of the amount of time it takes to create content. Accelerating the time it takes to maintain site content will benefit the business in many ways.
Enforcement of corporate-wide UI standards. Accenture needs the ability to make sure that content owners are adhering to corporate-wide standards in an easy, straightforward manner.
True separation of content and presentation and support for XML to enable content syndication. Content syndication is not only the ability to maintain one copy of all of the site content, but also to be able to display in multiple locations and formats. This is something that speaks to the architecture and flexibility of the system.
Greater control of site content. This includes a workflow process for content maintenance approval and the ability to have UI and content changes replicated globally where applicable.
Alignment with overall corporate technology strategy of using Microsoft.NET as an application framework.

Logical Architecture

The primary goal of the Accenture portal is to be able to deliver content, tools, and services to its employees in a very compelling and useful manner. Accenture accomplishes this by aggregating its disparate content sources and application services as well as providing a high-level channel hierarchy and search to ease navigation. By doing so, Accenture employees are able to realize one of the key goals of the portal vision, which is to more easily locate intellectual property and services that are key to their jobs and the overall Accenture business. In addition, being able to do this in a very compelling manner will help to foster adoption and usage of the portal by Accenture as a whole. Some of the different content sources and services that have been aggregated into the portal include news related to Accenture's business, accessibility to the intellectual property store, workplace services such as booking a conference room, travel services, and ability for employees to view information regarding their careers and benefits.

A stepping stone along the way to the final portal vision is focused on content management. The primary goal of the content management portion of the portal vision is to empower non-technical content owners to be able to create and maintain content for their sites in real time. This means that the portal site content can be maintained without the involvement of technical developers or administrators. This in turn reduces the amount of time that it takes to create content and enables site owners to provide more and fresher content, allowing their sites and home pages to be updated on a more frequent basis.

Taking into account these requirements that Accenture was looking to achieve, let's take a look into the logical architecture that Accenture put into place with the portal solution. The logical architecture of the portal solution entails many different areas of functionality, including:

Having a consistent global navigation – enforcing the usage of the same high-level navigational hierarchy throughout the portal.
Providing common navigation elements throughout the solution – this includes functionality such as search, "I need to", and so on.
Support for site sub-identity – giving site owners the ability to update their own Cascading Style Sheet (CSS) to provide a customized look and feel to their site.
Advanced content management capabilities – empowering site owners to be able to create and maintain their content in a real-time manner.
Ability to maintain user preferences and subscriptions – for this release, user preferences and subscriptions entail geographic location for localization, storage of up to 10 personal "quick links" (favorite user links), and selection of newsletters to be e-mailed to users.
Ability to analyze the usage metrics of the overall solution – being able to look back and report on site usage, slicing on many different categories.

These items are best represented in the following diagram:

Physical Architecture

In order to determine the technology that best fits the above requirements and functionality, Accenture began by reviewing the various content management products on the market. After evaluation, it was able to determine that CMS best suited its needs, as well as meeting an overall strategic objective of the organization –leveraging the .NET framework.

The next step that Accenture took was toward the development of a proof-of-concept (POC) on the Microsoft CMS/.NET platform. Before devising a POC, it needed to take an in-depth look into the organizational structure for the existing content contributors and managers. This helped Accenture to determine what high-level architecture it needed to put into place for the portal solution. Next, it evaluated the best approach to provide the localization of content in the CMS/.NET platform. From there, it was able to craft mockups for each of the proposed home and channel pages, and these were shown to end users to obtain feedback.

Taking what it had learned from the POC implementation, Accenture was able to take the next step forward to implementing their overall portal solution. Looking into the implementation of CMS, Accenture divided the portal site into two main publishing areas: Portal Main and Portal Publishing. Portal Main contains the core localized content to the overall portal solution and information to be viewed organization-wide by all employees. This portal uses the following high-level navigational structure:

Portal Home
Our Organization
Knowledge
News
Workplace & Services
Travel
My Career
My Benefits

The second publishing area contained in the overall portal solution is Portal Publishing. This area enables any internal group at Accenture to create and maintain an informational site leveraging the solution's overall technology and hierarchy. At time of publishing, the Portal Publishing site only contained two top-level sites/channels.

There are two main differences between the Portal Main and the Portal Publishing functionality:

The Portal Main site has a fixed number of top-level sites/channels, whereas the Portal Publishing site will continue to grow the number of top-level sites/channels based on internal user request for custom implementation.
The Portal Main site has the ability to display localized content to site users based on their country preference, whereas the Portal Publishing site does not.

The overall portal solution entails a total of 15 servers spread across Accenture's Quarantine Zone (QZ) and internal network (GTN). These servers can be broken down functionally based on the software installed on them. This library of software used in the overall portal solution includes:

Microsoft Windows® 2000 Advanced Server – Base operating system installed on each of the servers in the Accenture portal.
Internet Information Services (IIS) version 5.0 – IIS 5.0 is responsible for handling all of the Web request traffic on the portal.
Content Management Server 2002 – Installed on each of the five front-end Web servers to enable real-time, portal-wide content management by site owners and solution administrators and developers.
Application Center – Used to assist in the deployment of updates by portal administrators and developers to the servers in the production Web farm. Files that are deployed include Active Server Pages (ASP) .NET, XSLT, and database files to be restored. Application Center also assists in the monitoring of server health.
Microsoft SQL Server™ 2000 – Core database of overall portal solution. This contains Web content stored by CMS and personalization and subscription information for the solution.
Microsoft SharePoint™ Portal Server – Core technology used for portal-wide searching. This enables Accenture employees to find Web content in a speedier manner.
Microsoft Visual Source Safe (VSS) – Code repository used to maintain versions of the portal site source code as well as to deploy the portal site project files to the different environments.
Web Trends (Used for site usage analysis) – Third-party product used to analyze and report on Web usage trends of the Accenture portal.
Altova Authentic 5 Browser Control – Third-party product that enables business users to create XML content via an intuitive UI.

Whether site users are on the internal GTN or outside of the QZ, accessibility to the portal solution happens entirely via the extranet. This means that whether an Accenture employee is accessing the portal site from an internal or external location, the employee will be challenged for credentials in the exact same manner. This is done because the bulk of Accenture employees are typically at client sites, so they require extranet access. By comparison, the number of employees who access the site internally or via VPN are small, so putting up this additional infrastructure was not worth the cost. Both the Portal Main and Portal Publishing Web sites are set up for basic authentication over secure sockets layer (SSL).

Below is a graphical representation of the overall portal solution:

The hardware for the servers shown in the diagram above for the core CMS solution (IIS and SQL Server) consists of:

IIS Server – Five Compaq DL 380 dual processor servers
SQL Server – Two Compaq DL 580 quad processor servers

Security

Microsoft Active Directory® directory service provides the basis for both authentication and authorization in accessing the Accenture portal solution. In IIS 5.0, both the Portal Main and Portal Publishing sites are set up by using basic authentication. Since both internal and external accessibility to the portal occurs via the extranet, basic authentication was used rather than Windows Integrated Authentication, which is most often used for intranet portal authentication. That being said, the benefits of single sign-on would not be able to be realized through the usage of Windows Integrated Authentication. In order to not send the domain, user, and password information in clear text at time of sign-on, Accenture is leveraging the use of SSL encryption for traffic to both portal sites via basic authentication. Anonymous access is disabled to both portal sites in the interest of protecting confidential company information, as the site is exposed to the internet.

Authorization is handled by a combination of Active Directory Access Control Lists (ACLs) and CMS roles. For this phase of the project, Accenture maintains approximately 900 ACLs in Active Directory. These ACLs are broken down based on the CMS channel hierarchy (described in greater detail in CMS), as well as the possible CMS roles that can be assigned to a channel by an end user. These CMS roles include channel manager, author, and editor. The usage of these roles will be explained in greater detail in the Content Management Server section below.

SharePoint Portal Server

SharePoint Portal Server's (SPS) features as a product center around three core areas of functionality: scalable enterprise search, integrated document management, and a customized portal solution. Of these three features, Accenture is currently only leveraging the search capabilities in this release of the Accenture portal. The main reason for not using the integrated document management and customized portal was due to how Accenture viewed its portal content. Accenture considered its content to be more Web-related than document-related. This meant that the portal content was better served via a content management product than document management product. As well, at this point in the overall portal solution, Web-based content took on a higher priority.

There were two primary methods of locating content that Accenture was looking to implement on its portal solution:

Channel hierarchy - allow employees to drill-down to their desired content.
Search capability – allow employees to find their desired content based on keywords and phrases.

Based on these two methods for locating content, Accenture looked to SPS to be able to meet its search capability needs. SPS was already being used internally as a method for indexing and searching content. Accenture was able to leverage the flexibility of SPS by separating the indexing and search servers to provide better performance to the search being performed on the Accenture portal.

Accenture divided its search indexing into six distinct categories. These categories include:

Knowledge Assets
Discussion
Experts
Methods
Learning
External

Below is a screenshot of the portal solution's search:

Content Management Server

CMS 2002 is at the core of the Accenture portal solution implementation. With this in mind, it is necessary to drill-down on CMS and examine the various pieces that are entailed in Accenture's implementation. This section focuses on the channel and template hierarchy, the roles and tools used in CMS, any major custom components created, the new site creation process undertaken in CMS, and any portal content not contained in CMS.

Channel Hierarchy

The main hierarchy of Accenture's portal solution is based on a channel structure that is contained inside of CMS. Each of the major entities within the Accenture portal site is incorporated as a high-level channel. In total, there are eight main, high-level channels contained in the Portal Main site and, at time of publishing, two custom high-level channels in the Portal Publishing site.

The Portal Main site is further broken-down into sub channels based on both sub-entities and countries. The entire portal solution supports up to 48 different country localizations based on the sub-channel hierarchy contained underneath each of the entities and sub-entities. An example of this hierarchy is as follows:

chanhier

The high-level channels of the Portal Publishing site are based on each of the custom implementations. Like that of the Portal Main site, each of the custom sites under Portal Publishing can be further broken down into a sub-channel structure. Although as with the case of custom site in Portal Publishing, the site owners are responsible for making this distinction. This gives the site owners the flexibility to create whatever channel structures their solution dictates. This channel hierarchy is created and maintained through the custom "Modify Site Structure" template discussed more in the Custom Components Section below.

In total, there are approximately 4,500 channels in Accenture's overall portal solution. This number is so large due to the globalized nature of the Portal Main portion of the solution.

Template Hierarchy

The logical organization of the template gallery, at a high level, is based off of the channel hierarchy. This can be thought of as more of a categorization of the templates into high-level buckets based on the different elements of the portal solution. An example of this hierarchy consists of templates for the portal home page, channel home page, and portal content.

One of the main differences that exists between the channel and template hierarchy is the breakdown based on country. Since templates are merely the layout for the site content, they are created to span the different geographies contained in the portal site. This also helps to encourage the UI consistency across the entire portal solution.

Roles

CMS has a layer of abstraction in its architecture based on security. This layer introduces the ability to assign different roles to domain users or groups (ACLs) for the purposes of authentication and authorization against Active Directory. In total, there are eight roles in CMS 2002:

Administrator
Channel Manager
Resource Gallery Manager
Template Designer
Author
Editor
Moderator
Subscriber

Of these eight roles contained in CMS, Accenture only uses five for its portal solution:

Administrator – Used by solution administrators and template developers.
Channel Manager –Primarily assigned to the owner of the custom site in the Portal Publishing portion of the solution. This allows the owner to manage/maintain the sub-hierarchy of his or her custom site, as well as the different roles of the custom site.
Author –Used by the individuals responsible for generating and maintaining site content.
Editor – Proofs the new and updated content generated by the author.
Subscriber – Assigned to the internal Accenture organization on the whole for general site accessibility.

Roles not used in the Accenture portal solution:

Resource Gallery Manager – Resource gallery not used.
Template Designer – Template developers are set up as administrators as they double as solution administrators.
Moderators – No need for extra level of approval.

Content Management Server Tools

Out of the box, CMS comes with a series of tools to help administrators and authors manage and maintain their sites. For CMS 2002, these tools include Site Manager, Site Deployment, Site Stager, and Authoring Connector for Word. Of these tools, the Accenture portal solution focuses its usage on only the Site Manager and Site Deployment tools. The Site Manager is a must-use for administrators of the solution in order to manage and maintain CMS functionality across the solution.

At time of publishing, the Site Deployment tool is only being used for smaller scale and specialized deployments. Larger scale deployments are accomplished via database backup and restore. Accenture does not currently use the Site Stager or Authoring Connector for Word tools.

Custom Components

In order to implement the functionality as documented in Accenture's requirements, Accenture solicited the usage/creation of custom components that were not included with CMS 2002 out-of-the-box. These components included:

Altova Authentic 5 CMS Placeholder Control – Third-party placeholder control used on CMS templates to ease creation of site XML content.
Modify Site Security Template Page – Custom template page developed by Accenture to allow content owners to maintain security on their portal sites.
Modify Site Structure Template Page – Custom template page developed by Accenture to allow content owners to maintain the overall channel and posting structure on their portal sites.
Site Callouts – Custom virtual Web parts developed by Accenture that allow content creators to personalize the layout of a channel home page.

Altova Authentic 5 CMS Placeholder Control

The idea behind content syndication in the portal solution meant that site content was stored in one location and displayed in many. Not only could the content be displayed in many different locations, but it could also be shown in many different ways. The basis for this in the portal solution entails the storage of content in an XML format and the display of content using an XSLT. Enter Altova Authentic 5 placeholder for CMS 2002. The Authentic 5 placeholder control allows for the simple creation of XML content by site content owners, as well as plugging directly into the CMS/.NET platform.

Site owners select a CMS template that contains the Altova Authentic 5 placeholder to generate content. After selecting the CMS template, content creators pick from a listing of XSLT layouts that are pre-created by the Accenture portal solution developers. This XSLT will determine the format in which the content in the Altova Authentic 5 placeholder control will be displayed. Here is an example of what this template looks like in the portal solution:

Site Security and Site Structure Template Pages

In order to allow for content owners to be completely self-sufficient in the creation and maintenance of their portal sites, the portal solution team has developed two templates that are added to the Web authoring console of the portal solution: Modify Site Security and Modify Site Structure. Aside from the obvious ability to update site security and structure, these templates allow content owners to maintain their sites without having Site Manager installed on their desktops. Links to the two template pages are shown below:

edit_ste

The Modify Site Security template gives channel managers the ability to add and maintain the security of their overall portal sites via the Web-based authoring console without needing to go through an administrator or developer. Channel managers are able to modify the channel managers, authors, and editor roles of their portal sites. Below is an example of what the Modify Site Security template looks like:

The Modify Site Structure template gives channel managers the ability to modify the channel and posting hierarchy of their portal sites via the Web-based authoring console without needing to go through an administrator or developer. Channel managers are able to create and delete channels and postings based on a tree view to modify the hierarchy of their sites. Below is an example of what the Modify Site Structure template looks like:

Site Callouts

Similar to the Altova Authentic 5 placeholder control, portal site home page templates give content creators the ability to choose a page layout based on an XSLT transformation of XML data. The core XML data that is being transformed consists of a high-level site navigation that is dynamically pulled from CMS at time of viewing. The difference between the XSLT layouts for the home page is based on the inclusion and location of virtual Web parts to be displayed called "callouts". These callouts are merely a snapshot of information that can be linked to from numerous locations throughout the portal solution. A home page can display zero to three callouts at a time, and they can be displayed along the top or on the right of the home page. Below is an example of a home page template that allows for the usage of callouts:

New Site Creation Process

All requests for new or custom sites in the portal solution are put into the Portal Publishing site. The main pieces of this process entail:

Creation of new CMS channel.
Assigning Administrators and Subscribers to new channel.
Creation of the new channel roles.
- Channel manager
- Author
- Editor
Assigning of the channel manager of the new channel.
Creation of the ACLs in Active Directory (specific to channel and role in CMS)
- Channel manager
- Author
- Editor

Once assigned a channel manager, the site owner is able to assign individuals to each of the three groups set up in Active Directory. The site owner can do this directly from the Web authoring console on the custom portal site that was created. This eliminates the need to provide the CMS Site Manager client to the site owner, as well as to require solution administrator involvement when modifying site structure or security.

Localization

Being an international organization, one of the most important requirements of the internal portal solution is localization. Localization allows site visitors to view the portal site content in a language most familiar to them based on their country preference. As discussed in Content Management Server Channel Hierarchy, CMS makes localization of the portal site content a straightforward process based on the site channel hierarchy.

There are two different types of content implemented in the portal solution: global and local. Global content is content that will be displayed on a given page no matter which country a user has specified. Local content will be displayed based on the current user's country of preference. This means that any given page will display a combination of global and localized content.

Directly related to the two different types of content are two different templates that are created/used for every given localized posting: global and local templates. A global template for a given page consists of both primary and secondary placeholders. Content posted in primary placeholders on a global template will always be displayed on a given page, regardless of user country preference. Content posted in secondary placeholders on a global template, however, will be overwritten on a given page by content posted in a local template if a user has specified a country preference.

A local template contains the same placeholders as the secondary placeholders in the global template for a given page. The content posted to these placeholders in the local template will override the content posted to the secondary placeholders in the global template for a given page. The diagram below illustrates a localization example for a given page:

Keep in mind that if the user has not specified a country preference, content posted to both primary and secondary placeholders on the global template for a given page will be displayed.

Non-Content Management Server Managed Content

A tremendous percentage of the overall Accenture portal solution is managed within CMS 2002. At time of publication, the only portion of the portal solution that is not managed within CMS is a section entitled "Accenture Q&A". This is a pretty straightforward site that was created before the migration to the CMS platform. At this point, there has simply been no effort to migrate.

User Experience and Benefits

The user experience and benefits of the portal solution best illustrate the added value of the CMS platform. Let's take a detailed look into the experiences and benefits recognized by each of the individual site users.

Content Owners

Content owners are the people responsible for adding and maintaining their portal site hierarchy, security, and content on a regular basis. Content owner roles and responsibilities consist of the following (CMS role):

Portal manager (channel manager and editors) - Responsible for managing the portal site hierarchy and permissions, as well as approving new and edited content to be shown on the production site. The portal manager experience is based on the usage of the Web authoring console to maintain the site hierarchy and users on their portal site and use the CMS Approval Assistant to view content awaiting approval.
Content creator (author) - Responsible for generating the content that is to be displayed in the portal solution. The content creator experience is based on the usage of the Web authoring console to add and maintain content on the portal site.

Content owner benefits from the portal solution include:

Web-based site hierarchy, security maintenance, and content creation and maintenance.
Easy determination of where new content is created and where existing content can be maintained
Site easily maintained by business users.
Intuitive UI.
Ability to make real-time updates to production.
Ability to add more site content.
Updated site hierarchy and security.
Custom templates geared toward site content.
Web-based content approval.
Ability to approve content in the same place that it lives.
Ability to preview content within portal site before approving.

At this time, Accenture is not using e-mail notification for content approval.

Site Users

Also known as the subscriber role in CMS, site users include the entire organization that uses and views the portal solution. The site user experience is based on simply viewing the portal content through a Web browser. Benefits include:

Fresher content.
Home page changes more frequently.
Site UI consistency.

Solution Administrators

Also known as the administrator role in CMS, solution administrators are the people who are responsible for maintaining the overall portal solution hierarchy. The solution administrator experience is based on the usage of Site Manager to administer and maintain the overall solution hierarchy. Benefits include:

Less need to interact with site owners.
Content maintained on the live server.

Implementation

The overall portal solution was developed and tested by a team that consisted of the following roles:

1 Product Manager
1 Development Lead
8 developers
An outsourced team of infrastructure/logistical individuals
A team of Human Performance individuals (helped determine and communicate changes to functionality, as well as create and conduct training)

The implementation took approximately six months to complete. The use of beta code for both CMS 2002 and the Altova placeholder control contributed to additional hours on the project. In addition, there was a learning curve for the development team associated with using .NET, XML and XSLT, and CMS 2002. That being said, being able to complete a solution as complex as this in six month's time speaks highly of both the Accenture project team and the Microsoft platform.

The training of the completed portal solution is handled by the Human Performance team within Accenture. This training consists of both a high-level look into the editing and workflow functionality in CMS and a more detailed offering related to site maintenance that is geared specifically toward the content owners of the portal. The training is typically conducted via Microsoft NetMeeting® or teleconferencing services for the remote users of the site.

Testing and Deployment

Accenture has two environments set up for the portal solution: development and production. The development environment is broken down into seven different logical environments:

Development – This is where the core site development happens. This includes CMS templates and any custom components used in the system. Unit testing occurs in this environment by the developers.
Assembly Test – This environment is used to test the bringing together of one section or page in a particular portal site.
Product Test – The portal solution in its entirety is pulled together in this environment to test the overall interaction of the solution.
Performance Test – Accenture uses Loadrunner in this environment to test the overall performance of the application.
User Acceptance Test – Site users begin using the overall portal solution in order to perform functional testing.
"Fix It" Environment – This is an environment that mimics production that is used to make and test quick fixes.
Staging – This is an environment used to test the portal solution's hardware interaction with Accenture's QZ.

Physical breakdown of the development environment includes:

One server (CMS and SQL Server installed) – Used solely for Development and Unit Testing.
Two servers (CMS installed on one, and SQL Server installed on the other) – Used for Assembly, Product, Performance, User Acceptance, and Performance Testing. These testing stages are broken down solely by time. Typically, solution updates have a specified timeframe for each testing stage. The hardware for these two servers is set up as a scaled-down version of production in order to achieve accurate test results from performance testing.

Deployment between the different physical servers can happen in one of two ways. For major deployments (for example where the CMS channel structure has undergone major changes), a database backup and restore is done between the two physical environments. For point releases of the site for operational updates and minor functionality updates, Accenture leverages the Site Package and Deployment tool that comes with CMS. In both cases, file migration is a two step process done via both VSS and Application Center. VSS is a mechanism used for source control in the development process, as well as the pulling of all Web project files directly into each of the different environments. Once the code has been pulled into a given environment, Application Center replicates the Web project among the farm Web servers.

After initial release, each subsequent release will be deployed based on what Accenture calls an "incremental build" philosophy. This means that Accenture will take many small steps with the rollout of a new version as opposed to having one large deployment. This helps to mitigate scope creep and enables the portal solution to be updated faster.

Performance

On a high-level, moving to CMS 2002 alone has greatly improved site performance of the portal. This is due to the fact that .NET is now the base architecture of the portal, and improvements were made in how the site functionality was implemented (this is directly related to the greater level of development capabilities on the new .NET/CMS 2002 platform).

Accenture currently uses WebTrends to analyze portal usage data. Using WebTrends, it was able to determine that it received 89,000 page views/day with a visitor daily peak at around 650. Latest figures show that the portal has experienced 72,875 visitors over the course of a six month period with a return rate of 89 percent.

Note: Accenture has not currently implemented any ASP .NET output caching or CMS fragment caching in their solution. This is something that Accenture is looking at as a future enhancement.

Conclusion

One of main reasons that Accenture was so successful in its implementation of the portal solution was because the approach that it took to CMS 2002. Viewing CMS 2002 as simply an extension of the ASP .NET platform, Accenture was able to accomplish many powerful things by thinking "out of the box". This included custom placeholders, Web services, and content syndication.

Moving the Accenture portal to the .NET/Content Management Server 2002 platform has been a real win for Accenture. Benefits of the new platform include: non-technical content owners being able to make real-time updates to their sites in production without having to interact with the portal administrators or developers; time greatly reduced for content owners to create content; administrators who are better able to enforce corporate-wide UI standards; true separation of content and presentation and greater support for XML that provided a very simple and straightforward approach to content syndication; and the overall solution's direct alignment with Accenture's corporate strategy for technology.

Using Microsoft portal technologies, Accenture delivered the content management capability for its employee portal.

For more information, see:

https://www.microsoft.com/cmserver/

https://www.microsoft.com/solutions/portal/default.asp