The 'Social Experience Factory' and the Fabrics of Collaboration in Virtual Communities of Practice
Over the past few decades, information technology has evolved from a simple tool used by individuals to perform calculations to a medium that enables users to communicate and share knowledge with one another, which has been particularly valuable to industries in which the primary value (and competitive advantage) of their products is in the knowledge that goes into them.
This article is intended to describe a technical framework for "appropriating the benefits" of virtual networking, which the authors refer to as a "social experience factory" (SEF) - which is a community of practice that is formed for the purpose of supporting information-based products.
(EN: I'm cautious of this article already. An author who proposes to invent a term for something that already exists, and uses overly complex language to communicate simple concepts, raises suspicions that there is not much "matter" behind the smokescreen.)
THEORETICAL LINKS AND STATE OF PRACTICE
The author suggests that organizations that have transitioned their communications to be conducted via computer technology to be more "mature" (presumably, than those that have not). The value to the organization in seeking this maturity is to leverage information and resources within an organization more efficiently, and to be able to for virtual teams, or even an entirely virtual organization
A common theme among organizations from various industries that have adopted technology is their "intention to" encourage collaboration, and have used a variety of approaches(14 methods, 94 different products) for doing so The author notes that his study focuses on the use of communication technology for the purpose of new product development, and concedes that one criterion in selecting subjects for examination is that they were widely adopted within an organization.
One idea is that "creative users" are provided a tool-kit that enables them to devise virtual prototypes of products, and the technology platform enables them to collaborate and communicate within the organization and, eventually, send their designs to manufacturers. Such a tool-kit could also be leveraged across organizations and sectors, or even as methods for "open source" development within a practice community.
The author provides a list of some of the kinds of software that can be included in such a tool-kit, including one-to-many communication tools (mailing list and blogs) as well as collaborative authoring tools (wikis and prototyping suites). Such tools focus exclusively on managing the information that a company already knows, rather than on discovering new information that is germane to its interests (though it's noted that some companies use virtual "clipping services" to aggregate information from external sources and bring it into the organization's body of knowledge).
Second to the tools are the "practice elements" that are supported by an organization. This would seem to pertain to the organization's encouragement (or discouragement) of certain interactions among members of the organization, whether this is purely the intention of the organization or the interpretation by the individuals who use the technology. In general, researchers acknowledge that this is more challenging, but has historically been less studied in the literature, which focuses largely on the technology used to provide a "place" for engagement. One researcher refers to these practices, collectively, as "sociability."
In addition to the task of community management, there are also practice-specific toolkits, such as the code management tools used by software engineers, which coordinate the effort of multiple individuals and seek to facilitate collaboration on the "work" being done by a collective (rather than communication pertaining to the knowledge or theory that drives the work). Fundamentally, this software provides an "assembly line" in which individual workers perform tasks upon a product during the course of development, including the separate tasks to create components of reusable code that collocate with the master product.
It's noted that process improvement requires no only the orchestration of a task, but the ability to learn from the experience of performing that tasks and applying the lessons learned in one instance to future tasks of the same nature. The continuous build-up of knowledge gathered from multiple projects can be substantial, even in a small organization.
MANAGEMENT OF COLLECTIVE PRACTICES
In determining the tools to facilitate collaboration, there arises the question of what activities constitute a "community of practice," as opposed to other virtual communities (communities of interest, or action, or purely social functions). The underlying difference seems to be the nature of the goal and the means to achieve it, hence the "place" must be designed for the needs of practitioners in the context of their practice.
Again, the product of information-based industries is intangible, but has some specific characteristics:
- The end-user does not actually experience the product at the time of purchase, but derives a benefit from its later use.
- The products have very short life-cycles
- Information-based products are often customized to the needs of a specific user in a specific set of circumstances
- The products are fabricated by "virtual teams" in a process that resembles and assembly line (in terms of process, not physicality)
- Product development cannot be done by any individual member of the team, but requires a collective effort
(EN: I have some doubt as to whether these characteristics are applicable to all knowledge products. Some of them seem a bit arbitrary, and refer to practices that are common, but not strictly necessary.)
The author contrasts two methods for coordinating development: a "squad organization" in which all members to the team collaborate in every step of the process, and an "experience organization" in which roles seem to be more strictly divided, but there is a clear distinction between two phases: one where knowledge is gathered and evaluated, and a second where "work" is performed to implement a solution based on that knowledge. The clear value of community in this instance is to serve as a repository that will gather knowledge in the first phase and make it accessible during the second.
A bit more on "squad" organization: it involves a team made up of specialists who must interface with one another, and the rules of engagement stem from the commonality of the task. That is to say that the squad's interest in the body of knowledge of each member is limited to the ways in which it pertains to the task at hand. Likewise, the interactions among the members of the squad are mission-specific and are driven by the development process (its goals, and the current stage of production). The squad undergoes a distinct and repeatable process: formation; negotiation of goals, methods, and procedures; information gathering; and performance. This results in a temporary community of dissimilar individuals for the purpose of a given task.
A bit more on "experience organization": it is characterized by independent agents whose work is coordinated by moderators, who manage the flow of information and mediate among conflicting interests. Each agent (or team of agents) functions as its own team, insofar as developing common assets and communicating with one another in a "neighborhood" of experts with similar roles, who have community with one another, but not necessarily with other neighborhoods. The result is in a more long-standing community of similar individuals, independent of any individual task.
Regardless of the organizational structure, the act of product development generally takes a "factory line" approach, in which each constituent interacts with the product at one or more times to apply their expertise in tasks that progress the product toward completion. The nature of the work done may be in modifying the product directly, "bolting on" a component, making connections among existing components, or any combination of these tasks. An extended example of a software development process is used to illustrate this principle.
DESIGN OF TOOLS FOR COMMUNITIES
In developing communities of practice, tools can be provided to manage the institutional knowledge pertaining to certain disciplines as well as to manage the knowledge that arises in the context of a development project. These are essentially different communities that exist within a given organization.
There are a wide range of technologies: data repositories, collaborative tools, networking tools, etc. Vendors appear to specialize in a specific function, and there is not much research into the combination of various tools, and this is an area of interest to the author.
We can look to offline practices as a model of the way in which individuals interact and share knowledge, though it's clear that little progress has been made in this area. A team is assembled and given the command to work together to achieve a goal, but aside of that imperative, little organizational support is provided, and information is seldom collected in an organized manner, so it provides little guidance to the potential benefits of an online solution.
The author notes that infrastructures for "cultivated" communities of practice should be designed to support the workflows of the community (as opposed to software "workflow management" tools that force individuals to change their work patterns to suit the software). Specifically, the infrastructure should depict stages in the "evolutionary continuum" of the activities that result in the overall outcome. This can be done in a manner that has the flexibility to support the chosen workflow of the community.
Traditional groupware technology supports asynchronous (bulleting board) and synchronous (chat room) communications among group members, and enable the sharing of "media artifacts" (audiovisual media, screen sharing technology) to facilitate communication. The majority of artifacts remain textual in nature, though it is unclear whether this is because non-text artifacts are not useful or the tools provided for sharing them are not adequate for their intended use.
The author's SEF approach suggest that design for collaborative tools should begin with understanding the elements of interaction, then devising mechanisms that facilitate collaboration in the virtual environment. (EN: A reasonable approach, but I tend to wonder if this is not an overly simplistic view. Even when one makes an attempt to avoid solutions that force a "foreign" process on a community, the solution developed based on the needs of the community in its present incarnation becomes, in effect, hostile to its future evolution - the tool dictates practice, rather than supporting it.)
A distinction is made between mining information that is generated by a virtual community and the traditional concept of "data management." Specifically, "mining" data does not impose restrictions on how the data is developed or stored, but seeks to extract it regardless of the creation process. Mining also reaches beyond formal repositories of data to retrieve information from sources that may be "hidden" to the formal organization. It's also noted that mining can identify and codify new patterns, such as identifying the cliques that form within a community
SUMMARY AND CONCLUSION
The author notes that the present description has been "general and abstract," and that it may better be illustrated by the examples in chapter 21, which provides a real-world example of the principles in application.
(EN: And repeating a notion expressed earlier, my sense is it was a bit too "abstract and general" such that the notes that I've taken are even more likely than usual to depart from what the author intended to communicate.)