Agencies don't have to be like Vegas
- By Josh Stephens
- Oct 03, 2011
How are Las Vegas and government agencies alike? What happens there stays there. But although keeping a marriage to an Elvis impersonator secret may be a good idea, locking up an agency’s best practices in network management is not.
This general inability of agencies to “talk” to each other not only makes the job of agency IT pros harder but also has broad implications across the government as a whole, from technology integration to security concerns.
To put this in context, in a previous life, I worked at an Air Force base in the Midwest. We employed a fairly sophisticated network infrastructure and found ourselves troubleshooting relatively complex issues on a regular basis, which led to a good-sized compilation of best practices — best practices, however, that we could never share with other bases because there were no protocols in place, let alone collaboration tools, to do so. Additionally, my team could not seek out best practices from other military installations for the same reasons: We were isolated.
Two ways to improve collaboration
‘Culture of reuse’ critical to modernizing old applications
Look at it this way: Suppose an intelligence agency determines that a certain subnet is responsible for attacks on U.S. IT infrastructure. Currently, there’s no quick and efficient way to share that information across agencies, meaning the entire government is at risk until the news can be put through the preapproved, but most likely slow, channels.
Or perhaps another agency has successfully deployed a cloud infrastructure, saving millions in its budget while streamlining operations. How do they share how they did it? In today’s agency climate, they can’t.
As for what’s holding back agencies, it’s not the technology. Proven collaboration technology has existed for close to 15 years, primarily in the form of wikis. It’s personnel and process.
The very nature of most collaboration technologies, especially wikis, disturbs many agency IT decision-makers in the wake of WikiLeaks. Although it’s true that WikiLeaks is based on collaboration technology, the fact remains that, from a security and auditing perspective, wikis are actually more secure than even e-mail. The platform tracks data edits, user log-ins and downloads — all issues that agency IT teams struggle against with e-mail. To further distance the notion that wikis are not secure, agencies need to keep in mind that the leak behind WikiLeaks came from a database, not a collaboration platform.
Process, or rather lack of a process, also holds agencies back when it comes to collaboration. A wiki or other collaboration platform is simple for IT to integrate with existing operations…but then what? There’s no chain of command beyond “IT integrates the technology” — the collaboration platform is then opened to end users, and chaos ensues. This is not how a successful collaboration platform such as Wikipedia or even WikiLeaks succeeds.
To actually succeed in collaboration, agencies need to enforce structure, which, in practice, means applying taxonomy and a hierarchy of grouping. It also requires that someone be in charge of building a baseline organizational structure before releasing the platform into the wild. This requires that a project manager with a background in library sciences or, at the very least, information management give the platform a backbone.
This really should not be alien to agency decision-makers — the federal government loves processes. Every agency, from FEMA to the FDA, has a general process for most situations, such as floods or food recalls. But then the argument becomes “These processes are already documented, so what purpose does collaboration serve?” These documented processes, however, are high-level, and when does an agency ever actually run squarely into a high-level emergency? Never.
With the FEMA example, catastrophes can be generally categorized, ranging from “terrorist attack” to “hurricane.” These events all have processes backing them, which is good. What’s not good is that there are typically very few documented procedures for specific events, such as “storm surge in populated area” or “industrial accident in mid-sized town.” This is where collaboration is needed — local agencies have almost certainly dealt with these sorts of events and have a process, but they cannot easily share it.
Agencies may actually do well to mimic the collaboration-esque platforms that technology vendors have already perfected. Open-source communities such as SourceForge or SolarWinds’ own thwack can provide a good blueprint for local agencies seeking to implement communities where end users share information. Although it’s true that these vibrant, active communities were designed to foster collaboration on specific projects, they do exemplify the traits that local agencies will want to incorporate into their own collaboration strategies, specifically:
- Implementation of a wiki-like technology. There are dozens, if not hundreds, to choose from, with open-source, proprietary and cloud-based products available. Agencies should pick one that best fits their current IT architectures and can meet future needs.
- Building a team. Beyond integration, who’s going to be in charge of the wiki? Who is the Great Redactor of Agency X’s living documentation? Ideally, find someone with a knowledge management background. Failing this, look for outside help from a consultant or vendor.
- Designing the backbone. Before unveiling the system to end users, the project team should create a baseline, including general categories and tags. This helps enforce a specific taxonomy and keeps dozens of similar pages or categories from cropping up.
- Taking it slow. There’s no need to rush the collaboration platform out to the masses. Agencies should add users in stages and build information slowly. This gives each successive wave of users a base of information off of which to work and edit.
Finally, don’t ignore the impact that collaboration will have on networks. Collaboration platforms, particularly wikis, are proven technology, but they’re still a unique animal to the agency network environment and need to be managed as such. Although the tech is easy to implement, federal IT teams need to recognize that collaboration needs just as much management as their databases and e-mail systems.
Beyond this, the collaboration platform can actually be integrated with agency network management — as the IT management tool detects problems, best practices and an expert knowledge base are instantly accessible, becoming a built-in part of the remediation process.
And that’s it. Collaboration isn’t the bogeyman that agency decision-makers seem to think. The technology is proven, the security is tight, and the need is obviously there. So really now: Why can’t we talk?