Wiki technology is a foundational component for modern Enterprise Architecture practices. It will speed up many aspects of delivery, aide with communications and cut maintenance costs. Using Wiki to good effect is an excellent antidote to the ‘Ivory Tower’ Enterprise Architecture Anti Pattern. Let’s consider some common problems and how the use of Wiki technology can create opportunities for useful Patterns…

Problem Statements

• Enterprise search rankings often make it difficult to understand quality and provenance of indexed content in Enterprise Systems. Community generated indexes with contextualised links and meta data would improve content re-use.
• Unless the Enterprise has sophisticated Enterprise 2.0 tools, there is usually no or limited mechanism for social linking (i.e. community recommended links).
• Team based ideation is often difficult to implement rapidly.
• Inbox overflow (death by email) stifles collaboration and communications. Wiki and other collaboration tools have excellent potential for reducing email volume.
• ‘My content’ over ‘our content’ is pervasive. Wiki has a part to play in breaking down content ownership barriers and ‘not invented here’ syndrome.

Solution Hypothesis

Apply “What Would the Web Do” thinking using simple Wiki collaboration tooling. This leads to a number of interesting Patterns and potential Anti Patterns…

Patterns

The Index

Using inline links in the Wiki narratives, link to good external and internal content sources. Hence an index of content reviewed and recommended by a community of experts emerges. This is essentially a recommendation engine, with deep hooks into other knowledge management sources such as Enterprise Content Management systems. As the link is contextualised in the body of the narrative, the utility increases. Quite often this results in a much more usable index into Enterprise Content (than vanilla search products – although there is definitely a place for both).

The Self Service Kiosk

Self-service kiosks speed time to resolve external and internal queries. The answer to any query (which might be reasonably repeated) should be captured / codified and analysed. This is a useful approach when scaling up teams and freeing up time to concentrate on ‘higher order functions’ such as invention, thought leadership and market influence.

The Bid Engine

Again, like the Self Service Kiosk this is about capturing boiler plate content, win themes, approaches and any other useful content that can be quickly re-purposed. Self-service models can be Anti Patterns if the content is not understood and applied correctly, so always apply the appropriate guiding hand.

The Incubator

Wiki’s are perfect for content incubation, either individually created or created through collaboration. It is a very fast medium to share ideas, test them, improve them, solicit contributions and from which to then cut MS Office documents (or similar). Use a proper content lifecycle, with incubated and polished content eventually being cut into documentation stored in Enterprise Content Management, and using a Rating function (or equivalent) to store review comments and quality metrics with the documentation. This provides anyone searching with important review history and quality assessments.

The Scrapbook

Wikis are very useful for storing snippets, pictures, quotes and other artefacts for analysis and composition into higher quality collateral. Chopping up documentation and restructuring it in a Wiki as a set of questions and answers can be a really fast way to distil verbose documentation into key areas of concentration.

The Ideation Enabler

Wiki can be used for team ideation. It is very simple to post the skeleton of an idea, or create a seed page with a thought experiment or ‘call for fresh thinking’. There are many excellent ideation tools for this, but in terms of speed for small scale team internal ideation, Wiki is also an excellent approach.

The Social Network

As you research communities of interest across your internal estate (be that corporate Wiki’s, blogs, forums etc.) you unravel part of the enterprise’s social graph. This helps surface new connection opportunities and cross-populate each others work on a larger scale (although as Wikipedia does, this requires moderation processes). A Wiki can be an interesting ‘attractor’ for others to participate in your endeavours (be that internally within an enterprise or externally).

The Organic Connector

Enterprise Wikis tend to be self contained ‘universes’ each with singular purpose (if the Confluence model is followed). There could be a significant improvement, if these ‘hubs’ started to connect to each other and cross link. For example Enterprise Architecture draws heavily on Business Change as a discipline and simply creating hooks out to authoritative content on that (and other) subject(s) creates an ‘organic sprawl’ that knits the best thinking and approaches together. On a large scale this is clearly very complex, but on a small scale this would help define and build on and off-ramps from one specialism within the enterprise to another.

