StartupSpot

Enterprise 2.0 and the Debate about Technology and Control

Ross Mayfield, CEO of Socialtext, makes a number of excellent points in his article Enterprise 2.0, SoA and the Freeform Advantage. His article explores the potential debate about the issues of technology and control:

If there is debate, it will be on two fronts: the role of organizational identities (Egalitarian) or an emphasis on technology over social dynamics.

He quotes Andrew McAfee on the second point:

Programmers could build fully-functional wikis, blogs, tagging systems, and prediction markets by carving them out of solid COBOL and serving them through the first Netscape browser. They'd be clunky, but they'd work. And I bet they'd draw users, too, because they'd tap into our desire to use technology to interact with each other, and also tap into the good stuff that emerges when we do so.

I agree completely with this point. I think Web 2.0 has a lot more to do with concepts like emergence and self-organization than it does with a snapshot of the current technology in vogue.

And he makes a strong statement of his own on the first point, which I endorse:

Every sacrifice made for sake of control reduces network effects, assumes a static environment you can design against and is designed by supposed experts outside the context of use. Contrary to the most disruptive pattern of social software -- sharing control creates value.

While I agree with his primary points I would argue with certain aspects of his examples.

I don’t think the mere existence of granular access control is the cause of the problem. I think the real problem, as he pointed out is the model where a supposed expert exerts control outside the context of use. But for example, I think freely mixing single author and multi-author wiki pages increases the opportunity to leverage the advantages of a wiki without causing the problem of inappropriate control. Allowing authors to create a “single author” page that’s not open for edits is not the same thing as exerting control outside the context of use.

Examples of single author content that’s often shared in a wiki include:

• A press release
• A letter from the CEO
• Pricing information
• Explicit operational instructions from a customer or partner

I would also make the same point about simple workflow and templates. Workflow and templates can be used for control and they will have the negative impacts he suggests but they can also be used to simplify user contribution. For example, it’s extremely common for a new wiki user to copy an existing article and then edit it as a way to get started. Giving that user both the option of a blank page and a choice of templates to start from increases their freedom and ability to contribute. A good example of positive structure is wikiHow and we’ll certainly see more such prominent examples in the future.

Below are some examples of how I think workflow and templates can increase user contribution and emergent behavior

• Question and answer workflow as the basis for a new wiki page
• Simple workflow such as the “draft mode” concept which can encourage people to contribute partial ideas that they explicitly want help with
• Providing optional templates and forms to help people with new articles

To me the core wiki principles that Ward Cunningham outlined such as Open, Incremental, Organic, Observable, etc. are still prescient and provide valuable guidelines as wikis gain prominence within the Enterprise. Those original principles provide some very specific guidelines but they don’t prescribe the features or technologies that are appropriate to support those principles.

Enterprise Wikis: Bridging Communications and Publishing

Enterprise wikis bridge two major functions: communications and publishing.

Communications
On the communications side wikis operate in the same space as email and instant messaging products. Obviously they are different but they all enable web based communications.

Publishing
On the publishing side wikis operate in the same space as portals, web content management and knowledge management. These products operate on different principles but they all have a significant publishing element.

Understanding these two distinct aspects of wikis is important at two levels. One is the functional level and that has to do with how wiki software works and the other level has to do with how they are positioned relative to other applications typically found in large organizations.

Wikis bring communications and publishing together
One of the big problems with traditional publishing solutions such as, for example, knowledge management is that they require people with expertise to do additional work to share their knowledge. And not only do they require additional work but they often require a layer of control and gate keeping that adds insult to injury. As a result both acknowledged and informal experts have balked at using formal knowledge management systems. With wikis, the ideas behind knowledge management are finally implemented in a way that works.

Wikis improve on previous generation solutions in a number of ways:

• The same application can be used for communications and publishing, avoiding duplicate effort
• Wikis are self-organizing, making them more agile and adaptive
• Wikis focus on efficient contribution and editing, often doing the same work with half the steps
• Wikis openness encourages contribution from a wider, more diverse group

