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.

No comments:

Post a Comment