The White House recently announced that it has moved to Drupal, an open source content management system (CMS) to power the WhiteHouse.gov website. This is great news as it legitimizes the use of open source within the federal space. Federal CIOs should realize that most of the web is powered by open source software including premier web properties such as Google and Facebook.

WhiteHouse.gov is now powered by Drupal.

The new White House system runs on what is called a LAMP technology stack (Linux, Apache, MySQL and PHP). The LAMP stack is all open source. It is widely considered secure, offers high performance and is stable.  The White House chose Red Hat Linux as their supported distribution, and for enterprise search they are using Apache Solr. After the story was announced via the AP, Tim O’Reilly blogged the details of the technology choices and the reasons for making the switch.

More than just security, though, the White House saw the opportunity to increase their flexibility. Drupal has a huge library of user-contributed modules that will provide functionality the White House can use to expand its social media capabilities, with everything from super-scalable live chats to multi-lingual support. In many ways, this is the complement to the Government as Platform mantra I’ve been chanting in Washington. When you build a vibrant, extensible platform, others add value to the foundation you establish; when you join such a platform, you get the benefit of all those features you didn’t have to develop yourself.

Interestingly, Chris Wilson writing for Slate, has a different take:

I wish Drupal and the White House nothing but happiness. But I have a feeling this story ends badly. If the administration had conducted a few polls among the swing demographic of Web site administrators, it would have realized that Drupal is pocked with political landmines. To wit: Drupal represents everything the Obama team does not want to project.

Unfortunately, Wilson doesn’t offer any alternatives. The only real open source choices in my mind are Drupal, WordPress, Joomla! or Alfresco.

Many large organizations use WordPress MU to engage with their audience.

WordPress started strictly as blog software but has evolved nicely into a Web CMS. Many large organizations use WordPress MU such as the Wall Street Journal, New York Times, CNN and 10 (UK Prime Ministers site) to name only a few examples. My feeling is that for something as complex as the WhiteHouse.gov, WordPress does not have the robust features needed for enterprise-class CMS. Although it should be noted that the White House Office of Science and Technology Policy (OSTP) runs on WordPress.

Joomla! Is popular but has the reputation of not being secure enough. Which leaves us with Alfresco, an enterprise CMS that is used by the likes of FOX to power Fox.com.  Alfresco uses J2EE and Java instead of Apache and PHP. Alfresco is built by a team of original leading members from Documentum® and Vignette with 15 years experience in Enterprise Content Management (ECM).  Alfresco could have been a real viable alternative although the number of qualified developer partners is rather limited compared to Drupal.

My take on all of this is that the White House made a solid decision in choosing Drupal. What I would love to see is for GSA to offer Drupal as a platform for agencies that need a robust CMS but don’t want to manage their own LAMP infrastructure. Along with Drupal if GSA would offer WordPress as a platform (with agencies having their own unique URL), that would be heaven.  Hopefully, GSA CIO Casey Coleman is working on this platform as a services (PAAS).

IdeaFactory screenshot

It started as an experiment.
TSA Administrator Kip Hawley had sent a brief email to his senior leadership team saying, “This is almost exactly what I have been talking about. Very simple, digg-like, truly interactive…” Administrator Hawley, a tech savvy executive if there ever was one, had come across the Dell IdeaStorm website the night before and thought that TSA could use this technology to give a voice to his large and geographically dispersed workforce.

Don’t be afraid to fail. Call the initiative an experiment in order to manage expectations and to streamline the deployment process.

Ultimately, the “KW” (Kip Wants) filtered down to my boss Kevin and my ninja-coder colleague, Jack. After brief inquires to find that the IdeaStorm website was built by a company called, “Crispy Ideas” and they were not taking any new clients as they were being acquired by Salesforce.com, we decided that the three of us (all feds) could build the web application on our own. 

From the time we decided to build the tool ourselves to the day we launched the application was six weeks. Administrator Hawley and Deputy Administrator Gale Rossides launched the TSA IdeaFactory via a webcast to all TSA employees on April 25, 2007. We seeded the IdeaFactory with a few ideas just before the webcast as we did not know if anyone would use the site or want to post ideas. It could have been a huge flop – and we were OK with that outcome. Our position all along was that the IdeaFactory was just an experiment.

Innovation Lesson 1: Don’t be afraid to fail. Call the initiative an experiment in order to manage expectations and to streamline the deployment process.

Take Action: Create a formal internal process that permits an initiative to be designated as “fast track”. Create a streamlined process and Rapid Application Development (RAD) team that allows for rapid development and deployment.

Fast forward two and a half years later, the IdeaFactory has become an ingrained program within TSA. As of September, we passed a notable milestone; the IdeaFactory has generated 10,000 ideas (including 290,000 ratings and 80,000 comments).

10,000 ideas "built" by TSA's employees and contractors.

