DBAs need to take control of Wikis

Delivering cost-effective and maintainable content is not easy. Companies have spent literally hundreds of millions of pounds worldwide on websites, content management systems (CMS), hosting sites and bandwidth. Despite this, many companies freely admit that they have a problem with ease of use and the cost of running their websites.

It is not just websites that can be difficult to maintain. User manuals and help files vary from the almost useless to complex documents that take a lot of time, money and people to maintain and which, inevitably are out of date before anyone gets to use them. The same is true of troubleshoot and self-help systems that were originally designed to reduce the load on the support teams.

Into this comes a technology that has been around for over 16 years but which has only come to the fore in the last 8 years – the Wiki. Many people associate the word Wiki with Wikipedia, the online encyclopaedia and more recently with Wikileaks, a site infamous for publishing information from whistle blowers.

What a lot of people don’t realise is how widely used Wikis are. Organisations as disparate as the CIA, the EU, Apple and EMC all use Wikis. The latter are two of the giants of technology and both use Wikis to improve their customer facing processes. The way Apple uses a Wiki goes something like this:

You file a possible bug or fault with Apple via the website. That report goes into a Wiki which allocates you a case number that only you and the support team can access. When the report is allocated to an engineer for actioning, it moves into a private Wiki, accessible only inside Apple. Once the issue is resolved, if there is information in there that needs to be made publicly available to other Apple owners, it is published to another Wiki.

All of this is simple, easy to use and contains enough controls to ensure security of data and that nothing is published without being approved. EMC are apparently planning to go down a similar line and there are a host of hardware and software vendors whose online help systems are also held inside Wikis. This allows them to publish new help documents and link them to older documents very quickly. The entire help system can even be pushed down to the local machine.

A similar thing is happening on the corporate Intranet where the Wiki is being seen as an easier way to engage users and get more content online and without the cost of specialist writers. This sharing works well because a Wiki is effectively a lightweight collaboration suite. But inside the Enterprise it is increasingly coming into conflict with heavyweight collaboration suites such as Microsoft SharePoint, Oracle Beehive and IBM’s Lotus Domino.

Almost all Wikis use a database to manage their indexing and search functions and increasingly they are storing content inside databases. However, unlike the larger collaboration suites, Wikis do not maintain all the content inside the database and the most popular database is MySQL. Where content is not stored in a database it ends up as a large number of separate files in the files system. Contrast this to the bigger collaboration systems which import content as blobs into database fields and you get an immediate difference.

There is another, more important difference. We live in a world that is increasingly dominated by regulators, compliance and legislation. Being able to control access to data is central to the management process yet the shared community all access approach of the Wiki runs counter to this security. There is no fine grain approach to securing each individual document or simple way of creating a flexible user access hierarchy integrated with your directory and domain services.

The closest you have to management is the publishing process but once published the document is available. This is where companies that are interested in the use of a Wiki to replace their existing database driven dynamic websites need to think carefully. For many, the solution is likely to be a set of tiered Wikis with one master copy serving content out to a variety of sources.

A key area for this is in the supply chain where you might want to show stock levels, provide access to product literature and allow all your customers to access marketing materials. This is certainly a much more flexible approach than many of the complex systems used by a lot of companies.

Another issue, potentially just as serious, is that of backup, restore, business continuity and disaster recovery. Dealing with a single database is fine but managing hundreds or even thousands of files is something much more complex altogether. The solution here is to put each Wiki, just like each database, into a virtual machine (VM). This will allow you to simply snapshot the VM and then restore it when necessary.

DBAs need to take a long look at what Wikis are running in their organisation and how they can apply better management and process to them. This will not be easy as they are not considered part of the standard enterprise software library and any DBA attention could well be seen as trying to complicate a simple system.

The advantage of DBA involvement, however, should outweigh such concerns. More importantly, given that the DBA has a view of all the other database driven projects inside the organisation, it may well be that there are other projects that would benefit from being created as a Wiki rather than as a database.

Examples here would be to follow Apple and build your next Help Desk solution inside a Wiki. You could expose all the corporate training materials to users as part of a self-help system and release updates very quickly without the need to code.

The Wiki is here to stay and the DBA needs to take control.