Often times by the time a client gets to finding me, they have reached a point where they are ready to throw away their entire web infrastructure: both their corporate website and their intranet. They hope that one well executed product selection can solve both problems. When approached by this kind of prospective client I am careful to set the expectation that this hope is probably not realistic — not impossible, just not realistic. That said, there are a few conditions where putting your intranet and external website on one stack does work. Here are the criteria that I use.
- The intranet is informational rather than collaborative. Different people mean different things when they say the word “intranet.” For some, an intranet is just a collection of web pages that only employees can see. Others think of tools and workspaces that allow employees to collaborate and get things done. If you had the latter in mind, chances are you will be looking for a document management, ECM, or portal system like Sharepoint for knowledge worker collaboration. These systems are technically capable of pure web publishing but that is not their strength. Your website management team will feel constrained by a platform that treats web publishing as an afterthought. If you think of your employees and customers/prospects simply as different audiences that you need to publish to, a single platform may work just fine.
- The company has other platforms on which to build specialized, dynamic web applications. Sooner or later (or probably already) your company is going to need to develop content-oriented web applications and your WCMS is a logical place to start. However, these web applications are likely to introduce the most demanding and specialized requirements. It is quite possible that the union of your intranet and external website application requirements filter out every viable CMS — or at least force some painful compromises. If you have an alternative stack on which to build your fancy custom applications (possibly pulling content from your WCMS) and can let your WCMS focus on simple web publishing, you greatly increase the chance that you can comfortably support both internal and external publishing.
- The corporate website and intranet are owned by one communications group. Today you may be able to align your intranet and external publishing needs; but will they stay aligned? How will you arbitrate between the competing priorities of the intranet and marketing website? What if those priorities don’t just compete for resources but actually conflict with each other? Things can get ugly when two different departments with different goals argue over what feature needs to be added next. These decisions get a lot easier if both the intranet and external website are owned by one communications group. Companies that are structured this way are usually small and can benefit the most from sharing the infrastructure cost between the intranet and extranet. Having the intranet owned by a communications group also pretty much ensures that criterion 1 is satisfied.
If your company meets these criteria, there is a good possibility that one instance of one CMS platform could serve you quite well. Otherwise, I would recommend doing one of your two projects and then putting the product that you used on the short list of products to consider for the other. If it turns out that the one platform supports the requirements of the second project, buy another instance of the software (hopefully at a discount) and start a new project to implement it. Take advantage of code and idea re-use but don’t let that constrain the flexibility and agility that you need to achieve your goals.
Related posts:
- Does “Intranet” Need a New Name? James Robertson has an excellent post, Future principle: it’s more...
- Facebook as your Intranet? At the cmf2007 conference last week, there were some great...
- Do you need a blogging platform? Do you only need a blogging platform? I was reading this post on the definition of a...
- What your intranet needs is a publisher! J. Jonah Jameson Originally uploaded by OntologicalDoubt While I...
- How to Fix a Broken Intranet I am doing a joint presentation in Toronto with Julian...
I recognise each of the points you are making, and I agree with them; however, I’d like to note that it’s quite possible for a single WCM system to have a range of features that allow the implementor to make radically different choices when building an intranet or an Internet site.
It’s not always wise to use the same platform for both, and attempting to share content between the two is often a bad idea, but when an organisation has invested in a fully featured system, and trained its people accordingly, it can often make sense to have a common system.
(I work mostly with Tridion implementations.)
Really helpful post. In our view, the underlying use cases – not to mention the business objectives – of public facing websites and intranets to differ so dramatically that it’s hard to imagine a solution that could manage both without huge customization efforts. In many cases, in fact, you see multiple platforms or systems within the intranet itself to deal with top down info dissemination (the paid leave form, the H1N1 policy) and bottom-up social computing (wiki, blogs, content rankings etc.) In this case, intranet/enterprise search becomes critical and must span both. Make sense?
I think you should have the same platform but different environments. It is very expensive maintain knowledge of two different platforms, in case you want to do customization or addons.
Very interesting discussion!
I’m weighing up the possibilities of using Drupal to create a system where a company can run its Intranet and website from the same installation. If anyone has advice – or can post useful links – then I’d love to hear!
Regards
G.
I would recommend using a “Multi-Site” setup where you run multiple sites on the same core but each site has its own database and configurations. Modules and themes can be shared across sites but can be activated/selected at the site level. Content, however, is not shared across sites. You can rig Drupal to push feeds from one site to another.
The reason to go with two sites is that Drupal’s access control is unwieldy to manage “areas” of a site for different audiences. The content hierarchy is totally flat. The multiple site configuration will also allow the different sites to independently adapt to the diverging requirements of your intranet and website through the configuration of modules.
Seth, thanks for your informative reply. Our situation is actually a little more complicated: We have our own website & intranet. On top of this, we want to offer our clients their websites and intranets, all under our ‘umbrella’.
I’ve set up a basic experimental multisite Drupal installation here, but rather than the second site being our own intranet, it is the website of our client. I was hoping to be able to set up many of these for many clients. Then, I was hoping to be able to make each site (ours & our clients’) all ‘dual-purpose’, each hosting both website and intranet. As you put it – ‘to manage “areas” of a site for different audiences’. But this now looks to be impossible… Am I correct?
Thanks in advance!
Gordon.
Hi Gordon, you are right. Drupal is not the best tool for managing different areas of a website. You might look into other platforms that have a more hierarchical site structure. On the PHP stack, I know you can do this with eZ Publish. I am pretty sure you can do this with Silverstripe as well. Shoot me an email if you want to discuss.