The success of the IdeaFactory program has drawn the attention of The White House and they have featured the IdeaFactory as part of the Open Government Innovation Gallery. We have participated in several meetings with the White House Office of Science and Technology Policy (Innovation Tools Subgroup of the White House Innovation and Information Policy Group) and they have produced a document on sharing software innovation programs within the US Government.

The IdeaFactory is featured on the White House website

Towards that end, TSA and the Department of Housing and Urban Development (HUD) are about to complete an agreement which will allow us to transfer the IdeaFactory software and program guides to HUD.  The first of perhaps many such agreements.

At the request of the DHS Secretary Janet Napolitano, we are working with DHS to roll-out IdeaFactory to all of the DHS component organizations. By the end of this year, all of the DHS employees will be able to post ideas for improving the organization.

IdeaFactory was the first of several efforts within TSA to engage internal and external audiences. In the near future I will write about the TSA Blog which is widely considered the best example of a federal agency blog. Our blog also passed a major milestone; in September we reached one million page views. With close to 200 posts, we continue to engage the public in meaningful dialogue.

I’ll also discuss how we have created an internal collaboration platform (iShare) to facilitate information sharing and how to manage “unstructured data”.  And in November, I’ll blog about our most ambitious “Gov 2.0” effort at citizen engagement. Just in time for the Thanksgiving travel rush.

Photo, Tim Morgan. Some rights reserved.

Have you spent any time at the service department of your local car dealership? I’ve brought my car and SUV to two different dealerships and the experience was pretty much the same – quality service; done right and on-time.

CIO’s can learn a lot about how automobile dealerships are organized to deliver quality service, thereby earning a profit. For government CIO’s earning a profit is not a consideration, but delivering IT solutions whereby the customer’s definition of quality is of paramount importance.

The Service Department Manager is ultimately responsible for the delivery of services, customer satisfaction and profit. The service department is organized into several “teams”. In some dealerships trucks may be assigned to the Red Team, SUVs and mini-vans are assigned to the Blue Team and standard sedans assigned to the Green Team.

Each team lead (a.k.a. service advisor) is responsible for meeting with the customer, gathering “requirements”, and communicating costs, a timetable, and overall expectations. The team lead then works with the mechanics to ensure that they have the resources necessary to complete the job.

There is an important lesson here. It is insufficient to the bottom-line to just have quality people in your organization. The way in which people are organized and structured is critically important to achieving successful outcomes.

The knock against Government IT organizations

The narrative that government CIOs may hear from their peers and agency heads is this:

1. Customers feel you are not engaged or understand their priorities;
2. It takes far too long to deploy applications and services;
3. It costs too much money to deploy technology.

In my view, CIO’s should have a laser focus on three areas: customer engagement, time to deliver, and cost effectiveness.

In large Information Technology (IT) shops – particularly within the government; the CIO has not aligned the internal organization in a way that focuses on the three challenges listed above. Often the organization is structured in such as way that there are too many touch points between the various IT divisions.

For example, there may be an account management team, a network infrastructure team, a platform infrastructure team, an IT security team, an applications development team, a testing team… on and on it can go. The level of coordination and cooperation that is necessary to make this work is dauntingly complex – and largely unnecessary.

Align Apps Dev along technology platforms

CIOs should create application teams whereby the team lead is entirely responsible for meeting with customers, gathering functional requirements, building and deploying the solution. This can be accomplished by creating teams that are aligned by technology platforms.

For example, create a team that handles the Sun Solaris, and Oracle environment. Create a team to manage the Microsoft .NET environment, a team to handle Microsoft SharePoint services, and a team to handle the open source (LAMP) environment.  By creating these semi autonomous teams, they have control over the entire process – from client communications, requirements to development and delivery.

This structure eliminates the “seams” between organizational groups because specialists are matrixed into the team.  The IT security specialists reports and ultimately receives his yearly evaluation from the team lead.

“Free Market” competition for client funding

The other advantage to this approach is that it creates a healthy competition between the teams. Competition is the key driver to overcoming the three principle challenges to the CIO (customer engagement, time to deliver and cost effectiveness). If the Sun/Oracle team would take too long and be too costly to deliver the app, the customer could go to the Microsoft .NET team instead.

This healthy internal marketplace would ultimately lead to technology stacks becoming too costly and too inefficient to operate compared to other technologies. Perhaps over time, if it became apparent that the Sun/Oracle platform is not cost competitive, the CIO would put the platform into O&M mode.

New application teams could be stood up to follow best practices in the private sector. In addition to the technologies mentioned above, a team could be created to handle applications using commercial cloud computing services such as Google’s App Engine or Amazon’s EC2. As one technology stack became “uncompetitive” other application platforms (and their teams) would be stood-up.

Ultimately, if CIOs are to meet the challenge of customer engagement, rapid deployment, and low costs; CIOs should strongly consider an organizational structure that included decentralized, empowered teams focused on delivering applications and IT services.