Getting better at communication, getting better at publishing
Wiki vendors must stick to the core principles that make wikis different from existing applications such as being open, self-organizing and feedback rich, but as wikis become more pervasive in the enterprise there is plenty of room to innovate and improve on the core functions they provide.

Improving wiki communications:

• Tighter email integration
• Improved ability to create groups and invite participation
• Simple communications workflow

Improving wiki publishing:

• Templates and forms
• Improved navigation and search
• Tagging
• Increased ability to personalize the look and feel

Wikis: Improving on existing solutions and inventing new ones
As wiki vendors continue to make inroads in large organizations wikis will, in many instances, begin to replace email as a communication and collaboration vehicle. Email will always have its place but it performs poorly for persistent group discussions.

Wikis will also take over many knowledge management and content management functions. Traditional content management applications aren’t going away but there are many publishing and knowledge sharing applications that could be improved by a less hierarchical and more adaptive model.

Even more important than the instances where wikis improve on the tools of today will be the usage scenarios that haven’t even been thought of yet. With wikis users can invent new uses and solutions on the fly and since wikis are agile, adaptive and feedback rich they can grow and change with the changing requirements of enterprise users

Wiki Software and Enterprise 2.0

There has been a lot of discussion lately about wikis and Enterprise 2.0. Much of this has been excellent but it has mostly been at a business or strategy level. I’d like to discuss how I think wiki software needs to adapt to be effective in an Enterprise environment.

Wikis can benefit from structure

One thing I’ve found in our wiki implementations with Fortune 500 customers is that wikis often benefit from more structure in the corporate world. Now I know that may sound counter to wiki principles but it doesn’t have to be. Structure is not the same thing as control.

In order for wikis to be self-organizing (this means agile and adaptive for those who want this in business terms) they need to leave control up to those who have the expertise and insight, rather than hard coded experts. So wikis can have more structure and still be self-organizing.

This structure can come in the form of any easy way to save articles templates. Or it can come in the form of basic, adaptive workflow that captures an email dialog and transitions that dialog into a wiki page when the dialog is relevant to the group.

Wikis and basic workflow, templates and forms

I know workflow has a bad reputation with wiki enthusiasts because it’s often associated with control and gate keeping. This may often be true but it doesn’t have to be. Simple workflow can be a way to jump start participation in an enterprise wiki. For example, if a corporate sales force is being introduced to a wiki giving them a structured way to send a question to the sales support team if they can’t find the content they are looking for is an easy way to get them involved with the wiki without having to learn anything new. And giving them a structured form to create new wiki pages is another way to add definition to the wiki and make it easier to learn how to contribute. For example, a template or form for a competitive profile can make it more likely that someone will take the time to share this information. It also makes it easier to create a stub article and build on it. If someone wants to start sharing information about a competitor they could start by just filling out the name and basic information and letting the group fill in details on an incremental basis.

What is an enterprise wiki?

I’ve seen many attempts to answer the question “what is a wiki?" Many of them are very useful. But I’d like to take a shot at answering that question from an enterprise perspective.

The reality is that wikis need to be understood in the context of how large organizations work today and the tools that currently support them.

When we talk to big customers and prospects, even though we see ourselves as fundamentally different, we often get asked about how we relate to existing enterprise software such as content management systems from Vignette and Interwoven or portal solutions such as Plumtree and SharePoint or even knowledge management solutions from vendors such as Knova, RightNow and Kana.

These systems are obviously different in scope and architecture from our enterprise wiki but I think it’s fair that we get questions about these vendors. Wikis and traditional enterprise content management and portal solutions have content creation and communications as core functionality.

What makes a wiki so different from these traditional systems is that they are optimized for speed and rich feedback. Wikis are not just content management systems with an edit button on each page. Wikis are designed from the ground up for speed and this is vital to their success and it is big part of the difference between wikis and traditional enterprise systems.

This is also why I’m very skeptical of the idea that traditional content management and portal vendors will “add wiki functionality” to their applications. That idea doesn’t work because a system cannot be optimized for two different goals. For example, a Porsche is designed for speed and a Ford F-350 is designed for power. They are both good at what they do but trying to optimize the Ford F-350 for speed would be a bad idea and would never match the performance of the Porsche.

