This is a cross-post from my blog on the military Social Media tool milBook.
This is the seventh post in a series based on the book Digital Habitats: stewarding technology for communities (CPsquare Publishing, © 2009) by Etienne Wenger, Nancy White, and John D. Smith. This post will cover Chapter 9 of the text.
This chapter deals with the ongoing role of the tech steward in the day-to-day operation of the digital habitat for a community of practice. The authors offer various guidelines and specific suggestions, focusing on the practical activities and responsibilities, highlighting the creative, inventive, and the basic work of technology stewarding. The role of the tech steward is not just to manage the configuration, but to make it a productive habitat.
Principles of Technology Stewardship:
1. Keep the vision of your community's success above the technical details of technology implementation. Be sure to participate in the community, while maintaining a vision and using your experience to guide your goals and performance criteria. This sets tech stewards apart from IT support professionals who focus solely on the performance of the technology.
2. Keep the technology as simple as possible for the community while meeting its needs. The authors point out that the technology shapes the community and vice versa. No matter what shiny new technology you find, focus on the simplest structure in the beginning. Keeping the technology simple allows for community successes and failures to guide subsequent steps.
3. Let the configuration of technologies evolve as the community evolves. The tools used by the community will change over time as members substitute new tools for ones in the "official" configuration. A community's use of technology becomes more intricate over time. Focus on the configuration and the actual technology in use, keeping in mind that the important thing is how the tools fit the community's practices.
4. Use all the knowledge around you. People in your overall network can be your best source of information. The community has knowledge of the local technology conditions, other tech stewards can suggest technology to adopt or avoid, product focused user communities can provide context and/or advice, and you can bridge the expertise of vendors or other external technologists with your knowledge of the community. Connect and participate, share what you learn as a tech steward with others.
5. Finally, "back it up." This may be elementary, but the data brought in and created by the community is important, to include member lists, shared resources, and artifacts of shared interactions. While in some cases the IT department can be depended on for regular backups, other types of community configurations require more proactive measures from the tech steward to ensure community data is backed up. Make sure key files are saved in a redundant manner to avoid catastrophic loss of key files and artifacts.
Stewarding in the foreground is different than stewarding in the background
While there are different ideas about what a tech steward should do, there is only a finite amount of time. This makes it important to focus on what matters most to the community- where it is now and where it may be in the near future. The authors have devised the following list to help of tasks where the tech steward can invest their energies. There are two tasks where technology and the tech steward are in the foreground, and five where the tech steward works in the background. The text has a series of pointers regarding planning, technology, and practice associated with each task that I will not cover in detail here.
These activities are where the community faces major changes in its technology and the tech steward is in the foreground:
1. Implementing and deploying a new community platform or set of technologies (new or migration). This is covered in detail in other sections of the text, as the decision to implement and deploy a new community platform is one of the core tasks a tech steward is involved in.
2. Community closure and end-of-life issues for distributed communities. The tech steward has a key role as a community reaches the end of its lifecycle. These center around archiving data and artifacts, and shutting down online spaces, and related activities.
On the other hand, these are the ongoing technology activities that go on in the background of communities:
1. Supporting new members in their use of the community's technology. There are training, configuration, and orientation tasks that a tech steward may be involved in as new members join the community. The tech steward need to be aware and understand their responsibilities in the onboarding process.
2. Identifying and spreading good technology practices. The tech steward has a unique position in the community to monitor how the community is using technology and what emerging best practices are associated with each tool or configuration of tools. The tech steward should also look for ways to disseminate these best practices to the community in a timely manner.
3. Supporting community experimentation. A community's configuration will evolve over time, and the tech steward needs to take a proactive role as this process unfolds. The key actions here include encouraging this experimentation, spreading the word on successful new practices/ tools/ configurations, and acting on the results while preserving the integrity and effectiveness of the digital habitat.
4. Attending to community boundaries created by technology. There are a number of boundaries created by the community technology, mainly in the level of accessibility that a community has to the outside world. The tech steward needs to bridge these boundaries where appropriate, while honoring the members' preferences for tools and privacy.
5.Assuring continuity across technology disruptions.There are a variety of ways that the digital habitat can be disrupted. These can be created by the introduction of new tools or configurations, accidental actions that affect parts of the system, or other unforeseen technology problems (network outages, etc.). It is incumbent on the tech steward to be attentive to what is going on in the community tech environment, prevent these disruptions if possible (careful migration, etc.), and minimize the impact of the disruption to the best of their ability. There are a variety of maintenance tasks that can help prevent issues, and testing any changes in a non-production environment before implementation is also important.
Beyond cycling between stewarding in the background and the foreground, there are other factors in successful tech stewarding. Constant change in the larger tech environment as more Web 2.0 and even 3.0 technologies are introduced can challenge even the most knowledgeable and capable tech steward.
Stewarding technology involves knowing a lot but it also includes intuition, guesswork, and being able to tolerate uncertainty and not knowing. This uncertainty requires insight and inventiveness to understand the community's underlying needs regarding technology, and intuition to help determine what "good enough" looks like. This kind of work cannot be reduced down to one formula. Tech stewarding is an emerging and dynamic practice, where a good practitioner balances technical and community knowledge in order to help shape the evolution of the community and its digital habitat.
I hope you were able to get something out of this post. I will be wrapping up this series in my next offering. I welcome your questions and comments.
Thursday, April 29, 2010
Thursday, April 8, 2010
Digital Habitats (Part 6)
This is a cross-post from my blog on the military Social Media tool milBook.
This is the sixth post in a series based on the book Digital Habitats: stewarding technology for communities (CPsquare Publishing, © 2009) by Etienne Wenger, Nancy White, and John D. Smith. This post will cover Chapter 8 of the text.
There comes a time in the life of a community of practice where the decision is made to change its digital habitat. This is a key time for the technology steward, as everyone is interested in what the new technology will be, and other aspects of the new system. Selection of this new habitat must be done carefully and diligently, as there are usually resources of some type involved. The authors suggest seven general acquisition strategies as shown below. Each strategy has pros and cons, and each implies a relationship with certain actors- something important when asking for help or permission. Orientations and context (covered in previous posts) will have an effect on which strategy to choose. There are also tips from the authors for each strategy.
Strategy 1. Use what you have
This strategy may not be very exciting to the tech-savvy members of the community, but it is the simplest and least resource intensive. While this does not involve the acquisition of new technology, there may be some changes in the way the community uses their digital habitat. The pros include no budget, a low learning curve, and little or no extra negotiation with the IT department. Cons are the question of firewall access for external users (if needed) and possibly no commitment to supporting the community. Tips center around finding out what is working (or not), exploring new or more effective ways to use existing tools, assessing what's available, looking at backup tools, and if there is access to enterprise-level resources, check out strategy 3 (below).
Strategy 2. Go for the free stuff
A growing array of free community tools and technology are available for groups with little or no resources. These are also attractive as many communities have no dedicated IT resources. Pros are the price and the ease of use and setup of many of the tools, low-risk experimentation (especially for tech-savvy members), and often the functionality of the free tools rival many expensive solutions. The cons include the presence of advertising, the potential difficulty in integration, and the need to jump between tools (which can be hard for less technology inclined members). Tips are back up your data in case of a change in the tool, consider whether archives and control are important to the community (it may make this a bad choice), consider blending free tools with other tools you already have or can acquire, and check user forums associated with the free tools to see what issues other users are having with the tool or platform- this can also give an indication on the level of support available.
Strategy 3. Build on an enterprise platform
Communities may have access to enterprise-level portals, tools for virtual teams, and collaboration platforms. They can provide rich resources for a small community of practice that would not generally need such an expensive feature-rich solution. These can be useful solutions for one community, and also support multiple communities as well. Pros center around encouragement to use the tool to make it easier for the IT department, usually not needing a technology budget, improved visibility for the community within the larger organization, and the good document management and other functionality of an enterprise solution. Cons are the potential lack of adequate collaboration facilities because the community is not the focus of the system, the need to adjust the facilities to support the community, and the possibility of needing some customizations to meet all of the community's needs.
Strategy 4. Get a commercial platform
Choosing a commercial community platform can go a long way toward meeting many of a community's needs all at once. This strategy is useful when communities prefer a "one-stop shop" or do not have a clear sense of its orientations and wants a variety of tool options. Some platforms are designed for communities of practice, and they can provide the community a distinct sense of identity. However, it may compete with other technologies in the members' daily lives. There is a separate issue of selecting the specific platform, keeping in mind the needs of the community as outlined elsewhere in the text. Pros revolve around having a community-specific platform that can provide a lot of tools, the support that a vendor can bring to the community, and the opportunity to get a quick start due to the burden of technology being on someone else's shoulders. Cons include cost- these platforms can be priced differently (which might limit the number of members), there may be resistance from the IT department- especially if it is an externally hosted solution, and the integration with back-end systems may be complicated as well. Tips are careful consideration of the list of tools available making sure they meet the community's needs, develop a relationship with the vendor, ensuring that the platform is configured properly (not just the default settings), and taking time to consider how the platform will be present in the life of the members.
Strategy 5. Build your own
Some communities or companies have the skills and willingness to create their own community platform. This can be a very flexible but risky endeavor, and implies a close relationship with a developer plus a deliberate investment of time and resources. Pros are focusing on specific needs of the community and developing tools to meet those needs, the prospect of having a unique and useful solution, and where programming costs are lower (using students or outsourcing/ off-shoring) this strategy can be very effective. The cons focus on the fact that this is not an easy strategy, can be very resource intensive, can still not meet the needs of the community, and the potential for developers to focus on functions not how members use the functions. Tips are explore the market to make sure this is the right choice, determine whether building a platform is part of your community's learning process, have a contingency budget for scope increases, and consider whether a unique tool is really right for your community given it can be a barrier to participation in some aspects.
Strategy 6. Use open-source tools
A possibility that may be present in all other strategies is that the tools selected are open-source (or Free and Open Source Software- FOSS). This means that the software itself is no-cost but usually requires customization and configuration to make it useful to the community. The community of practice may actually even make changes to the code and contribute it back to the larger FOSS community. Many open-source projects are communities of practice themselves, and this may be a driver in selecting this type of solution. Pros include the increasing variety and quality of FOSS collaboration tools, an active user community, and the fact that as these are used they continue to mature. Cons are mainly that this type of system still requires substantial programming and configuration, there is still a cost to configure and host the software, and the fact that not all FOSS is stable and mature. Tips are making sure to evaluate the maturity of the software, consider the configuration costs, observe the community around the product, and evaluate whether commercial versions of the FOSS would be a better choice given the community's needs.
Strategy 7. Patch elements together
Advanced Web 2.0 technologies allow communities to construct their own platforms by patching together easily available pieces, sometimes even with no programming skills. These technologies allow for a level of integration that is more than the "use free things" strategy, as not everyone is adept at jumping from tool to tool. Really Simple Syndication (RSS), Open Application Programming Interfaces (API's), Widgets, and Mashups are some of these technologies. Currently this strategy still requires some technical knowledge, but as this technology advances it should become easier over time. Pros are the flexibility to add and subtract tools and content incrementally over time, it allows for creative tech stewarding (as it lets less technical individuals do the work), and it allows gradual evolution instead of migrations from platform to platform. Cons include the tendency for "cool" enhancements to not serve the full community all the time, the ease of change which could allow for casual introduction of widgets which can disrupt some community members, the withdrawal of support for some of these widgets, and the potential for the introduction of malware using widgets as an attack vector into the community. Tips are make sure to have the ability to test new feeds, mashups, and widgets "off to the side" before allowing widespread use in the community and to remove feeds and widgets that fall into disuse.
Each strategy takes a slightly different approach to acquiring software for the community. Each one can build upon community circumstances and needs and has budget, resource availability, and technology comfort implications. As the community makes incremental changes to its digital habitat, the authors also have a few overall tips:
Start with the simplest, least expensive solution that will work. Identify tools that are available and make sure that you need to do anything at all, especially if it costs money. Justify the decision with real community experience.
Learn from other communities and their tech stewards. Once a strategy is picked, reach out to others that have used the strategy and talk with them.
Develop a testing plan. Depending on the strategy, find a way to include your community in testing the technology solution. Ask for test space from the vendor (and if they don't give it to you, beware...) and use free tools for small experimental activities with the community.
Once you recover from the first round, keep an eye out for what is next. This is a cyclical process, and the strategy may change in the next cycle. Evaluate the community's experience and learn how to better meet the community's technology needs, then prepare for the next cycle of decision making.
Please comment or ask questions below. Thanks for reading.
This is the sixth post in a series based on the book Digital Habitats: stewarding technology for communities (CPsquare Publishing, © 2009) by Etienne Wenger, Nancy White, and John D. Smith. This post will cover Chapter 8 of the text.
There comes a time in the life of a community of practice where the decision is made to change its digital habitat. This is a key time for the technology steward, as everyone is interested in what the new technology will be, and other aspects of the new system. Selection of this new habitat must be done carefully and diligently, as there are usually resources of some type involved. The authors suggest seven general acquisition strategies as shown below. Each strategy has pros and cons, and each implies a relationship with certain actors- something important when asking for help or permission. Orientations and context (covered in previous posts) will have an effect on which strategy to choose. There are also tips from the authors for each strategy.
Strategy 1. Use what you have
This strategy may not be very exciting to the tech-savvy members of the community, but it is the simplest and least resource intensive. While this does not involve the acquisition of new technology, there may be some changes in the way the community uses their digital habitat. The pros include no budget, a low learning curve, and little or no extra negotiation with the IT department. Cons are the question of firewall access for external users (if needed) and possibly no commitment to supporting the community. Tips center around finding out what is working (or not), exploring new or more effective ways to use existing tools, assessing what's available, looking at backup tools, and if there is access to enterprise-level resources, check out strategy 3 (below).
Strategy 2. Go for the free stuff
A growing array of free community tools and technology are available for groups with little or no resources. These are also attractive as many communities have no dedicated IT resources. Pros are the price and the ease of use and setup of many of the tools, low-risk experimentation (especially for tech-savvy members), and often the functionality of the free tools rival many expensive solutions. The cons include the presence of advertising, the potential difficulty in integration, and the need to jump between tools (which can be hard for less technology inclined members). Tips are back up your data in case of a change in the tool, consider whether archives and control are important to the community (it may make this a bad choice), consider blending free tools with other tools you already have or can acquire, and check user forums associated with the free tools to see what issues other users are having with the tool or platform- this can also give an indication on the level of support available.
Strategy 3. Build on an enterprise platform
Communities may have access to enterprise-level portals, tools for virtual teams, and collaboration platforms. They can provide rich resources for a small community of practice that would not generally need such an expensive feature-rich solution. These can be useful solutions for one community, and also support multiple communities as well. Pros center around encouragement to use the tool to make it easier for the IT department, usually not needing a technology budget, improved visibility for the community within the larger organization, and the good document management and other functionality of an enterprise solution. Cons are the potential lack of adequate collaboration facilities because the community is not the focus of the system, the need to adjust the facilities to support the community, and the possibility of needing some customizations to meet all of the community's needs.
Strategy 4. Get a commercial platform
Choosing a commercial community platform can go a long way toward meeting many of a community's needs all at once. This strategy is useful when communities prefer a "one-stop shop" or do not have a clear sense of its orientations and wants a variety of tool options. Some platforms are designed for communities of practice, and they can provide the community a distinct sense of identity. However, it may compete with other technologies in the members' daily lives. There is a separate issue of selecting the specific platform, keeping in mind the needs of the community as outlined elsewhere in the text. Pros revolve around having a community-specific platform that can provide a lot of tools, the support that a vendor can bring to the community, and the opportunity to get a quick start due to the burden of technology being on someone else's shoulders. Cons include cost- these platforms can be priced differently (which might limit the number of members), there may be resistance from the IT department- especially if it is an externally hosted solution, and the integration with back-end systems may be complicated as well. Tips are careful consideration of the list of tools available making sure they meet the community's needs, develop a relationship with the vendor, ensuring that the platform is configured properly (not just the default settings), and taking time to consider how the platform will be present in the life of the members.
Strategy 5. Build your own
Some communities or companies have the skills and willingness to create their own community platform. This can be a very flexible but risky endeavor, and implies a close relationship with a developer plus a deliberate investment of time and resources. Pros are focusing on specific needs of the community and developing tools to meet those needs, the prospect of having a unique and useful solution, and where programming costs are lower (using students or outsourcing/ off-shoring) this strategy can be very effective. The cons focus on the fact that this is not an easy strategy, can be very resource intensive, can still not meet the needs of the community, and the potential for developers to focus on functions not how members use the functions. Tips are explore the market to make sure this is the right choice, determine whether building a platform is part of your community's learning process, have a contingency budget for scope increases, and consider whether a unique tool is really right for your community given it can be a barrier to participation in some aspects.
Strategy 6. Use open-source tools
A possibility that may be present in all other strategies is that the tools selected are open-source (or Free and Open Source Software- FOSS). This means that the software itself is no-cost but usually requires customization and configuration to make it useful to the community. The community of practice may actually even make changes to the code and contribute it back to the larger FOSS community. Many open-source projects are communities of practice themselves, and this may be a driver in selecting this type of solution. Pros include the increasing variety and quality of FOSS collaboration tools, an active user community, and the fact that as these are used they continue to mature. Cons are mainly that this type of system still requires substantial programming and configuration, there is still a cost to configure and host the software, and the fact that not all FOSS is stable and mature. Tips are making sure to evaluate the maturity of the software, consider the configuration costs, observe the community around the product, and evaluate whether commercial versions of the FOSS would be a better choice given the community's needs.
Strategy 7. Patch elements together
Advanced Web 2.0 technologies allow communities to construct their own platforms by patching together easily available pieces, sometimes even with no programming skills. These technologies allow for a level of integration that is more than the "use free things" strategy, as not everyone is adept at jumping from tool to tool. Really Simple Syndication (RSS), Open Application Programming Interfaces (API's), Widgets, and Mashups are some of these technologies. Currently this strategy still requires some technical knowledge, but as this technology advances it should become easier over time. Pros are the flexibility to add and subtract tools and content incrementally over time, it allows for creative tech stewarding (as it lets less technical individuals do the work), and it allows gradual evolution instead of migrations from platform to platform. Cons include the tendency for "cool" enhancements to not serve the full community all the time, the ease of change which could allow for casual introduction of widgets which can disrupt some community members, the withdrawal of support for some of these widgets, and the potential for the introduction of malware using widgets as an attack vector into the community. Tips are make sure to have the ability to test new feeds, mashups, and widgets "off to the side" before allowing widespread use in the community and to remove feeds and widgets that fall into disuse.
Each strategy takes a slightly different approach to acquiring software for the community. Each one can build upon community circumstances and needs and has budget, resource availability, and technology comfort implications. As the community makes incremental changes to its digital habitat, the authors also have a few overall tips:
Start with the simplest, least expensive solution that will work. Identify tools that are available and make sure that you need to do anything at all, especially if it costs money. Justify the decision with real community experience.
Learn from other communities and their tech stewards. Once a strategy is picked, reach out to others that have used the strategy and talk with them.
Develop a testing plan. Depending on the strategy, find a way to include your community in testing the technology solution. Ask for test space from the vendor (and if they don't give it to you, beware...) and use free tools for small experimental activities with the community.
Once you recover from the first round, keep an eye out for what is next. This is a cyclical process, and the strategy may change in the next cycle. Evaluate the community's experience and learn how to better meet the community's technology needs, then prepare for the next cycle of decision making.
Please comment or ask questions below. Thanks for reading.
Subscribe to:
Posts (Atom)