This month the name of the column is a misnomer because I want to look at some issues of going through the firewall. In between writing columns for EContent, I earn my living as a consultant and, over the last few months, I have seen a significant trend towards the deployment of extranets. If some recent figures from the UK Department of Trade and Industry are to be believed, around 20% of UK companies have an extranet. That seems rather high to me, but one feature of the intranet market is its total lack of reliable statistics, as all CMS vendors are beginning to realize.
In fact, I have seen the concept of an extranet used for two rather different applications: The first is the provision of remote access by staff to an intranet. With current wireless technology, this is an increasingly technically-feasible option. I use a 64K ISDN line for Internet access, but my mobile phone provides twice the bandwidth using a GPRS service. Unfortunately, however, most intranets were designed (if only designed were the right word) to take advantage of internal networks operating at perhaps 100MB/s, and so the fact that the staff newsletter is provided as a 3.5MB color PDF has little impact on access speeds. On the other hand, over a dial-up link, one could have a coffee and Danish while waiting for this file to download.
Apart from any technical issues with sign-on, the critical success factor is recognizing the limitations of bandwidth and also associated printing. A remote user is unlikely to have a color printer available, for example. The standards for the intranet need to be looked at quite critically with regard to file size. Of course, in an ideal world, there would not be any PDFs larger than 100K, but that is but a dream. Problems also arise with PowerPoint files that are used for topics like the Annual Review. PowerPoint files do not compress much in a zip file. But a major problem with them is the inclusion of vast amounts of reveals and dissolves. PowerPoint treats these as individual slides so removing them can have a significant impact on file size.
The final content issue is the provision of access to external services, such as those from Reuters business news services, or the Science Direct ejournal service. There may be some license restrictions on the use of these services outside of a physical site, or through a defined suite of IP addresses. Again, with these services (and especially ejournals), download speed issues need to be considered carefully.
The other extranet application is the provision of access to specific sections of the intranet. This is an area that professional services businesses such as law firms and management consultancies have pioneered in order to lock in clients. The theory is excellent, but the implementation can be a nightmare. In one frequent scenario, a client sees the range of content on the intranet of his law firm and comments about how useful it would be to have access to the briefing papers and legal information services.
However, the information architecture of the intranet was not designed to enable individuals outside the organization to see only what they should see; this is more than a security/password access issue. Hyperlinks in documents, and indeed the search functionality, could give clients access to some very sensitive information. It is slightly easier if the extranet content is partitioned onto a specific server, but if this has not been thought of at the outset, then the reverse engineering involved can be quite daunting.
Another issue is the look and feel of the extranet. The easy route is to maintain the existing look and feel of the intranet, but this may be totally inappropriate for the extranet content, not to mention the way in which a client will access this content. In fact, the content itself may need to be repurposed to remove internal acronyms and perhaps references to other clients.
Of course what many clients really want is low-cost access to services such as the Lexis and Westlaw legal databases. Here you should take extreme caution. The license agreements and copyright issues will almost certainly be a major barrier and it would be inadvisable to assume that the database owners will not find out.
If you already have an extranet then you've probably been through the pain barrier. If this is still something on the corporate wish list, then I would advise setting up a broad-based task group to look into technical, client relationship, information architecture, and legal issues. It is also worth pointing out that if you have managed without a CMS product so far, you are almost certainly going to need one to manage the flow of information from the content contributors to the intranet and/or extranet. All this in the name of better client relationships.