In addition to being optimized for speed wikis are optimized for rich feedback. This makes them highly adaptive which leads to the creation of an information resource that is very relevant and very up to date. The open editing and discussion features that are core to the wiki design help ensure that the content produced is constantly adapting and benefiting from new feedback. This approach is directly counter to systems that focus on control and hierarchy.

In an enterprise environment wikis still need the ability to ensure accountability and compliance with corporate rules and legal requirements but they are designed to do this without sacrificing the core design principles of a wiki.

In some cases enterprise wikis will completely replace an organization’s existing content management and knowledge management technology and in some cases they will co-exist. In today’s fast changing and highly competitive world optimizing for speed and rich feedback is often a very wise choice.

So from an enterprise perspective one way to answer the question “what is a wiki?” is to say that it’s a next generation content management (or knowledge management) solution that acknowledges the enterprise’s requirements for accountability but that is optimized for speed and rich feedback.

Building rapid learning, rapid response organizations with CustomerVision wiki, blog and RSS technology

Today the best companies can make decisions almost instantaneously. When something happens in a store or a field sales office the key decision makers are made aware of these developments and can make a decisions that get communicated back to the field just as quickly. Nobody meets this ideal all the time but this rapid response cycle is becoming an increasingly critical success factor in any business.

Businesses with the shortest response cycles have a significant advantage over their slower, less aware competitors. These short response cycles allow a business to respond to the market faster and provide superior products and services.

Not only are market conditions changing faster than ever but they are also harder to predict. Customers are better informed and more demanding than ever and word of mouth spreads at unprecedented speed. As a result, central planning and strategy becomes increasingly difficult. The only way for businesses to deal with this rapid change is to transform themselves into communities that constantly reinvent themselves by continuously learning and adapting as the business environment changes.

Guidance for Management

In order to build this new rapid learning, rapid response environment management needs a new set of principles.

• Employees must have a core set of rules that guide them in using the system
• Employees must share more information
• Managers must receive more feedback from the field
• Managers must be more effective in communicating strategic objectives

Tools to Support This New Environment

This new environment would also be impossible without a new set of tools. Important new developments on this front include: wikis, blogs, RSS and improved search and feedback mechanisms.

Wikis

Wikis are a new innovation that can form the backbone of this highly adaptive learning environment. Because wikis are so open and adaptive they come with a set of rules that surround them and help ensure they produce effective results. Though wikis are designed to support open contribution they still support the idea of privileged users that help settle disputes and enforce the rules of the community. Wikis create a critical resource that is constantly changing in response to changing market, competitive and customer conditions. Information can come from anywhere in the organization and can be checked and improved by everyone who uses it.

Blogs

Blogs are another method for improving information sharing in the business world. Internal blogs differ from wikis because they are the voice of an individual instead of a group. They are also often more personal and more opinionated. They are an excellent way for experts to document and share their knowledge. Blogs can also be an excellent source of information for a more official source like a wiki. Blog posts that have lasting interest and relevance to a larger audience can be transitioned into the wiki format so that they can be verified and enhanced by the entire user base.

RSS and My Place

And finally a new development called RSS makes it possible to distribute information much more efficiently. The organization can deliver a customized “My Place” style desktop that uses RSS to populate a custom home page with constantly changing information feeds that reflect the interests of the specific organization, team or individual.

Search, Feedback, Integration and Navigation

Critical enabling technologies such as wikis, blogs and RSS need to be surrounded by a handful of supporting features in order work effectively.

Search is a critical element to any information space as has been demonstrated by the success of search companies like Google.

Discussion functionality is absolutely critical in creating an adaptive, feedback driven resource. Participants in the system need to know how the community is responding to their contributions and they need to be able use this feedback to direct their participation. Other key feedback elements include popularity rankings, related links, granular alerting, and a method for showing recent changes in the system.

