Where did the Semantic Wiki go?

Last week I looked at Atomization of applications to enable the construction of new processes. Atomization is the de-construction of applications in to re-usable components that can be combined to create new solutions. I see this as important because I believe we are entering an 

era in the Enterprise where the 80% application will emerge. What do I mean by this? 

Agile development methodologies have been adopted by some organizations to improve the delivery capability of the IT department. Instead of developing all encompassing applications Agile delivers solutions incrementally. This has the advantage of just developing the code that is required where as the traditional waterfall development leads to catch all requirements inclusion which is often driven by the long development lead times, which is driven by the need to code for all eventualities, which is...... and so it goes around in a vicious circle.

But there is a new game in town. Users have become familiar with drag and drop widgets and personal web pages that can be adapted to their needs. The growth of RSS has also provided a triggering mechanism that has been put to use by some people to drive processes. This new world, when coupled with the atomization of monolithic applications is creating new opportunities to meet the demand for transient applications. The Wiki has an important role to play in this new world.

I see wiki technology being adapted, through the use of widgets to provide crude workflow capabilities that can be built by end users without intervention or support of an IT department. We are already seeing this in the consumer sector with services like Yahoo Pipes.

Gartner has pointed out how business is changing and we are seeing applications becoming disposable. The "80% application", based around wiki technology are the potential manifestation of the disposable apps that Gartner points to.

My definition of the "80% application" is a simple application that is built from modules of code and glued together with data feeds using standard services like RSS. The "application" is basic and can be constructed in a matter of hours and can meet 80% of the functionality required by the users. Wikis provide the ability to deliver this capability in a matter of hours to a point where a prototype can be demonstrated. These applications will filter and extract information and present it to users. There may still be a strong element of manual processing but the heavy lifting of compiling the data to be worked on will have been automated.

The "80% application" is good enough to support emergent coordination and new workflows but not so good that users aren't prepared to throw it away for a better, more complete solution.

In the context of all this the Wiki needs to evolve with critical semantic capabilities built around emerging microformat standards. We should be looking to Enterprise Wiki vendors to be delivering widgets that can be incorporated in to Wiki templates. These widgets can provide containers to add semantic context to the data being entered by users. For example, a widget to embed address formating that makes address information hCard compliant. It is this type of development, utilizing a growing range of microformats that can turbo charge the enterprise wiki and support the 80% application. 

Taking text entered in to a wiki to the next level by embedding machine interpretable meaning  around that text opens up a world of new possibilities. Imagine machine interpretable data being delivered to a simple workflow process by an RSS feed. The ability to act of wiki text becomes dramatically enhanced. 

I have been getting increasingly interested in the potential of the Semantic Wiki but it looks like the Semantic Wiki has remained stuck in 2005 as an academic issue. I would love to be proven wrong by some of the major enterprise wiki players. Come on, show me that the Semantic Wiki is a reality and is busily embedding machine interpretable content in to the every growing number of wiki pages and sites that users generate every day. 

So, SocialText, Atlassian, Near-Time and other wiki developers show me the Semantic Wiki is alive and well and not just an academic exercise.

Everything you might not want to know about Sharepoint

Gartner's  Karen Shegda reviewed Microsoft's swiss army knife product which is Microsoft Office Sharepoint Server (MOSS) 2007.

The new features are wikis and blogs plus people search.

Content management had major updates and records management to keep DoD happy (Dod 5015.2).

The MOSS is not seen as an Enterprise Content Management product. MOSS builds on Windows Sharepoint Services (WSS) and on top of basic Windows File Services.

The MOSS portal provides Search, personalization, news, presence and calendaring. We will see Sharepoint increasingly integrated in to the Unified Communications Server stack.

The claim is that team collaboration is a sweet spot with team sites, task management, wikis and blogs. However, from what I have seen of the Wiki capability it is still well behind the curve in comparison to other wiki products such as Socialtext.

One content management gotcha is that compound documents are not handled by Sharepoint.

MOSS has multi-layered security. Site administration, Service administration and central administration.

Integration of MOSS depends on your level of commitment to the Microsoft Ecosystem. However, I have seen instances where things like datasheet edit capabilities get disabled if you have a mixed Office 2003/2007 product set. For example Office 2003  with Project or Infopath 2007. Beyond the Microsoft Ecosystem integration is required. Like a lot of Microsoft software - you can make it do just about anything - provided you want to sit down and cut plenty of custom VB or .Net code.

My experience is also that you need to buy in to the Microsoft stack. Don't try running Sharepoint using Safari on a Mac. If you want to run FireFox on Windows you are best to install the IeTab add-on for Firefox that basically run Internet Explorer inside Firefox.

Succeeding with Sharepoint

• Set up governance
• Set a policy on the life of team sites
• Develop a high-level common taxonomy. This is especially true in compliance-controlled environments like Financial Services and Healthcare.
• Create an approval process for sites
• Build a library of useful templates and third-party tools
• Determine who owns the user experience for different classes of users

Some third party tools bridge Sharepoint Gaps

Quest software - management tools

Infonics and Syntergy - replication tools

F5 Networks and Riverbed - WAN Accelerators

Casahl - Content migration

Don't overlook the substantial supplemental costs:

• Additional database licenses
• internet server for public sites
• Office 2003 or 2007
• MOSS requires a standard or Enterprise Client Access Licence (CAL)
• For offline access to Sharepoint you will need Groove desktop clients

First steps

• develop your content management strategy before acquiring technology
• Focus on people and behavior. Fit tools to the process. Don't bend processes to the tool.
• Prioritize for flexibility. Avoid monolithic design. Build in a modular manner.

Sharepoint and Content Management

One part software and four parts professional services. In other words there is a lot of custom integration required.  

What is the difference between collaboration and an Intranet. Collaboration is dynamic and often real-time, two-way and asynchronous. The Intranet still tends to be a one-way publishing paradigm.

Sharepoint and Document Imaging

Sharepoint is only suited to lightweight document imaging and workflow. It is not designed for heavyweight transactional document imaging applications.