Publishing content on corporate Intranet, Extranet and public websites

In my presentation on 22 August 2008 at the 8th Annual Strategic Intranet & Enterprise Portal Management Summit in Wellington, I looked into aspects of merging corporate Intranet, Extranet and public websites into single synchronized systems that allow access to both staff and partners.

The challenges that I discussed included:

  • Synchronising visual design and branding
  • Integrating separate systems from multiple vendors into a single sign-on system
  • Creating search results that are rich in context
  • Finding win-win solutions to diverse requirements from teams and business units that are distributed across the globe

I find the most interesting challenge, however, to be the issues around publishers that want to use a single instance of information across multiple websites.

Re-use of content when publishing to corporate Intranet, Extranet and Internet websites

The write-once, use-many-times model is popular and rightly so: when content requires updating, a single update of the source will automatically be reflected on the multiple websites where that content has been used.

Requiring multiple instances of similar content also happens when publishing to corporate Intranet, Extranet and Internet websites.

A very simple model would be to use security levels as access levels: documents marked as Internal would appear on the Intranet, Restricted would appear on the Intranet and Extranet, and documents with a rating of Public would appear on the Intranet, Extranet and public websites.

There is a down-side to this approach: external audiences often require less information than internal audiences, but they need more context around the information. A system engineer, for instance, will be comfortable with highly detailed descriptions of the features of the products that must be integrated into a system. A salesperson may require a less detailed description of the features, but would need to know as much as possible about the benefits that these features will have for a potential customer.

Due to the need to have different levels of detail and context for different audiences, matching a single instance of information to a wide audience is not always appropriate. It sometimes mean that content must be adapted into different formats and then maintained in more than one location.

Another approach is to display additional information when required. In the example of feature and benefit descriptions, someone who is part of the system engineering group will see fully detailed specifications of a specific product. For the same product, a sales person will see a subset of the technical specifications, but a comprehensive range of benefits. In other words, content is presented or filtered out by audience role.

What is the difference between Intranet, Extranet and Internet?

Steve Gallagher from Synapsys and I had a number of conversations on this topic in the past few months, and it was also a regular point of discussion during the summit.

Ten years ago, Steven L. Telleen wrote on this topic, and laid down a rather robust definition (relevant after 10 years) of the difference between Intranet, Extranet and Internet.

My take on it:

The Intranet is the sum of an organisation's websites and web applications used by its staff. This can range from applications such as the phone book and calendar, issue and document management systems, through to internal wikis and blogs. Mature Intranets consolidate the information and applications that a staff member requires on a personalised home page.

The Extranet: websites and application on the Extranet is meant for business partners or customers of the organisation. Note that the sites and apps that comprise the Extranet, may also be part of the Intranet. There may also be sites or apps that are part of the Extranet but not used by staff and therefore not part of the Intranet.

The Internet: any content that is not secured by a login.

The security-conscious IT manager may choose to locate Extranet sites and applications on a DMZ, while keeping Intranet sites and applications inside the corporate firewall. This requires a physical separation between Intranet and Extranet, but the information served up by these separate systems can still be integrated seamlessly as described above.

So in the end, in terms of information, Intranets and Extranets are separated only by the roles of its users: if a website or app is used by staff, it is part of the Intranet. If it is used by users who are not staff, it is part of the Extranet. If it is open to the public, it is part of the Internet.

From that, I conclude that we had better know who our users are and what information they require!