Integration with existing information resources is also critical to this kind of resource. The term integration can bring up the thought of all kinds of complex integration schemes but at its most basic level integration can mean making it easy to get information out of existing common information sources and into the system. For practical purposes two of the most common information sources are people’s email inboxes and their collection of personal documents usually found in a format like Microsoft Word. So a key starting point on integration is making it easy to transition information from email and Word into the system. The ease of use of wikis make it easy capture emails using cut and paste and if you add a Word Import feature you have a solid basis for transferring information from an unstructured environment to a more structured, shared environment.

And finally a navigation engine is critical to provide a framework for the site and to support a method browsing the system for information.

Participation

The final element needed to tie all this together is participation. None of these tools mean anything without the trust and participation of the community. If only a handful of people use the system then it will never reach its potential. But if management leads by example, encourages experts to share, and gains the trust and participation of the broad user base then the system can provide unprecedented improvements in the knowledge and decision making of the organization. These advantages are the key to an organization’s long term competitive strength and success.

Conclusion

The implications of this approach are nothing short of revolutionary. Empowering the entire organization to share and contribute is breaking new ground for many. But paradoxically this is only way organizations will maintain control of their position in the market in the long run. Tomorrow’s winners will be those that have a constant pulse on their markets and their customers and those that stick to their top down methods will be swept away by those same rapidly changing market forces. So join us in embracing a new vision for market driven organizations that learn and respond at the speed of the global marketplace.

CustomerVision at Recent Changes Camp

This week a number of people from the CustomerVision team, including Cindy Rockwell, Cliff Monlux, Tom Wynne and myself, spent some time together in Seattle and towards the end of the week we went down to the Recent Changes Camp in Portland.

It’d already been a long week for us so we only managed to get in one day at the camp but it was great to spend time with some of the movers and shakers in the wiki world. We got to touch base with an old friend Ray King, participate with the inventor of the wiki idea Ward Cunningham in a small group session, and meet some of the other great entrepreneurs in the wiki world such as Mike Cannon-Brooks and Jonathan Nolen from Atlassian and Michele Ann Jenkins from Wikitravel.

A couple of interesting sessions we attended include Managing Large Scale Wikis convened by Ward Cunningham and A Pattern Language for Wiki Adoption convened by Mike Cannon-Brooks. Our CEO Cindy Rockwell convened a session on Bringing Wiki Passion to Corporations.

I was quite impressed with how effective the Open Space meeting format was. For anyone who has spent much time in corporate America the Open Space format can seem like chaos when you first see it but it ended up producing an agenda that was highly relevant and tightly aligned with skills and interests of both the presenters and the participants.

The CustomerVision Approach to Wikis

I recently had a conversation with Ray King, who’s very involved with the wiki world including the RecentChanges blog, ICANN Wiki and the upcoming RecentChangesCamp. I was telling him about our vision for delivering an Enterprise Wiki suitable for use by Fortune 500 business customers. He came back to me with a few questions about how we are different from the many open source wikis available. And he also wanted to know what made our solution uniquely suited to corporate use. I gave him a fairly brief answer that outlined my experience with corporate customers what I felt was unique about our approach. This conversation got me thinking about documenting in a little more detail what our approach is, how our thinking has evolved, and where we are going.

To begin with in this article I thought I would outline some of the original ideas that went into the design of the CustomerVision “Business Wiki”.

When we first thought about the design of our wiki we decided to build a product that sticks to the core concepts that have made wikis so effective while still creating a product that is easy for people who are not tech savvy and who may not even be early adopters.

Wiki concepts that we felt had to be there

• One click editing - It may seem like stating the obvious but we felt this is the starting point for a wiki.
• Roll back - It turns out making it easy to role back the small number of mistakes or disagreements is a more productive model then putting up a bunch of gates and fences to stop anyone from the possibility of doing something wrong.
• Recent changes – This is a concept that isn’t always obvious to new users but it’s very important once a wiki develops an active user base. Recent Changes makes it easy to instantly see what’s happening and who’s active.
• Discussion – This is another concept that’s much more important than most people initially understand. The discussion area and the "give and take" that happens around an article isn’t just a supporting feature – it’s critical to the value of the wiki. The discussion area often drives some of the most valuable learning and communication.

