Sebastian points out some things which are helpful in getting you to understand some comparisons, but I will share with you some of the experiences I have had working with intranets and extranets, including companies that have Sharepoint 2.0 and also evaluating the cost of implementing Sharepoint 3.0 (not MOSS) and I think you need to analyse more details of the actual purpose of the intranet itself.
DNN can be built into a huge mess too you know - we work with untangling inexperienced and over zealous IT guys who love the concept of DNN but with their lack of understanding and lack of planning the solution can in fact, build out hundreds of pages that are a nightmare to manage.
Your goal to bring about a collaborative online experience for employees - but what are your expections and ambitions of the site's requirements. This might sound odd, because you've already 'loosely' elaborated what you want, but the specific use will help determine whether the investment of pushing for a Sharepoint 3 solution is in fact the most ideal, or if DNN will effectively help you move forward in a cost effective manner.
In my opinion, Sharepoint is an ideal solution for file collaboration and mutiple authors with different roles to assist in workflows and I guess to a certain extent searching and indexing of content. It works seamlessly with all the Microsoft products, as you would expect and Sharepoint 3 can harldly be compared to Sharepoint 2. However, you back to this point of investment in time, money and learning, DNN may be a worthy option.
We have several projects on the go, like most companies, but one in particular is where we have built an extranet for a global company, where we will have approximately 10,000 users from 18 different countries, with 35+ different brands and hundreds if not thousands of products. It is the extranet of the parent company where we have implemented a virtually off the shelf solution, using only third party modules that exist, with only a couple of things having to be redone because we use a completely compiled version of DotNetNuke and therefore could not utilise modules that ran the app_code folder. It very fast and particularly in administration mode it's extremely efficient and has less calls to the database, giving us better peformance all round.
Now, this is the third intranet / extranet I've built out, and I had an idea on the first one, where I was asked to sort out this enormous mess, whereby the IT guys were not able to to understand how to have 1 build of DNN to run 4 different intranets and let some users shift between the different departments/portals. It was primarily for staff to place procedural documentation, information for staff on processes and connected to a document server - getting it all to run utilise UNC was a bit of a job back then - but they got it all working. When I first received the build to analyse and sort out, it was a huge mess - entwined within iframes - I found it impossible to navigate and so we built from new from scratch, and after spending some time mapping out the structure and purpose, were able to come up with a solution that was well received by the staff and very manageable from the IT point of view and site administrators view.
Back to this project we're currently working on - this is being rebuilt from a huge, messy monolithic DNN 3 build (we were not engaged in the first project) and once again, I went through the exercise with them on the purpose of the site - it seems to me that many many projects have great intentions but still lack the actual purpose of what the site is meant to deliver - so making the right decision is really hard and without control over purpose, it's easy to run away with ideas and build out a mess. The most frustrating thing we inherited was that there were only 1/2 dozen or so roles, the global address book had been clumsily written by the developer with absolutely no relationship with the membership role, so guess what - every name had been put in manually and even if someone left the company, you couldn't delete one of the 1/2 dozen roles, for fear you'd locked out all the employees ... *sigh* stupidity beyond comprehension that set the utilisation of the extranet - and this company thought that was how you had to manage users.
After consultation and analysis of the difficulty they were experiencing, we were able to ascertain the following -
The primary purpose for this company is to provide all the units around the world, a single point of access of information and news from the parent company and help the new staff.
Centralised location for documentation - there were over 1,000 documents, but it's been brought back to aboug 750 documents, still being manually categorised (client has manually segmented / categorised most of the information but has full control over how it's done)and all documents are in more organised locations.
- Welcoming of new staff and providing a location where key important documenation is
- Global repository of images for marketing materials
- Easy to find names, email addresses and physical addresses of staff throughout different divisions around the world
- Allow employees to contribute comments and share information in a central point
- Provide a directory of all the companies listed in a structured, easy to view and consistent manner
- Allow easy administration of the website by none technical staff
We have really worked hard on porting the old information from the DNN 3 portal (some exported but most copied and pasted so we could implement consistent presentation)
We also had to take content from many of the existing sites around the world to help pad out the content somewhat since our method of building out the portal reduced the pages by about 400.
Currently there are are 20 testers giving us their feedback, and upon the site being deployed, every employee will receieve their login (either their email or employee number) and password, and will have their roles preassigned, so the release of the site will be fairly straightforward.
If you spend the time mapping out what you want the site to be, and it's more than document collaboration, you have a good case to utilise DNN. We will be running this extranet along side our live sites - we push abou 500gb of traffic through our server at the moment and it can handle more, but if it's showing signs of performance issues, we'll drop it onto another machine.
The fact you're able to utilise AD will help you tremendously because I found the biggest challenge we're going to have is finalising the system of employee management with a global company and no distinct relationship between HR units around the world (each is handled locally to suit their laws) we are still working out how to fine tune it. You see, each country has it's own intranet too, some on Sharepoint, others with different CMS products or static, or none at all, and the extranet has a different purpose to the intranets.
I modelled some of the solutions based on the Campbells company - as it was the closest to reflecting the product brands, the countries, staff and purpose. It was based on articles about intranet deployment and development I purchased and was really glad to see that DNN was in fact a viable option as they were discussing whether to utilise Sharepoint, but again, the cost for extranet as opposed to intranet really made DNN seem very appealing.
Currenty it's a 4.8.4 build, but in the next couple of weeks, I hope to be testing our completely compiled version of DNN 5, which we may choose to upgrade to before it's release, if we feel there is benefit, otherwise we'll keep it running on 4.8.4 till such time that an upgrade is required, and because we've built this from off the shelf modules, it's upgrade path is cost effective and practical.
I hope this gives you an insight on the use of DNN for intranets and extranets - but please spend the time in analysing it's purpose so you can make the correct steps and NOT build out a monster like I've had to handle on several occasions.
Nina Meiers
http://www.xd.com.au