Wiki in the Enterprise

Social Technologies like Blogs and Wikis which are already popular on the consumer Internet have steadily been making inroads to the other side of the firewall as well.  Everone from Large enterprise clients to small companies are already using these with varied success rate or are considering using these technologies/tools.

So if you are one of those considering implementing a wiki, it is important to understand all the aspects related to not only technology but also the impact a wiki can have in terms of organization and other “softer” issues. J. Boye, have just published a new research, Wiki in the Enterprise which will help you understand just that.

The report presents a balanced perspective on the benefits as well as challenges. For example, everyone knows that a wiki can help improve productivity when used as a centralized repository of common information and questions. However,  the report goes a step furthur and suggests what actually needs to be done to ensure this. There are best practices and recommendations for implementation as well as adoption. A project check list and another list of major wiki vendors are also quite handy to kick start your initiatives.

I would have loved to see some more details on different wiki vendors and how they compare with wiki offerings of other products (Portal, CMS). But may be that is a subject of another future report?

Delivering Portal and CMS as Service Part 2

Tenant Specific Content

Okay the next issue to be aware of is about how actually the content is stored. So let’s for the sake of simplicity assume the content is a “News Article” with fields like Headline, Byline and Body.

A very good article on issues related to multi tenant data architecture is here. This article explains data architecture in terms of databases, schemas and tables. The same architecture principles will also apply to a more generic CMS repository which may not be based on a database. The CMS can store the same content for multiple tenants in multiple ways. It can either have a completely independent repository for each tenant. It can also use the same repository for all the tenants but with some kind of logical partitioning. I think Alfresco uses this mechanism. And finally, it can use the same repository for all the tenants without any partitioning. In this case, Tenant -> Article ownership is identified by some other mechanism. A possible way is to have a field like tenant id (along with Headline, Byline and Body) that identifies the tenant.

Each of these mechanisms have their advantages, disadvantages and associated costs. There is a trade off between security and costs.


Apart from tenant specific administration (or Federated admin), the application needs to provide capabilities like:

  • Provisioning
  • Billing and Metering
  • Management, Monitoring and Reporting

So some kind of delegated administration and centralized management application is required that enables assigning administrators for individual portals (or applications) and then Monitoring (and managing) these individual portals.

There are also issues related to Tenant Specific Security. More about that later…