As pointed out in a recent GovTech article, social media has been opening up transparency for government agencies—like law enforcement—as more of the these agencies allow employees to use Twitter, Facebook, and other social media to let the public know what is going on. Many government offices even have their own official Twitter and Facebook pages so members of the public can keep constant tabs on the day-to-day activities of their local, state, and federal government. (Just yesterday, in fact, the Greenfield, Calif., PD announced that they have created a Facebook page and have been furiously adding photos to their site.)
However, all this constant public communication does create some problems. Government entities are already required to archive official communication delivered through traditional channels. But, currently, most government agencies have no mechanism or policy in place for archiving social media communication.
The Problem
The problem lies in the fact that the agency should be able to produce an archived copy of official communication, but the current, external platforms don’t necessarily provide a reliable way to archive and house this information for government agencies.
A Communication Shift
I guess this is the long way of coming back to a point I have made in the past: that relying on Twitter, Facebook, and other external social media applications should not be the end goal of law enforcement communication practice. These applications are only the beginning of an overall communications shift, and—as such—new systems/policies need to be implemented in order to better accommodate this shift without losing the ability to archive and house public records.
Every Agency a Software Developer
In the GovTech article, Peter Larson, senior manager of IT operations for Douglas County, Colo., theorizes that government agencies could use software that could act as an interface for employees, allowing them to post to social media sites while archiving a copy of the message for the public record. Perhaps a system like this could be added to current email programs, and similar programs already exist. However, says Larson,
An agency would need to build its own to ensure its reliability. “If you were going to be on the hook for producing that archive, you would have to implement some sort of system you could have confidence in.”
High Cost, Inefficiency, and Isolation
But I beg to disagree. Agency-created solutions, as Larson suggests, come one step closer to turning every individual government agency, and every police department, into a software developer. In other words, each agency would have to find the money, time, and resources to create its own self-serve application that would work on their system alone, would not interface with other agencies, and would likely serve to increase budgets and further isolate government agencies from one another.
Standardization and Market Solutions
Again, what government agencies, including law enforcement, need are comprehensive software platforms that will not only let them interface with multiple social media service at once, but will standardize social media archiving practice and format. And standardization is vital for inter-agency communication and collaboration, saving time, money, and headaches.
We don’t need every government agency and police department to develop its own software. In order to keep costs down and improve efficiency, 3rd party vendors should shoulder the responsibility and cost of developing the technology. Whoever creates the most efficient platform for the lowest cost would eventually win.
James Gunter is the editor of The Crime Map and the director of social media for CrimeReports.com.
Get on the National Crime Map at CrimeReports.com
{ 1 trackback }
{ 2 comments… read them below or add one }
While the author acknowledges the problem, his suggestion to wait for someone else to develop a standardized, comprehensive program doesn’t seem like much of solution (and something of a pipe dream at that). And I didn’t suggest that everyone start developing software. My point was that although there are third party programs in their infancy that promise an interface to social media, agencies should be wary of relying on them as archives of official records at this point. My suggestion to build a system actually was geared more toward assembling those pieces an agency already possesses, such as email, a document management system, etc. and layer process in to assure that a copy of any official communication ends up where your records management policy dictates it should go. If a system pops up tomorrow that can interface to any social media as well as interface with any records management system or file archive, with a long term financial viability and great uptime guarantees, then we can all start using it. You would still need to build a system around it that includes people and process.
I’m glad you found my post and clarified your stance on the solution to archiving social networking communication. I’m also glad to see that you don’t believe agency-built applications are the only solution to this problem. Granted, a reliably-secure system does not exist yet, which we both acknowledge, and creating a network of current systems is definitely an option for agencies who want to find a solution right now. But single-serve solutions are not a long-term answer to this problem.
I guess what I see as the more over-arching problem is the short-sightedness of *some* government agencies, who have a we-have-to-build-everything-ourselves mentality when it can be done cheaper and more effectively in the private sector. It may not exist right now, but it can be done (basically, all you’d need is for TweetDeck, HootSuite, or a similar developer to come up with a secure archiving system). I believe it will be done right if there is a demand in the marketplace for such solutions, instead of just turning inward. Unfortunately, I’m not a programmer or developer and can’t come up with a solution myself, but I look forward to the person/company who can do it and keep agencies secure and happy.
Thanks again for your comments.