Peter 2006-06-04 < StructuredWikis LLC

NOTE: The founders of StructuredWikis LLC moved on. The content on this site is for archival purposes only. Please contact the following companies:

Twiki, Inc. for wiki support, wiki solutions and services
-- Peter Thoeny

Evolved Media for content creation and publishing services
-- Dan Woods

The Penguin and The Python for Linux consulting and Python programming

Wiki Applications and The Long Tail

First, what is The Long Tail? From Wikipedia: "The phrase The Long Tail was first coined by Chris Anderson in a 2004 article in Wired magazine to describe certain business and economic models such as Amazon.com or Netflix. The term long tail is also generally used in statistics, often applied in relation to wealth distributions or vocabulary use."

In statistical terms, the horizontal axis of the graph represents a sorted data set (such as words in English language, articles, sales deal, etc.), and the vertical axis represents the volume (number of times used, number of back-links, price, etc.). For example, let's look at the advertising deals of search engine companies. Traditionally, they used to focus on the left side of the graph, e.g. they tried to sell high priced advertising deals to a few customers. Google and other companies started to focus on low priced high volume deals. That is, the sales action shifts to the long tail (the right side of the graph.)

You might be wondering, what the long tail have to do with wikis? Structured wikis are in the long tail of implementing business processes. But how?

Large scale business processes are typically implemented by the IT department, such as to comply with the Sarbanes-Oxley Act, to deploy a CRM application, a traditional CMS, or the like. Those systems have a long procurement and development cycle, e.g. they are on the left side of the graph. On tho other side, teams follow formal and informal workflows to accomplish tasks. This is often a paper-based process, such as rolling out laptops to employees, maintaining a status board of a call-center, or signing-off software for export compliance. The IT department typically has not enough bandwidth to implement lightweight applications to automate those processes.

A wiki lends itself to support evolving processes. First by enabling employees to document processes in the free-form wiki way, with linked pages maintained collaboratively. Secondly, by creating structured wiki application with forms, queries and reports that automate those processes. As we have learned in my previous post, those applications are typically done in iterations - in bazaar-style. In The Cathedral and the Bazaar, Eric S. Raymond compared two different styles in software development, the "cathedral" model of most of the commercial world, versus the "bazaar" model of the free software world. A similar shift happens now when collaborating in a wiki and when implementing business processes. One could say, wikis take care of business processes with an open source approach.

An interesting question is: Who is implementing the applications that support the business processes? A CMS for example is deployed in cathedral-style: User requirements are collected, the system is designed and implemented by programmers, then deployed to the user base. The design is done with a focus on security, and more often than not, this ends up with a solution that is not very customer focused.

When users are enabled to implement and deploy wiki applications in bazaar-style, they are their own customers. Because of that, and because of the iterative approach, they get a very customer focused solution. We see a paradigm shift from programmers creating applications to content contributors with moderate skill sets building applications. A similar shift happened when spreadsheet programs have been introduced to the mainstream. Spreadsheet calculations were once the realm of Wall Street, with highly specialized software and people. After the introduction of VisiCalc, people without programming background were enabled to create spreadsheet programs that solved complex and very specific problems.

My view on "content contributors with moderate skill sets building applications" is actually a bit idealistic. This assumes that structured wikis are as easy to program as spreadsheets. TWiki already has all the Lego blocks, but more work on the usability front is needed. For now, it is often the wiki champions who create the wiki applications, and who coach other users in creating them.

Feedback on this blog? Please send me an e-mail.