Feature

posted 11 Sep 2006 in Volume 3 Issue 3

Website management

A two-pillar approach to managing multiple websites

Website proliferation is a fact of life and ensuring that multiple sites adhere to the same infrastructure and policy guidelines requires a firm hand, says Nigel Atkinson.

Please note: Due to shortcomings in our website technology, we’re unable to reproduce some tables and illustrations referenced in this article. We can, however, provide Adobe PDF copies of the articles to subscribers on request. Please e-mail Graeme Burton, gburton@ark-group.com.

The web has become the medium of choice for publishing information and opening up online services to a huge range of audiences: customers, suppliers, employees, investors, the press and the public at large.

Each of these audiences has different (but often overlapping) needs in terms of the content and services they need to access. In order to meet the needs of each group in a more accurate and tailored way, many organisations now find themselves running a number of different web-based information systems, including websites, intranets, extranets, self-service portals and microsites.

That may be good news for consumers of web-based content and services, but not for the people whose job it is to keep their organisation’s numerous sites up-to-date and under control, without spiralling costs.

So what is the answer? A multiple website management strategy. This involves centralising the administration and control of technology infrastructure, while devolving responsibility for content and day-to-day operation of the individual websites.

In this workshop, we will consider the objectives of a multiple website management strategy, identify and investigate the issues involved and outline a process for establishing multi-site management within an organisation.

Before discussing objectives, we need a working definition for a website: in the context of this workshop, we will define a website as a single, manageable unit of content and functionality, owned by a branch of the organisation and provided for a specific, definable audience; for example, the ‘Widget Pro’ product website provided by the widget sales team for customers in Europe, the Middle East and Africa (EMEA).

This definition is useful to apply when auditing an existing portfolio of websites, as it can highlight isolated sites that may be prime candidates for consolidation, as well as areas within existing websites that might be treated as individual sites in their own right. An inventory of sites should contain at least the following information: site name, purpose, owner, and audience (see figure 1).

This kind of classification scheme should be developed in-house as it will vary according to an organisation’s size, structure and purpose. To illustrate, we can extend the example of the Widget Pro website a little further.

Let us consider two possible EMEA sales team structures. In the first, the sales team is centralised, managing the website and outsourcing translation of the Widget Pro website to an external agency. In the second, the sales team is sub-divided into regional offices throughout EMEA, each office having responsibility for localising the Widget Pro website for its own territory. The owner and audience segments, and therefore the website as a whole, may be better classified and managed by region in the second sales team structure.

Geography and role (employee, customer, partner and so on) are the two most common audience segmentations; however, some organisations will also wish to consider segmentation by other factors such as age (for age-restricted content) and presentation format (for example PC, mobile, interactive TV).

Strategy objectives

The purpose of a multiple site management strategy is to put in place policies and systems to support the cost-effective creation and management of websites across the organisation. This goal will be supported by the two pillars of effective website management.

Pillar one: Centralised policy and infrastructure management

The key driver for the centralisation of policy and infrastructure management is to reduce the cost of supporting the organisation’s websites. Cost reductions are achieved directly through shared infrastructure and centralised procurement, as well as indirectly through centralised day-to-day management and enforcement of policy.

Technology is the obvious place to begin when looking to achieve cost savings through infrastructure centralisation. Websites require hardware, software and network bandwidth to function, while further hardware and software is usually required to manage and report on their effectiveness. Sourcing and managing this hardware and software on a site-by-site basis very quickly becomes expensive, management of a diverse set of systems becomes difficult and this leads to increasing costs, security issues and frustrated website owners.

The selection of appropriate software, hardware and services by the IT department is crucial to success when centralising website infrastructure. Hardware and networking must be scalable with predictable costs to meet increasing capacity requirements. Website hosting infrastructure requirements may vary dramatically, depending upon the nature of each site. The website hosting environment should be designed to accommodate the most resource-intensive sites and either have enough capacity available to meet anticipated requirements over a two-to three-year period, or to scale rapidly to meet increasing demand.

The website-management software will be the interface that business users will interact with on a day-to-day basis. The choice of software will depend upon the number and nature of the websites that the organisation needs to manage, either now or in the future.

It is ideal, where possible, to select a single website-management product; however, this may not be practical, especially where the managed websites include existing complex functionality, such as e-commerce. In addition to standard content-management functionality, a centralised website- management software platform should also provide the following:

Single sign-on authentication for management access to all websites, with fine-grained, hierarchical access control of content and role-based permissions for publishing and approval workflow;
Asset-management libraries providing shared access to images, copy, video and so on to authorised website managers;
A flexible approval and publishing workflow that enables hierarchical approval of content across different websites prior to publishing;
A website publishing engine capable of publishing to the centralised hosting environment. This will often need to be capable of publishing to a server farm and must be configurable on a site-by-site basis to support publishing sites to different logical and physical locations;
Web application management and deployment;
Multiple website preview environments providing, at a minimum, a view of both content in development as well as the content currently approved for publishing for each website;
Comprehensive inline help and documentation for users.

In addition to the management functionality, providing a common library of web application functionality will support the creation of high-quality websites and consolidate customer relationship management (CRM) and application data. This will offer two benefits: first, it will reduce costs and timescales and improve quality and security when creating sites that utilise common functionality; and second, it will reduce system management overheads by consolidating application data and reducing the quantity of maintained application code. These are some areas of functionality that are candidates for provision through common libraries:

Website user management, authentication;
E-mail services and CRM;
Community functionality, such as message boards, polls, and user reviews;
E-commerce functionality.

Consolidated reporting across all websites provides the IT department with a consolidated view of resource usage. Reports should include:

Storage utilisation;
Network utilisation;
Website-management system usage;
System availability.

Finally, in addition to consolidated reports for IT department use, website managers within the organisation should be able to access the following reports on sites for which they are responsible:

Website usage;
Website user statistics;
Website availability.

Outside of the IT department, marketing, branding and legal departments may all wish to impose centralised policy across all websites in the organisation. Centralising infrastructure and policy within the organisation will require the creation of supporting processes for business users. Figure four, for example, shows a simplified process for the creation of a new website.

Pillar two: Devolution of responsibility for website creation and management

The key driver for devolution of responsibility for the creation and management of websites is to remove unnecessary operational bottlenecks from these processes. This both encourages the use of centralised infrastructure and resources and gives website owners direct control of, and responsibility for, their content and functionality.

Effective devolution relies on the ability of non-technical users to achieve results by following well-documented procedures for all tasks. Provision of common tools, user training and clear guidelines on issues such as branding, accessibility, internationalisation and legal compliance help to reduce day-to-day support requirements and remove barriers to the self-management of websites by teams within the organisation.

The ability to decentralise control of website design, application development and day-to-day content management and CRM functions is largely determined by the capabilities of the web-content management (WCM) software that is used. A suitable WCM system for multiple websites must provide the following features:

Shared asset management;
Shared template management;
Content re-use;
Flexible publishing workflow;
Discrete site and content publishing;
Content access control;
Role management;
Application code deployment;
Template development;
Search engine optimisation;
Technical and business policy enforcement.

Additionally, either as part of the WCM or through additional systems, website owners must be able to access statistics and reports on usage, campaign effectiveness and visitor communications for their sites. A centralised approach to reporting, as outlined previously, will provide website managers with the information they require and enable the central IT department to monitor infrastructure issues.

For websites offering complex functionality, such as e-commerce, the management software has additional requirements to provide access to website user data, application-specific data and reports. In order to support these types of site, a multi-site management system must provide the website owner with interfaces to manage and report on application data.

These interfaces may be external to the website management system itself; however, they should ideally be integrated so that user access control and role assignments may be centrally administered.

While in the majority of instances it will be desirable to ensure that corporate design and branding guidelines are enforced, there will be exceptions. The website management software should be flexible enough to cater for these in order to avoid website owners being forced to find their own solutions.

Strategy development process

We will now walk through a skeleton strategy development process aimed at managing multiple websites. The first stage of the process is to formulate an online strategy and implementation plan for the organisation. This should outline goals for the use of the web within the organisation and a set of high-level requirements for achieving them. This stage is of crucial importance to the success of any implementation project and should be conducted at senior management level, in consultation with a significant sample of website owners, business strategists and IT department representatives.

The next stage of the process is to understand the current and anticipated website usage profile for the organisation. There are four important aspects to consider for each website in this inventory stage: content, personnel, systems and data.

We begin by building an inventory of all existing websites and websites in development within the organisation. The inventory should contain the following about each site: Site name or ID, purpose, owner, audience.

Any additional information readily available should also be recorded; this may include details such as published URL and usage information.

We then need to create a content inventory, an organisational chart and a systems inventory for each website. The content inventory does not need to go into great detail in the context of this process and should include only a high-level description of the subject, organisation and format of content within the site. Restricted information should be highlighted and details of the required level of protection and access control included. This information will be used later on in the process to identify common content and to derive website management system requirements.

The organisational chart for a website should identify key resources and stakeholders. These should include:

Website owner and business stakeholders;
Website content managers;
Website IT resources.

It should also include information about any workflow processes – whether systematised or not – and contain details of the responsibilities of each individual.

The systems audit should contain details of all system infrastructure supporting each website. This should include technical details and location of all hardware, software and communications systems, both internally and externally managed.

The data inventory should include details of all data managed or accessed by each website. This should include application data such as website user and transactional records. The inventory should detail the quantity and locations of data stored and indicate the sensitivity and any regulatory requirements relating to the data.

The final stage is a detailed review of functional and non-functional requirements for the infrastructure that will support web-based activities within the organisation. This is based on the information gathered during the inventory stage and augmented with requirements to support the organisational strategy. At a high level, there will be requirements in the following areas:

Functional requirements

Infrastructure management;
Content (website) management;
Asset management;
Publishing;
Workflow;
Website functionality;
Reporting.

Non-functional requirements

Security;
Scalability;
Isolation;
Availability;
Performance.

The outcome of the process ought to be an understanding of the current website landscape within the organisation, a high-level vision and strategy for website use by the organisation in the future and a set of requirements for the implementation of technology and processes to achieve the vision.

Nigel Atkinson is a director of NeoWorks, a software development and consultancy company that has performed website content management and e-commerce projects for a range of clients, including Channel 5 Broadcasting, Royal Doulton and Levi’s Europe. He can be contacted at nigel@neoworks.com