At first, shuttered government websites smacked of political statement to me. Four other factors apply -- but none of them explain the decision to shut off the Panda Cam.
I couldn't believe it at first when I saw that websites from Data.Gov to the Library of Congress and beyond had been eviscerated and replaced with splash pages reading, "Due to the lapse in federal government funding, this website is not available. We sincerely regret this inconvenience." My first response was irritation. Since when would an automated system need staff to run it, at least in the short term? On the surface, it would seem that it would take more effort to shut them down than to keep them running, so the motivation would appear to be political or "I'll-show-YOU" maneuvers.
As a government employee, I firmly believe that staff (as opposed to political appointees or elected officials) has a responsibility to avoid politics and to take actions based on business objectives. So, shutting down systems that could have continued operations just as easily (with a caveat that no support is available) smacks of making a political point.
Yet, on further reflection and discussion with colleagues, there ARE at least a couple of reasons why politics might not be involved.
1. Insourcing vs outsourcing.
Call it cloud versus premises or what you will -- but if there is a restriction on pay-as-you-go spending, then if you don't pay, you don't go. In this scenario, it would make perfect sense for websites to be shuttered. No authorization for the credit card means no compute or storage for your agency.
2. Power spending.
One colleague pointed out that for some of these apps at large scale, spending on power for the data center might be enormous. No running the Library of Congress apps using your home power circuits, we're talking serious juice. The database and app servers are likely the lion's share of the architecture so keeping the front end servers lit would probably save a bunch of power. I'm not sure -- and both my queries and those of Wyatt Kash, InformationWeek Government's editor, were not returned, presumably because our contacts are on furlough, so it's hard to say.
Another colleague pointed out, again, quite correctly, that securing government apps is not exactly like securing your brother's WordPress site. The Federal government presents an enormous attack surface, and the odds are that they have to deal with DDoS and other types of attacks on a weekly, if not daily basis.
We often say that we want our government running like a business. I am a big fan of that. It makes my heart happy when I see government units reporting, reviewing and adjusting on a quarterly basis, instead of the more common-to-government annual basis. So when I put my business glasses on, I wonder: who would leave a factory running, no matter how automated, if funding went away? There's just no way that would happen. All too often, IT simply "absorbs" cuts, reasoning "sure, we can handle that," but in reality, as a nun once said to my spouse, "no money, no mission." Cuts without commensurate service reduction often lead to unintended consequences: My colleague's observation about security is just one. So, it could be that responsible business leaders in the IT units at the government would rather have an "intended" consequence of funding being cut and have an orderly shutdown than to risk an unintended and possibly worse consequence.
It is, however, hard to argue with my other colleague who's finding it hard to believe that ANY of the above 4 reasons are the reason to shut down the "Panda Cam".
Yet, we need to realize that the Federal government is as large as many, many enterprise businesses, and there are a diversity of use cases and a diversity of leadership. In many cases, the Web shutdown may be completely valid. For those cases, I just wish that there had been customer communication that clarified the pragmatic reasons for the shutdown.
InformationWeek Must Reads Oct. 21, 2014InformationWeek's new Must Reads is a compendium of our best recent coverage of digital strategy. Learn why you should learn to embrace DevOps, how to avoid roadblocks for digital projects, what the five steps to API management are, and more.