Note: Initially I was going to call this post "Project Managing Enterprise Portals" but somewhere along the line the post morphed into its current form. I expect this is a topic that I will want to revisit again soon...
In my rather limited experience, I'm finding that SharePoint is often compared against products such as DotNetNuke. I've done it myself. However, the more I'm working with SharePoint, I'm realising that this is a wrong comparison.
Products like DotNetNuke are Content Management Systems (CMSes). They excel at producing web sites that have a distributed content management infrastructure built-in. ie. an administrator can configure certain areas so that business users can readily add content - typically by using a built in text editor (of varying quality) or uploading documents and pictures to a list or library. The content is also typically provided by one person for consumption by many.
While SharePoint certainly does have CMS features, it's wrong to say that it's a CMS. SharePoint and its peers (of which there are only a handful and include SAP and Oracle) fall into a category of its own that could be called enterprise portals. At least this is what SAP calls its portal module (EP - for Enterprise Portal).
Enterprise portals include features to integrate data from a variety of data sources, will have some form of document management service, and will probably have other features as well, including some CMS functionality. Their nature is far more collaborative (many people contributing to the same content) than CMSes are.
Enterprise portals are enterprise systems, on par with applications such as ERP (Enterprise Resource Planning), CRM (Customer Relationship Management) and SCM (Supply Chain Management). It is wrong to compare them to CMSes (as both Bill Simser and Shaun Walker - admittedly in response to Simser - have done).
Enterprise portals are important to a business as they affect the usability of these core systems (eg. ERP, CRM). They allow internal or external users to interact with the core systems without them having to have direct access to it. By not requiring this direct access, security of the core system is maintained. For external users, this means that they can interact with the business without needing to have a specialised client installed on a local computer. They are able to use a web browser and rely on HTTP and SSL to carry and encrypt their data. Additionally, for the business, user support is more contained as custom software does not need to be installed (and supported) on external machines.
The nature of the data usage should also be different in an EP than in a CMS. As stated earlier, in a CMS, the content is created by one person for consumption by many. In an EP, data usage is often also collaborative - ie content is produced collaboratively by many people. The lines between the two categories of product certainly blur: CMSes can do some EP tasks and vice versa but I think there is a difference to be made. Consequently, I also think that the project management infrastructure surrounding them need to be different.
However, I think also that enterprise portals tend not to have the kind of project management infrastructure surrounding them as other ES implementations have, possibly for a couple of reasons:
- They're perceived as just being web sites so can't be that hard to build.
- That they are edge systems, rather than being the core systems that provide the business rules and store the data.
For the reasons above, I cannot say that this is a wise decision. Portal design may often follow a similar process to website design but I'm not convinced that this is sufficiently heavyweight for this class of application. However, project management methodology for an EP is a topic for another post.
Posts