Concepts that needed a fresh approach for our customers

• Wiki script vs. WSIWYG editor – I know that wiki script is simple and clean and very convenient once a person gets the hang of it but we felt a good WSIWYG editor was still the fastest way to let non-technical users build and edit content. This approach has been taken by a number of wiki vendors so it should not be a huge surprise.
• Wiki linking vs. List view, Category menu and Search – This is probably our biggest departure from a conventional approach to wikis. Many people consider wiki style linking to be just as important as one click editing when it comes to core wiki ideas. But it’s my feeling that wiki linking and naming issues can cause both short term and long term complexity that's challenging for non-technical users. Many of the initial users of wikis were software developers and they're very familiar with the concepts behind naming and creating relationships. These ideas are obviously very flexible and powerful but they can also be very complex if you don’t already have that mindset. At CustomerVision we took an approach allows someone to create a page or article then place that page based on its category. We also make search and navigation easy and intuitive so that pages can be organized, found, browsed and re-organized without the conceptual overhead of page naming and page relationship building. This is an area were we may end up supporting both approaches. We’ve been very happy with the results of our Category, List View and Search driven approach but that would not exclude providing traditional wiki naming and linking as well.

Features we felt should be added

• Simple content management – Provide the tools so that an end user can build a wiki that looks like a standard, attractive website.
• Simple workflow – Sometimes workflow is a "must have" for a corporate environment. CustomerVision provides simple workflow for those that need it without adding any complexity to the wiki performance. The workflow can be activated on a full or limited basis but if you don’t need it it’s invisible.
• Templates and forms – This is another addition that’s critical for the customers that need it and invisible to those who don’t need it. If you have a standard article type or stub that can form the basis for a new page then you can save that as a page template. This could be a standard format for a competitive review or for documenting a best practice. The form builder feature makes it easy for someone to create a form to get specific structured feedback. We also provide the ability to manage and route that feedback and to author and send responses when appropriate.
• Granular permissions – If the permission system is turned on users can create anything from a simple, two tiered Visitor vs. Member permission system to a complex hierarchical arrangement that supports groups like Employees, Field, Partners and Customers, including subgroups beneath the major groups.
• Advanced options for articles – This includes things like a Summary Field for List View, Related Links and Page Expiration.

The final element that needs to be mentioned is building an organization that’s designed to sell to and support large corporate customers. This part is easy to overlook but mainstream business adoption will not happen until large corporate customers can work with an organization that also provides the sales process, training, support and service required to ensure successful adoption.

From my knowledge of the marketplace CustomerVision, along with Socialtext and Atlassian are fairly unique in having a specific focus on providing the features, training and service infrastructure to implement wikis for use by business customers in a Fortune 500 company. And I’m talking about the kind of implementation that’s used by a full business unit made up of non-technical sales and service people. While there may be a number of Fortune 500 companies with active wikis in IT and development groups, the requirements for successful implementation in a business unit are very different.

Understanding the Wiki Market

Corporate customers looking to implement a wiki for a mainstream business application may face a bewildering array of choices. In order to help make the landscape more understandable I’ve created a brief overview of some of the different wiki options.

Open Source

The wiki concept started with an open source model and there is still intense activity in this space. Wikis were originally created by developers for use by other developers and that is still probably the most common use for them today. But as a result these wikis are often very technically oriented. Many of these open source wikis work best in the hands of someone who is comfortable with complex scripting and naming conventions.

There are many examples that fit into this category. A few of them are listed below:

• MediaWiki
• PmWiki
• Twiki

Consumer Wikis

A new breed of hosted wikis is emerging. These wikis are designed to be created quickly and accessed over the internet. These are good for small groups whether they are ad hoc public groups or a small team within a larger organization. They usually tend to include a community element.

Examples include:

• EditMe
• Seedwiki
• Wikispaces
• Jot

Enterprise Wikis