The Safety Net

Hardware failure, disk failure, inbox corruption etc. all happen. Having a discipline to harvest and distribute high-value content into a Wiki structure (and other knowledge management tools) helps insure against critical data loss from hardware failure (or other loss).

The Seamless Handover

Exemplary knowledge management with Wiki as part of an architectural delivery approach also helps insulate against efficiency loss during holiday periods, illness, staff churn or simply roll off/roll on cycles which happen on most engagements. Unleashing a ‘full magazine’ of emails to a replacement colleague is less than ideal. Perhaps worse is the monolithic ‘tar ball’ that will take days if not weeks to unpick and understand.

Anti-Patterns

The following Anti Patterns may also arise and must be actively avoided.

Stale Content

Like any website, if the content is not maintained the utility will decay.

Broken Links

The web is organic and so too are internal structures. Broken links may be hard to repair in large volumes (if for example there was a decision to replace the Enterprise Content Management System and this resulted in a wholesale change in URL structures)

Vandalism

Wiki’s can suffer from vandalism, although this is unlikely on an internal platform. There could of course be Wiki Wars or other anti social editing.

Non authoritative content

Wikipedia works by creation of content that has external authoritative references with (some degree) of content moderation by expert editors. Emergence of non-authoritative content should be neutralised by having assigned knowledge champions / community leadership.

Broken Lifecycle

If nothing was ever promoted from the Wiki incubation process to formal knowledge management, the content would not be accessible through a well-established search channel (i.e. the search function with the Enterprise Content Management System). This could create a disconnection problem between internal knowledge systems.

The Jail Break

Protectively Marked content or any sensitive content should only be added to Wiki spaces that comply with security requirements. There should be no use of a Wiki to Jail Break content. There may be a similar argument for the creation and preservation of Ethical Walls, although this could be provided using dedicated Wiki Spaces and restricting access.

Wiki for Wiki’s Sake

As Enterprise Architects we are acutely aware of the Modelling for Modelling sake Anti Pattern. Similarly there is always a danger of drifting into “Wiki for Wiki’s Sake”, where the point of development of the content is lost, and mushrooms into a bloated unmaintainable mess. Further thinking on best practices for ‘Wiki depth and width’ is advised.

Copyright Confusion

Wikipedia has copyright infringement detection capabilities. Obviously using a wiki as a ‘scrap book’ may lead to copyright infringement if content is reused ‘wholesale’ before it is re-crafted. A little care and attention will avoid this, but it is useful to call out the potential downfall.

Authority Abuse

There are many collaboration Anti Patterns, and for brevity these will not be repeated here. Authority abuse however is a potential issue. This requires sophistication in article moderation, although the ‘casting vote’ or tight stewardship of certain content is probably advisable.

Moderation Overload

Moderation overload could occur in large collaboration communities with frequent content edits. There are ways to control this, scaling the number of trusted moderators, limited access to certain content, or more realistically only moderating edits on content which is considered highly important. Emerging ‘leaf pages’ require little moderation where central pages with well developed content require more protection against ‘bad edits’.

Private Islands

Private Islands spring up where local control is desired, where there is no central co-ordination or where there is limited trust and different opinions (aka ‘Not Invented Here’). Wiki is a flat taxonomy (the taxonomy emerges through links, rather than pre-determined structure). This is beneficial, however there is some logical architecture required to structure Private Islands to ensure best reuse across the entire enterprise.

Copy/Paste Design

Re-using stock content without tailoring is a poor choice in almost all circumstances. Monitoring for copy/paste design behaviours (which are negative) is highly advisable.

Summary

Wiki technologies should be part of the smart Enterprise Architect’s delivery approach. Used well, Wiki fosters collaboration, accelerates multi-author content creation and acts as a superb communications channel. Keep a close eye on the emergence of any Anti Patterns and remember that the human factor of collaboration must not be underestimated.