This is a cross-post from my blog on the Military Social Networking system milBook.
This will be the second of a series of posts that will look into use cases for Google Wave (or more specifically FedWave, which is the effort to use Wave in the Federal Government). While these use cases will have a military/ government focus, they have much in common with other articles that cover uses for Google Wave (here, here, and here).
NOTE: this and subsequent posts on this topic are strictly the opinions of the author, and do not represent any official Government policy or endorsement, nor are endorsed by any entity that is or may do business with the Government in any capacity.
Assumptions and Warnings:
- Not all the functionality shown in the following use cases is fully developed
- Some existing Wave features are not available in open source version of Wave (FedOne) including attachments and many extensions.
- The use cases are for illustration only, do not represent any official sanction of the technology or its use by the Government in any form
Here are some more use cases, based on milBook comments/ contributions in response to my earlier post:
7. Task/Initiative Management: A simple management tool to track small projects, initiatives, or actions that do not require a full project management tool
8. Staff Action Tracking: Items that need to be endorsed by multiple staff sections can be collaboratively reviewed in order to see the comments or thoughts put together by another office and could collaborate on responses and reduce email overhead
9. Operations Center: Update briefings can be created and kept current in real-time for briefing senior leaders; being able to coordinate and collaborate using rich media will provide a clear common operational picture that is available to a multitude of organizations using trusted connections
I will expand on these and the first six use cases in subsequent posts.
Thanks for your participation in the process, and please continue to let me know what you think about this.
Tuesday, July 13, 2010
Wednesday, June 30, 2010
Why Use Google Wave?
This is a cross-post from my blog on the Military Social Networking system milBook.
This will be the first of a series of posts that will look into use cases for Google Wave (or more specifically FedWave, which is the effort to use Wave in the Federal Government). While these use cases will have a military/ government focus, they have much in common with other articles that cover uses for Google Wave (here, here, and here).
NOTE: this and subsequent posts on this topic are strictly the opinions of the author, and do not represent any official Government policy or endorsement, nor are endorsed by any entity that is or may do business with the Government in any capacity.
By way of review, here is a synopsis of one of my earlier posts:
Definition: Google Wave is a product that could replace email, instant messaging, and threaded discussion using a collaborative platform and an open-source protocol.
- Product: Currently Google hosted
- Platform: Includes Extensions, bots, etc.
- Protocol: Facilitates having independent Wave servers on any network, but still able to federate over a single port
Assumptions and Warnings:
- Not all the functionality shown in the following use cases is fully developed
- Some existing Wave features are not available in open source version of Wave (FedOne) including attachments and many extensions.
- The use cases are for illustration only, do not represent any official sanction of the technology or its use by the Government in any form
1. Joint Use Case: Targeting
All information and approvals for target execution in one place on the Network that can be edited in real-time by multiple users
2. Interagency Use Case: Significant Activities (SIGACTs)
Effective Real-time and Time-Delayed Collaboration across multiple-networks for information gathering, analysis, and response
3. Intergovernmental Use Case: Border Enforcement
Real-time multiple-echelon and multiple-network collaboration to coordinate response to border incidents
4. Multinational Use Case: Simultaneous translation coupled with event planning
Use of simultaneous translation extensions to facilitate event planning such as a G8 or G20 summit
5. Social Media Integration (VIP Social Media)
Authoritative capture of official communications via non-Federal controlled systems such as Facebook, Twitter, or other Web 2.0 apps
6. Secure Messaging
Replacement of aging E-mail (SMTP) based organizational messaging systems with a platform that inherently supports a similar authority model and meets the criteria of multi-author, multi-destination authoritative organizational messages
In subsequent posts I will expand on these six FedWave Use Cases and provide an example of each.
Please let me know what you think about this. I have to admit that I am less than objective about this new technology, as I believe it is truly revolutionary and has tremendous potential. If you have other use cases, please share them in the comments, and I will look at adding them to my unofficial list. As always, thanks for reading.
This will be the first of a series of posts that will look into use cases for Google Wave (or more specifically FedWave, which is the effort to use Wave in the Federal Government). While these use cases will have a military/ government focus, they have much in common with other articles that cover uses for Google Wave (here, here, and here).
NOTE: this and subsequent posts on this topic are strictly the opinions of the author, and do not represent any official Government policy or endorsement, nor are endorsed by any entity that is or may do business with the Government in any capacity.
By way of review, here is a synopsis of one of my earlier posts:
Definition: Google Wave is a product that could replace email, instant messaging, and threaded discussion using a collaborative platform and an open-source protocol.
- Product: Currently Google hosted
- Platform: Includes Extensions, bots, etc.
- Protocol: Facilitates having independent Wave servers on any network, but still able to federate over a single port
Assumptions and Warnings:
- Not all the functionality shown in the following use cases is fully developed
- Some existing Wave features are not available in open source version of Wave (FedOne) including attachments and many extensions.
- The use cases are for illustration only, do not represent any official sanction of the technology or its use by the Government in any form
1. Joint Use Case: Targeting
All information and approvals for target execution in one place on the Network that can be edited in real-time by multiple users
2. Interagency Use Case: Significant Activities (SIGACTs)
Effective Real-time and Time-Delayed Collaboration across multiple-networks for information gathering, analysis, and response
3. Intergovernmental Use Case: Border Enforcement
Real-time multiple-echelon and multiple-network collaboration to coordinate response to border incidents
4. Multinational Use Case: Simultaneous translation coupled with event planning
Use of simultaneous translation extensions to facilitate event planning such as a G8 or G20 summit
5. Social Media Integration (VIP Social Media)
Authoritative capture of official communications via non-Federal controlled systems such as Facebook, Twitter, or other Web 2.0 apps
6. Secure Messaging
Replacement of aging E-mail (SMTP) based organizational messaging systems with a platform that inherently supports a similar authority model and meets the criteria of multi-author, multi-destination authoritative organizational messages
In subsequent posts I will expand on these six FedWave Use Cases and provide an example of each.
Please let me know what you think about this. I have to admit that I am less than objective about this new technology, as I believe it is truly revolutionary and has tremendous potential. If you have other use cases, please share them in the comments, and I will look at adding them to my unofficial list. As always, thanks for reading.
Thursday, May 20, 2010
Overview of Citrix and Virtualization Technology
Citrix Systems (www.citrix.com) is a leading provider of technology for virtualization of applications and servers. The company was formed in 1989 and its name is a portmanteau of Citrus (the original name of the company) and UNIX. It had over $1 Billion in revenue in 2009 and employs over 4800 worldwide. Citrix is headquartered in Fort Lauderdale, Florida.
Andreas Krebs authored an excellent brief overview of Citrix technology in the All Covered Learning Center:
In 1995, Citrix introduced the world to virtualization with NT 3.5 WinFrame, an application virtualization solution. Later, they offered NT 4.0 Terminal Server, a desktop virtualization solution. As the founders of virtualization technology, Citrix is the company that many businesses recognize and trust for their virtualization solutions.
Server Virtualization
XenServer is Citrix’s no-cost server virtualization solution that gives small and medium sized businesses an affordable and effective way to adopt an enterprise-class technology. Unlike other server virtualization solutions, XenServer provides premium grade features for free. Benefits include the following:
XenDesktop is Citrix’s desktop virtualization solution. As an on-demand service, XenDesktop will deliver a Windows desktop to any user, anywhere. Features include the following:
XenApp is Citrix’s application virtualization solution that allows users to directly access Windows applications from through a desktop computer or web browser. Benefits include the following:
Essentials for XenServer is an add-on enhancement that complements XenServer by providing additional features and integrated management capabilities for server, desktop and application virtualization.
This post is a very brief overview of Citrix and virtualization technology. The Citrix website is an excellent place to learn more about this important technology.
Thanks for reading.
Andreas Krebs authored an excellent brief overview of Citrix technology in the All Covered Learning Center:
In 1995, Citrix introduced the world to virtualization with NT 3.5 WinFrame, an application virtualization solution. Later, they offered NT 4.0 Terminal Server, a desktop virtualization solution. As the founders of virtualization technology, Citrix is the company that many businesses recognize and trust for their virtualization solutions.
Server Virtualization
XenServer is Citrix’s no-cost server virtualization solution that gives small and medium sized businesses an affordable and effective way to adopt an enterprise-class technology. Unlike other server virtualization solutions, XenServer provides premium grade features for free. Benefits include the following:
- XenServer supports an unlimited number of servers, virtual machines and physical memory.
- XenServer includes a conversion function will allow you to convert a virtual server into a physical server and physical server into a virtual server as needed. (Other server virtualization solutions will charge you for this feature.)
- Shared SAN and NAS storage between server hosts maximize available storage on the network.
- All virtualized servers can be accessed and maintained from a single location.
- In the event of server failure, affected virtual machines are automatically restarted on other production servers.
- A library of pre-configured virtual machine templates make it easy to rapidly create a test or production environment.
- Centralized patch management makes it easy to keep virtual servers updated.
- Easy migration of virtual systems to from one host server to another makes it simple to maintain host servers.
- XenServer is open-source and takes advantage of the intellectual contributions of thousands of users, hundreds of companies and partners.
- XenServer is compatible with most server hardware that is currently available.
XenDesktop is Citrix’s desktop virtualization solution. As an on-demand service, XenDesktop will deliver a Windows desktop to any user, anywhere. Features include the following:
- XenDesktop users can access their desktop and corporate applications from any PC, Mac, thin client or smart phone.
- XenDesktop gives users a computing experience that rivals a local PC, even when using Multimedia, 3D graphics or VoIP-integrated applications.
- Each desktop is customizable to meet the performance and security needs of individual users.
- XenDesktop will work with your existing hypervisor, storage and Microsoft infrastructures—you don’t have to spend more money buying compatible programs.
XenApp is Citrix’s application virtualization solution that allows users to directly access Windows applications from through a desktop computer or web browser. Benefits include the following:
- Windows applications can be accessed on devices that have non-Windows based operating systems—more than thirty operating systems are currently supported.
- This solution requires that only one virtualized copy of an application such as Office 2010 be installed and maintained, while allowing any number of users to access and use it as if it was locally installed.
- Applications can be streamed directly from the host server for users working on the corporate network or remotely. Permissions can even be set up to allow users to download and access apps while offline.
- Virtualized applications function as if they are locally installed.
- Application delivery and access is customizable for each user and their preferred device, network and typical access location.
Essentials for XenServer is an add-on enhancement that complements XenServer by providing additional features and integrated management capabilities for server, desktop and application virtualization.
- One-click access to native storage makes device management simple.
- Automated high-availability protection will move virtualized machines from a failed host server to another physical server.
- Automated management of lab infrastructures decreases the complexity, time and cost of managing non-production environments.
- Automated workload balancing will move virtual servers to hosts with more available resources based on pre-configured policies.
This post is a very brief overview of Citrix and virtualization technology. The Citrix website is an excellent place to learn more about this important technology.
Thanks for reading.
Thursday, May 6, 2010
Introduction to Kanban
The purpose of this post is to provide a general overview of the practice of Kanban in software development and its relationship to Scrum. There is a lot of great material available on the Web on Kanban, and one of the best of them is this article: Kanban Development Oversimplified. The main website for Kanban is here. For comparison purposes (and for reference) review my post on Agile Development.
This is a discussion and definition of Kanban from Karl Scotland:
"While the word Kanban comes from the Japanese for “visual card”, the term Kanban as used by the Kanban Software Development community, represents much more than a standard task-board. Additionally, the Kanban Software Development community have not tried to replicate the mechanism of the Toyota Production System kanban tool exactly, but have taken the underlying principles in order to achieve similar effects in software development. So what is a Kanban System for Software Development?
A Kanban System visualizes some unit of value. This unit of value could be a User Story, Minimal Marketable Feature, Plain Old Requirement or something else. This is different from a task-board, which generally focuses on visualizing the current tasks.
A Kanban System manages the flow of these units of value, through the use of Work In Process limits. This is different from a task-board, which generally has no WIP limits, but aims to have all tasks complete by the end of a time-box.
A Kanban System deals with these units of value through the whole system,from when they enter a teams control, until when they leave it. This is different from a task-board, which generally only deals with the work in the build/test stage, but shows no information about what work is being prepared, or what work is ready for release.
By putting these 3 properties of a Kanban System together, we can describe a Kanban System for Software Development as one which allows value to flow through the whole system using WIP limits to create a sustainable pipeline of work. Further, the WIP Limits provide a mechanism for the Kanban System
to demonstrate when there is capacity for new work to be added, thereby creating a Pull System. Finally, the WIP Limits can be adjusted and their effect measured as the Kanban System is continuously improved.
A task-board simply shows what development tasks have been predicted to be done in the current time-box, with their status."
Kanban fills a niche in the world of Agile Development in that it provides a system to control the flow of work where the development team has other duties (production support, multiple projects) and cannot work in dedicated Scrum Sprints (Agile iterations). Kanban allows for teams and individuals to work on specific units of value and advance them through the various stages based on WIP limits.
Here is a great story from the Kanban Development Oversimplified article that illustrates some of the key pieces of Kanban:
"You’ll find a lot of terminology in Lean software development comes from Japan and from the Toyota Production System in particular. Kanban translated literally: “Kan” means visual, and “ban” means card or board.
Picture yourself on a Toyota production line. You put doors on Priuses. You have a stack of 10 or so doors. As you keep bolting them on, your stack of doors gets shorter. When you get down to 5 doors, sitting on top of the 5th door in the stack is a card — a Kanban card — that says “build 10 doors.” Well it may not say exactly that — but it is a request to build exactly 10 more Prius doors.
You pick the Kanban card up, and run it over to the guy who builds doors. He’s been waiting for you. He’s been doing other things to keep busy while waiting. The important thing here is that he’s NOT been building Prius doors. He takes your Kanban card and begins to build doors.
You go back to your workstation, and just a bit before your stack of doors is gone, the door guy comes back with a stack of 10 doors. You know that Kanban card is slid in between doors 5 & 6. You got the doors just in time. The whole thing sorta works like magic. Only you wish you had the door-building job. That guys seems to have a lotta free time on his hands.
Kanban cards are used to limit the amount of inventory the factory builds. It doesn’t do the Toyota factory any good to build doors faster then they can assemble cars. It just wastes money on excess doors, and parts of doors. Excess work in progress is considered to be waste in Lean manufacturing. (It’s probably waste in non-Lean manufacturing too.) In the above completely made up example, you’ll never have more than 15 finished doors hanging around. (Mudha is Japanese for waste. Learn it to impress your Lean friends.)"
The article goes on to the more practical aspects of the process:
"Kanban thinking in software development attempts to do a similar thing. We want to limit unnecessary work in progress to be no higher than it needs to be to match the throughput of the team. Kanban thinking applied to Agile development results in sweeping changes that throw out much of what Agile practitioners consider necessary practice.
A key component of Kanban is the visual board that is used for managing work in process. Most of the time it is a physical board similar to this one:
This board was reconstructed from photos of boards used at Yahoo.
There are also online versions of Kanban boards such as LeanKit Kanban and Kanban Tool. The key is to use some type of information radiator so that everyone can see what is on the board and what the status is. Seeing the flow is also important so and bottlenecks can be identified and cleared out. It is important to set limits for each stage in the process as this will govern the flow of cards from point to point.
All of the columns should be customized to the team and the project being worked on. There are several aspects of Scrum that need to be upheld, especially in the area of collaboration and communication. Just because there isn't a defined iteration schedule does not mean that the software is not demonstrated and planning meetings are not needed. These are scheduled at some interval so that the customer gets to see working software and the team is able to work together to keep the flow moving. Regular review of the process (similar to the Scrum Retrospective) is also done as part of Kanban. There are other aspects of Scrum and Agile that the team can use as part of this process. Again, customization of the process is encouraged.
This is a very brief overview of one of the emerging software development methods. Please access some of the references on the Limited WIP Society website for more in-depth information.
I hope you found this interesting and informative. Please post questions and comments below.
This is a discussion and definition of Kanban from Karl Scotland:
"While the word Kanban comes from the Japanese for “visual card”, the term Kanban as used by the Kanban Software Development community, represents much more than a standard task-board. Additionally, the Kanban Software Development community have not tried to replicate the mechanism of the Toyota Production System kanban tool exactly, but have taken the underlying principles in order to achieve similar effects in software development. So what is a Kanban System for Software Development?
A Kanban System visualizes some unit of value. This unit of value could be a User Story, Minimal Marketable Feature, Plain Old Requirement or something else. This is different from a task-board, which generally focuses on visualizing the current tasks.
A Kanban System manages the flow of these units of value, through the use of Work In Process limits. This is different from a task-board, which generally has no WIP limits, but aims to have all tasks complete by the end of a time-box.
A Kanban System deals with these units of value through the whole system,from when they enter a teams control, until when they leave it. This is different from a task-board, which generally only deals with the work in the build/test stage, but shows no information about what work is being prepared, or what work is ready for release.
By putting these 3 properties of a Kanban System together, we can describe a Kanban System for Software Development as one which allows value to flow through the whole system using WIP limits to create a sustainable pipeline of work. Further, the WIP Limits provide a mechanism for the Kanban System
to demonstrate when there is capacity for new work to be added, thereby creating a Pull System. Finally, the WIP Limits can be adjusted and their effect measured as the Kanban System is continuously improved.
A task-board simply shows what development tasks have been predicted to be done in the current time-box, with their status."
Kanban fills a niche in the world of Agile Development in that it provides a system to control the flow of work where the development team has other duties (production support, multiple projects) and cannot work in dedicated Scrum Sprints (Agile iterations). Kanban allows for teams and individuals to work on specific units of value and advance them through the various stages based on WIP limits.
Here is a great story from the Kanban Development Oversimplified article that illustrates some of the key pieces of Kanban:
"You’ll find a lot of terminology in Lean software development comes from Japan and from the Toyota Production System in particular. Kanban translated literally: “Kan” means visual, and “ban” means card or board.
Picture yourself on a Toyota production line. You put doors on Priuses. You have a stack of 10 or so doors. As you keep bolting them on, your stack of doors gets shorter. When you get down to 5 doors, sitting on top of the 5th door in the stack is a card — a Kanban card — that says “build 10 doors.” Well it may not say exactly that — but it is a request to build exactly 10 more Prius doors.
You pick the Kanban card up, and run it over to the guy who builds doors. He’s been waiting for you. He’s been doing other things to keep busy while waiting. The important thing here is that he’s NOT been building Prius doors. He takes your Kanban card and begins to build doors.
You go back to your workstation, and just a bit before your stack of doors is gone, the door guy comes back with a stack of 10 doors. You know that Kanban card is slid in between doors 5 & 6. You got the doors just in time. The whole thing sorta works like magic. Only you wish you had the door-building job. That guys seems to have a lotta free time on his hands.
Kanban cards are used to limit the amount of inventory the factory builds. It doesn’t do the Toyota factory any good to build doors faster then they can assemble cars. It just wastes money on excess doors, and parts of doors. Excess work in progress is considered to be waste in Lean manufacturing. (It’s probably waste in non-Lean manufacturing too.) In the above completely made up example, you’ll never have more than 15 finished doors hanging around. (Mudha is Japanese for waste. Learn it to impress your Lean friends.)"
The article goes on to the more practical aspects of the process:
"Kanban thinking in software development attempts to do a similar thing. We want to limit unnecessary work in progress to be no higher than it needs to be to match the throughput of the team. Kanban thinking applied to Agile development results in sweeping changes that throw out much of what Agile practitioners consider necessary practice.
In Kanban development:
By now you should be scratching your head a bit. Exactly what’s left of Agile if we get rid of time-boxes, change the meaning of stories, and stop measuring velocity. And, exactly what do car doors and Kanban cards have to do with software development?"- time-boxed development is out
- stories are larger and fewer
- estimation is optional or out completely
- velocity is replaced by cycle time
A key component of Kanban is the visual board that is used for managing work in process. Most of the time it is a physical board similar to this one:
There are also online versions of Kanban boards such as LeanKit Kanban and Kanban Tool. The key is to use some type of information radiator so that everyone can see what is on the board and what the status is. Seeing the flow is also important so and bottlenecks can be identified and cleared out. It is important to set limits for each stage in the process as this will govern the flow of cards from point to point.
All of the columns should be customized to the team and the project being worked on. There are several aspects of Scrum that need to be upheld, especially in the area of collaboration and communication. Just because there isn't a defined iteration schedule does not mean that the software is not demonstrated and planning meetings are not needed. These are scheduled at some interval so that the customer gets to see working software and the team is able to work together to keep the flow moving. Regular review of the process (similar to the Scrum Retrospective) is also done as part of Kanban. There are other aspects of Scrum and Agile that the team can use as part of this process. Again, customization of the process is encouraged.
This is a very brief overview of one of the emerging software development methods. Please access some of the references on the Limited WIP Society website for more in-depth information.
I hope you found this interesting and informative. Please post questions and comments below.
Wednesday, May 5, 2010
Digital Habitats (Part 8)
This is a cross-post from my blog on the military Social Media tool milBook.
This is the eighth and last 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 Chapters 10,11, and 12 of the text.
Chapter 10 of the book is a series of checklists and other resources designed to help a tech steward put some of the other concepts of the text into action. They are worth reviewing and using as appropriate.
Chapter 11 covers emerging trends in technology stewardship and how these trends may affect the intersection of community and technology in the digital habitats of the future. The roles in the community are blurring and the process is accelerating.
The authors explain these trends in terms of the three polarities that were defined earlier in the text and a previous post. They go on to add a fourth dimension that spans all of these polarities. Here is a brief overview of these reconfigured polarities:
1. Increased connectivity across time and space (Polarity: Dynamic fluidity of togetherness and separation)
- Ubiquitous connectivity: The progression here has been from intermittent connections using modems to the current "always on" wireless and mobile technologies.
- Virtual presence: We have gone from purely text-based interaction to virtual presence, multimedia on demand, and avatar-based environments.
2. New modes of engagement (Polarity: Reweaving participation and Reification)
- Generalized self-expression: This manifests itself through the Web 2.0 technologies that enable users to publish content rapidly and easily using blogs and "personal space" sites.
- Mass collaboration: Examples of this are wikis, tagging, social networking sites, publicly shared, interactive storage spaces.
- Creative reappropriation: This is an emerging practice where remixes, social bookmarking and personalized lists, and mashups create content from existing content.
3. Changing geographies of communities (Polarity: Dynamic group formation and multimembership)
- Homesteading on the web: The proliferation of sites, tools, and links coupled with the multiplicity of places for any topic form emergent patterns of meaning and interrelatedness.
- Dynamic boundaries: These are boundaries that are defined by activities and their traces, including the tools that rank locations and direct traffic.
- Individualization of access: RSS, personalized aggregation, customized search, and personalized access to sites allow users to individualize their online experience.
4. Toward a socially active medium (Polarity: Ability to find each other and to see the social fabric)
- Social Computing: This is the phenomenon that includes social relations and interactions as data, "folksonomies" and tagging, networking services, distributed decision making processes, reputation computing, and socially directed search all have a role.
- Semantic web: Meaning-based representation, intelligent agents, and new-generation search is changing online interaction in fundamental ways.
- Digital footprint: All this comes together to create a trail of web activities that become an expression of an online identity.
These reconfigured polarities present the tech steward a variety of challenges and opportunities, including overwhelming volume, falling into groupthink, vulnerable systems, and stretching our relationships. All must be considered as digital habitats move into the future.
Chapter 12 is also oriented to the future in that it proposes a learning agenda for technology stewardship that is an invitation to explore three areas where technology stewardship will matter:
- Serving existing communities: This includes the concepts of connectivity and proximity, shifting boundaries and peripherality, new modes of engagement, creative reappropriation and community voice, transparency in a socially active medium, and dealing with multiplicity.
- Making new communities possible: Digital habitats have the potential to enable the formation of new groups and communities. They do this by allowing people to find each other on a wider scale (size and meaningful engagement), being catalysts for communities, allowing access to living practice through virtual presence, creating complex geographies of identity and domain-based relationships, and seeing the social in the technological.
- Stretching our very notion of community: The interaction of community and technology affects both to the point of challenging our assumptions about them. The evolution of Proto-communities (emerging patterns of communities and networks) is an excellent example of this. Also, the emerging practices of stewardship that allows for balancing network and community processes is important. Finally learning between the old and the new will keep everything in perspective.
The text goes into more detail on each of these concepts.
Supporting all of this is a literacy of technology stewardship that includes a strong understanding of the concepts of technology configuration, community polarities, and community orientations that have been covered in previous posts. In fact, technology stewardship is on its way to becoming a community of practice in its own right as it becomes more central to the learning experience of a growing number of communities. This practice of enabling learning with technology will become increasingly widespread and the stewardship of these digital habitats an important part of the success of the communities that inhabit these virtual spaces.
I hope you have enjoyed this series of posts on a very important book. Thanks again for reading, and I invite you to post comments and questions below.
Thursday, April 29, 2010
Digital Habitats (Part 7)
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.
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 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)