Enterprise wikis are designed to be deployed by an entire corporation or a department in a large organization. As a result they need to take into account security, access control, and segmentation through more granular control of where and when wiki collaboration can take place. They also need to be backed by an organization that is designed to support a large corporate implementation. Getting a small team engaged with a workgroup wiki is a very different proposition from getting a 50 person sales support team and a 6,000 person field sales force sharing information in a corporate environment.

Examples include:

• Atlassian Confluence
• CustomerVision
• Socialtext

Best of breed Content Management provides targeted solutions for targeted needs

A common question that business managers and IT leaders face is how much to standardize when it come to vendors and product functions. The idea behind standardizing on one vendor for all a companies content management needs is that it will create efficiencies because IT only has to deal with one vendor and business units are all using the same interface so training and support can be the same for the entire organization. The argument is compelling on the surface and has obviously been encouraged by the handful of large vendors that can supply a broad “one size fits all” solution.

Content Management in practice

In practice the idea of standardizing on a “one size fits all” solution has not worked out exactly as described. There are many instances where a one size fits all solution does not solve a given business problem. Content needs comes in all different shapes and sizes and solutions that are designed to meet a wide variety of needs are by definition not going to be the best for every specific need.

Content Management is not like other IT functions

One of the things that have driven the interest in large “one size fits all” solutions is the fact that centralizing other IT functions has proven to be effective. This is the thinking behind big ERP systems. Data warehouses have also proven their worth. But content management is actually not the same as these other IT areas. Content management is fundamentality about communications more that is about number crunching or transactions. So consolidating content management functionality makes it difficult to meet the needs of individual groups with special interface, collaboration and deployment needs.

Emerging technologies to support diverse content management solutions

Organizations are starting to recognize these issues and gradually the pendulum is swinging back towards providing targeted solutions for targeted needs. This doesn’t mean though that companies will put up with having too many application silos. What is required in the future is a distributed architecture where diverse, targeted solution can share information or can be accessed by a common dashboard. Emerging technologies such as RSS and tagging are also gaining acceptance in corporate environments and make it much easier to create a distributed content management environment in which specialized, best of breed solution work together to provide a platform that meets the unique needs of teams, departments or an entire organization. Best of breed solutions connected together with new technologies like RSS can provide a unified view of the content and communications that are the lifeblood of the modern corporation.

The New Model for Web Content Management

I think web content management is incredibly important and the industry settled on a profoundly flawed model for it during the first round of Internet growth. On the low end you had personal web design tools like Front Page and Dreamweaver and on the high end you had enterprise content management system like Vignette and Interwoven.

The fact that the world of web design was dominated by tools like FrontPage and Dreamweaver was the biggest failure and missed opportunity of the first wave of Internet innovation. The problem on the low end is that most people spend most of their time and effort endlessly tweaking the look and feel and struggling to create a decent navigation system. This sucked up huge amounts of time and brainpower that could have been applied to understanding the intended audience and having something useful to say. Blogs and increasingly wikis are much better suited to most requirements for personal or small organization publishing needs. Default navigation and templates allow people to immediately publish a site and start being productive with content creation. In many respects the resulting site is superior. With a blog or wiki those people not trained as a designer don’t waste huge amounts of time and then end up with an ugly site like most novices produce with FrontPage. The news oriented format of a blog prompts people to keep their content fresh and up to date which is the biggest challenge for most small sites and wikis make remote collaboration an order of magnitude easier than trying to collaborate with someone else who has their own copy of FrontPage or Dreamweaver.

On the corporate side folks like Vignette and Interwoven provided a better solution than trying to coordinate the web activity of a huge corporation with a desktop tool like Dreamweaver but they were still built on a profoundly flawed centralized, command and control model. I’m not one to say that control is not needed in the corporate world but I do think the architecture was flawed. The corporate would be much better served with a mix of “best of breed,” light weight content management systems such as blogs, wikis, and special purpose CMS systems pulled together with an enterprise RSS infrastructure. This is a much more flexible architecture that allows an organization to scope the grassroots participation and corporate controls in a way that fits their needs and ensures much wider and more effective use of the system.