« November 2008 | Main | January 2009 »

3 posts from December 2008

December 31, 2008

A Fresh Look at Cloud Computing in Government

Anyone reading technology blogs or trade publications in 2008 has heard of Cloud Computing as the current/next big thing.  I wrote a blog entry on cloud computing in August and sent a request out over Twitter today seeking examples of cloud computing being used in government to see if I could pull together any new, useful, information.  I referenced this article where Google touted the potential of cloud computing in government back in June to see if there were any fresh examples of government using cloud computing.  I'll get back to the examples later.

What is Cloud Computing? 

Gartner recently listed Cloud Computing as one of the top 10 technologies to watch.

There is a good definition at Wikipedia.  To borrow from that definition, cloud computing is the act of accessing technology-enabled services over the Internet.  Cloud computing is a general concept that incorporates software as a service (SaaS), Web 2.0 and other recent, well-known technology trends, in which the common theme is reliance on the Internet for satisfying the computing needs of the users.

By this broad definition, virtually all Web 2.0 applications (Facebook, Twitter, MySpace) qualify as cloud computing applications as do SaaS systems like Salesforce.com.

Again, sticking to the broad definition, cloud computing is used widely in government.  Government has not yet adopted software as a service applications quite as broadly a the private sector, but there is still very broad use of software as a service particularly for inbound and outbound digital communication.  Of course, my favorite example is our company, GovDelivery. 250+ governmental organizations across 25 states and 13 of 15 federal departments send mass email and wireless notices to the public using our platform.  We used to focus on functionality and downplay the "in the cloud" nature of our system, but with all the benefits of being centrally hosted (easy collaboration between clients, better functionality, more scale, faster deployment) we now use it as a selling point.

If you want a non-GovDelivery perspective on the benefits of SaaS, here's an article offered via @appirio_kirk on Twitter today describing how DC govt. is now using Google as its corporate email client

As I noted in my last entry, I don't completely buy the broad definition of cloud computing.  I think that SaaS / hosted services that ask you to use an application in pre-determined "wrapping" are very powerful, but true cloud computing is about leveraging application capabilities  and storage  "in the cloud"  without using a prescribed user interface.  So, logging into Facebook wouldn't qualify as cloud computing, but using a Facebook application that automatically stored pictures on Facebook when you saved them to your home computer would qualify.

Why does one definition matter over another?

Because, particularly in government, there is broad embrace of SaaS services and platforms  such as Facebook, GovDelivery, Comcate (local government CRM), and various Google applications, but government is in only the early stages of tapping into the powerful capabilities offered by these vendors as well as by Amazon and many startups that would enable government to more rapidly deploy custom applications by tapping into storage, processing, and messaging services on an "as needed" basis.

I think I understand why.   We launched an "On-Demand Mailer" capability earlier this year.  Our beta client, the National Labor Relations Board is using this cloud-based service as its email sending engine for a custom-built application that notifies lawyers of new rulings.  NLRB is a highly-sophisticated client with some uniquely talented staff.  We have many clients like this, but you have to catch the right people at the right time when they are building applications that need this type of service.  In addition, much of the application development in government is done by integrators that have not yet embraced the power of cloud computing (and in some cases may see it as a threat to their current business model).

In other words, our "fully-wrapped" service is much easier to sell.  It's easy to understand and the benefits are clear.  Successful use of cloud computing within a custom application requires a motivated developer / architect that is actively seeking shortcuts that will allow him or her to deliver a better solution with less time and cost.  It's a paradigm shift that can't be encouraged by a vendor quite as easily.

To get you thinking of what's really possible with cloud computing, I want to point out some additional examples that came up on Twitter today.

One is this amazing public data service from Amazon that allows you to tap into Census and Human Genome project data stored on Amazon servers:  http://aws.amazon.com/publicdatasets/   (Thanks to @Rchards).

Another example that requires a little more technical understanding to digest is GoGrid which offers storage and more advanced server infrastructure in the cloud.  HighTechDad is their technology evangelist and indicates that they do work with government today, but that governments don't always like to admit they are using the cloud (something I think is less true everyday as many governments are trying to demonstrate their ability to use technology to save money these days).  HighTechDad also maintains a blog here where he has an absolutely superb explanation of cloud computing that is better organized and better thought through than this entry (though hopefully I've brought in some extra perspective on the government angle).

If you find this useful or have your own examples of governments using cloud computing, I welcome your comments and feedback.  From a selfish GovDelivery perspective, I'm also looking for creative ways to better expose this type of service to anyone building applications within government (particularly within those government bodies that are already using our platform in it's "fully-wrapped" state). 

We had terrific attendance at our recent webinar, but we need to continue reaching out to agencies that might want to take the leap to embracing the power of the cloud when building custom applications.

Happy New Year!

December 22, 2008

Public Sector Agencies Continue to Embrace Social Media

As Web 2.0 technologies become increasingly popular, government agencies can truly benefit from experimenting with existing social media tools and collaboration capabilities.

It is widely believed that government officials have been slow to take advantage of these technologies, but in actuality public sector agencies are adopting Web 2.0 tools quicker than you may think. In fact, some departments of the U.S. federal government, including the EPA and DOD (both GovDelivery clients), began adopting these tools as early as 2006.

