This is the 2nd in a 3-part post representing the culmination of 5+ years of work for my business partner, Roy Youngman and me.
A Quick Recap
Roy and I had become frustrated with the state of management consulting and the lack of “stickiness” with our consulting work. In helping clients develop business-IT strategies and realign their IT operating models, the deliverables we would leave behind as the artifacts of the work (usually PowerPoint slides, Word documents, etc.) rarely became part of the client’s organizational fabric. Another source of frustration was that we’d typically arrive at those deliverables through a series of workshops – usually with the CIO and IT leadership team. Middle managers and the ‘troops’ who had to bring those strategies and operating models to life often did not get exposure to the work until relatively late in the day. Because they had not been part of the work, they were slow to understand and embrace it.
As Web 2.0 and social media began to take hold, we started to see and experiment with better ways to help our clients – engaging broader and deeper participation by client staff, and leaving behind a ‘living, breathing’ IT strategy and/or IT operating model, captured as a set of wiki pages developed collaboratively with our clients. As such, the act of development and deployment became more concurrent. Defining the IT operating model was part of deploying it, and vice versa.
However, we’d found that IT organizational attempts to improve collaboration and support knowledge management typically met with limited success, and that collaboration tools and platforms deployed by IT were falling short. While the power and simplicity of wikis were appealing, their ‘one size fits all’ approach was not well suited to supporting an IT operating model. We closed Part 1 by summarizing the strengths of a wiki, and suggesting that these strengths also create vulnerabilities.
The Proverbial Double-Edged Sword!
A wikis strengths also create vulnerabilities. For example, the ease with which users can create and edit pages can quickly lead to a chaotic free-for-all, as content becomes subject to the whims of authors and editors, and absent a meaningful underlying structure, pages proliferate. The lack of review before modifications are accepted can limit the credibility of a given wiki page as a ‘source of truth.’ A process definition, for example, may have been last edited by someone that introduced a serious error – and that error can proliferate as people refer to and use the process with the assumption that the content on the page is valid.
Sites such as Wikipedia mitigate these vulnerabilities through a robust system of editorial administration, oversight and management – enhanced by the ‘law of large numbers.’ In this case, with a sufficiently large universe of editors, the content of any page quickly converges towards a mean, reflecting “the wisdom of the crowd”. But with an internal wiki – say one used by an IT organization or other shared services function, the law of large numbers does not apply, so without other mechanisms to manage structure and content, the wiki degrades in quality and value over time.
SharePoint as a Common Culprit!
This degradation is commonplace in organizations using Microsoft SharePoint as their collaboration platform. While typically deployed to support collaboration, the reality quickly scales back to “a place to store documents”, which, in the words of one of my clients, soon degenerates to, “a place to lose documents!”
The other problem with SharePoint is that its strength is also its weakness. While it is a good document management system, documents in of themselves are rarely the proper end goal of collaboration. Collaboration is largely about having multiple authors create, evolve and use content, and documents are a poor medium for developing, codifying, and sharing knowledge. Wikis provide a far more valuable alternative approach. As my colleague Roy Youngman noted in his blog:
The nonlinear nature of a Wiki enables well-factored content, thereby minimizing redundancies and preventing contradictions that confuse people. It also allows people to contribute to whatever area of expertise each person happens to have so everyone is drawn in, not just the elite few. A Wiki approach enhances the discovery of knowledge and exposes the subject matter in the greatest need of improvement. And the improvement is a constant theme – the very heart and soul of a Wiki.”
Semantic Wikis to the Rescue!
But all is not lost, as the world of Web 2.0 gives way to Web 3.0, tapping into the special properties of the Semantic Web, a term first coined by Tim Berners-Lee. Tim was the inventor of the World Wide Web and is director of the World Wide Web Consortium (W3C), which oversees the development of proposed Semantic Web standards.
Berners-Lee defines the Semantic Web as, “a web of data that can be processed directly and indirectly by machines.” A Semantic Web goes beyond the traditional web concept of hyperlinked, human-readable web pages by inserting machine-readable metadata about pages and how they are related to each other. This enables automated agents to access the Web more intelligently and perform tasks on behalf of users. As the W3C describes it:
In addition to the classic ‘Web of documents,’ W3C is helping to build a technology stack to support a ‘Web of data,’ the sort of data you find in databases. The ultimate goal of the Web of data is to enable computers to do more useful work and to develop systems that can support trusted interactions over the network.”
In some respects, the Semantic Web is designed to overcome the all too familiar limitations of today’s Web – a proliferation of untrustworthy content that can be hard to navigate and make sense of. Building on the Semantic Web concept and standards, a Semantic Wiki has an underlying model of the knowledge described in its pages, thereby capturing the meaning of the data within the wiki.
While traditional wikis have structured text and hyperlinks, a Semantic Wiki captures and identifies information about the data within its pages, and the relationships between pages, in ways that can be queried or exported like a database. While conventional wikis provide users a simple means of expressing data and metadata, typically through tagging, Semantic Wikis include additional ways to express semantic declarations. They are therefore able to understand and display the relationships between pages or other data. For example, you can declare the underlying semantic properties of an IT Operating Model, such as:
- Processes require people taking on specific roles
- Roles point to specific competencies people must have to fill them
- Competencies comprise specific Knowledge, Skills and Behaviors
- Metrics define process performance
Having these semantic properties explicitly defined enables wiki governance rules and workflows – for example, someone defining a new process will be prompted to define the associated competencies needed for that process, and an appropriate template can be automatically loaded for defining those competencies, thereby encouraging consistency and quality. A simple query can highlight roles that are missing, or identify associates who are qualified to fill a given role.
The graphic below shows a partial example of the underlying semantic structure for an IT Operating Model.