Government officials have come to view such tools as blogs, wikis, and social networking as cost-effective alternatives to traditional communication channels. In many cases, Web 2.0 provides a direct line of communication to an audience that is otherwise difficult for government to reach. We've provided a number of examples before, but the State of Iowa serves as a great illustration of how agencies can be selective in utilizing Web 2.0 tools that will best help to accomplish agency goals.

How Iowa state agencies leverage Web 2.0 technologies:

Iowa Lottery
  • Shares the excitement of winning through YouTube videos of lottery winners
  • Reveals winning lottery numbers through text-messages and "Tweets" on its Twitter page
Iowa Department of Transportation
  • Takes to its blog to communicate news releases and traffic incidents
  • Reaches out to a younger audience through Facebook and YouTube to engage in a teen traffic safety contest
Iowa Department of Public Health
  • Sends text messages to teens regarding the "Just Eliminate Lies" anti-tobacco program
Iowa Homeland Security
  • Distributed podcasts of news conferences during floods earlier this year

Read more of the article, "Government officials embrace social media," by William Petroski at DesMoinesRegister.com. 

December 04, 2008

Thinking through your Content Management System Needs

You've been talking about it for a while, but now your organization has finally decided to get a new content management system (CMS).  This is the "BIG" project of the year.  All of your hopes and dreams for where your website is heading are wrapped up in your CMS project. 

In fact, if you're a typical organization, everyone has started to project their own goals onto the project.  "We'll have that fixed when we get our new CMS," they say, and, "That will all be addressed with our new CMS." 

Goals for almost every CMS project:
  • Keep content more up to date
  • Allow individual "content managers" easier access to update their areas of the website
  • Create a more consistent look and feel for the organization
  • Make search indexing and search within the site easier
  • Improve navigation
More advanced goals for your CMS project:
  • Improve content structure: Produce content in multiple standard formats so it can be reused by other websites and systems
  • Support improved navigation: Publish content with appropriate tags and categorizations so that new content appears in all appropriate locations rather than just in one place.  For example, if you publish three safety publications on water, fire, and snow, the publication on "fire" should appear in the fire safety area of the website as well as the "safety publications" area without much extra effort
  • Works well with other technologies (Web 2.0 widgets, other systems you buy, etc.):  Your CMS needs to "play well with others."  If you are looking at CMS vendors and the vendor says, "we do that" in response to all of your questions, that is red flag.  CMS are not best in class at everything.  You may want to use YouTube for video, Google for search, GovDelivery for email communication, and Wordpress for blogging.  Find out how the CMS will work with these systems rather than hoping the CMS will do everything you want.
5 outcomes you should expect from your content management project:
  1. New content can be posted within 15 minutes by any approved individual in the organization. 

    I know that some content has to be approved, but if your project is more focused on "workflow" and approvals rather than efficiency, you may want to rethink things.  The fact is that in order to be current, Web content cannot be bottle-necked by cumbersome approval processes.  Set policies and guidelines for content and let people publish without too many extra steps.  As long as you're not publishing the new interest rates, you can make edits later without major consequence.

  2. Any web page can be published as an XML / RSS Feed at the same time as it is published in HTML.

    This ensures that other Web managers, bloggers, and even other systems (including GovDelivery) can read and interpret your page in an automated way.  In the Web 2.0 world, this type of openness and sharing is important and will ensure that your content "has legs" and gets reposted and repurposed across the Internet.

  3. All web pages are easily indexed by major search engines.  I'm not an expert on this, but it's an easy topic to research online.  Google has all kinds of tools for this at www.google.com/webmasters

  4. Content can be published to multiple locations at the same time without too much extra effort.

  5. Your system supports a user-centric design. 

    Oops, you thought your CMS project was going to give you a "usable website."  If that's the case, you should stop right now and focus a bunch of time on the design and usability of your website.  A CMS is for managing the content on your website.  If you have a poor design and a good CMS, you will just have very up to date, but unusable content.  

Finally, you need to have a way of capturing information from people who are interested in your content so you can reach out to them when updates occur.  My company, GovDelivery, works with government websites on this and has found the following best practices to support the rollout of new content management systems.

  • Have a proactive communication system in place before you launch your CMS. Why? You want to know what people are interested in on your current site so you can focus more effort on that content and make sure people know how to find it when the new website is up and running.  Even the best redesigned websites often annoy their most regular users.  You can help prevent this frustration by allowing regular users to signup for updates before you rollover to the new CMS when links/designs/navigation will typically change dramatically.

  • Make sure that your new CMS will work with whatever proactive communication solution you are using or plan to use to allow you to automatically send updates when you publish Web content.  You don't want to publish Web content and then have to login separately to send email.  In GovDelivery's case, if you publish information in RSS or can connect to a Web Services API, you'll be able to automate your outbound email communication.

This is a complex topic that I will return to if there is any interest.  When I mentioned I was writing this blog entry, I got some great links to other resources on vendor websites and regarding open sources CMS.  If the topic is of interest, I will write another article on vendor selection.