Cross-posted from my Intelink blog. I realized that if I’m going to talk about Federal cloud computing, I should get input from the Federal community. 😉
I’ve been thinking a little bit about cloud computing lately and am wondering if the whole Federal government should be part of the same cloud, or if there should be sections of the cloud. I’m leaning toward the former, but am open to comments.
Also, if we had one big government cloud, wouldn’t it be great if each of us could login using the PKI cert issued to us by our own agency? I would hope this is something that the Federal Bridge could support.
If it works like Google Docs, will we be able to set permissions for people by email address, by cert type, by agency, etc.?
Posts and Papers I’ve been reading on this subject include:
Seems to me that the new FCTO and FCIO have some good ideas on moving into the cloud… not sure if ACT/IAC put up comments from last week’s Mgmt of Change conference, but might be a good resource to look at…
Don’t see one big cloud happening in my professional lifetime….
IMO TOO much of major power struggle over whom would control what!
I’m afraid Henry is right. Somebody at the very top needs to tell the rest of the kids to “shut up and color.” 😉
Having all of the Government be part of the same cloud kind of defeats the largest oppourtunity of Cloud Computing. Instead think of what type of security framework could be wrapped around Government Applications and Data that live in the Cloud and how these security frameworks could be syncronized and managed. PKI is one approach where some type of Fed Portal holds one of the keys and when your data/ app in the cloud is accessed the Fed Portal key could be used. Unfourtunately I dont think that PKI in it’s current form would work in this manner. Somthing to ponder though.
My hope is there is enough momentum on cloud computing plus the new CIO has time to exert his authority and make this happen. I think there are lots of opportunities to use a federal cloud to rapidly deploy applications (that have already been set up at one agency), save the taxpayer money, and leverage some interesting collaboration across the federal sector.
Given that much of the reason for pursuing the cloud lies in economies of scale, I think we need to look harder at how many federal cloud providers we really need. Why not a common cloud provider for unclassified (GSA), one for SIPRNet (DISA), one for JWICS (ODNI)?
Rick:
The last administration tried this with some level of success, the program was called the “Trusted Internet Connection”. Apparently the federal government went from some several thousand Internet facing systems to something less than 300. The agency that pays my salary looked at cutting their internet facing systems from 4 systems, Not sure how much progress was made, I believe that we do in fact have all the systems that we had over a year ago.
While I would love to see a “federal cloud” I still believe the politics are too strong. I do think that it will lead organizations to look at their own computing power and provide better governance of what they have internally. The biggest problem with “a cloud” is that applications / deployment methodologies need to be changed to take advantage of the value of the cloud. We need to look at applications today and determine how long it takes to expand them to an additional server. This is after the hardware is acquired and appropriated. OS load, application server, application, network, load balancers, etc.
If we are looking at the service model for cloud computing (i.e. disk storage, queues, etc.) then we need to get a better handle on the authentication and authorization methodologies being put in place. While PKI does a good job at authentication of users, it doesn’t do a good job with services trusting one another in the cloud to do work for a user. Things like attribute/policy stores, secure token services, etc. need to be put in place to manage what applications can do work for users in the cloud and who is initiating the services across the cloud infrastructure.
I keep hearing about the promise of a federal bridge, but I am still seeing each organization worry about who has control of the “router” that is the bridge and who has access to the logs. If organization C owns the bridge and as organization A I use a lot of services from organization B I worry that organization C can read the logs to see this pattern. They might not know what the service organization B provides, but the fact that I use it a lot might peak interest. As much as we all want to believe the organizations are starting to trust one another there still is a high level of distrust between them.
@John Younkin: I’m not sure I understand what you mean. Doesn’t somebody have to administer the cloud and the rest of us just use it? Or maybe I misunderstand cloud computing… I agree that PKI would have to be part of the architecture. There’s supposed to be a Federal Bridge program to allow for this, but I think it still needs work.
@Rick Holgate: What you suggest is along the lines of what I was imagining as well. Although some people would split into four clouds: purely unclassfied, FOUO/SBU/CUI, secret, top secret
@Henry Brown: That may have been a good first step! I’ll have to look into that a little more.
@Matt Topper: Optimism is good. Join @GovLoop and I as we continue to hope that our new CTO and CIO will push hard enough to overcome politics. 😉
From govfresh blog
Why Gov 2.0 means the U.S. Government must centralize its Web operations
* By Luke Fretwell on June 9th, 2009
In an earlier post, I offered recommendations on centralizing U.S. Government Web operations, which seemed naive or misinformed to some.
Here’s what I recommended:
* Centralize all government Web operations under one agency
* Hire a Chief User Experience Officer
* Unify look/feel of all government/military Web sites
* Hire talented writers and editors to produce quality content
As I’ve added new GovFresh feeds for various departments, agencies, military branches, and more, I’ve visited many of the government-operated sites over the past month.
Here’s what I’ve found:
* Lack of unified design
* Disjointed use of Web platforms
* Inconsistent editorial and content
* Outdated Web design practices
* Development redundancy
While all of the above don’t hold true for every site (there are several fantastic government sites), at least one of the above does.
Here’s why the U.S. Government must centralize its Web operations:
Development
One open-source platform would allow for a more agile development process and more scalable, cross-site features to be built quickly. Code could be re-purposed, rather than re-created. Eventually, interactivity, preferences and personalized updates could easily be built, which would allow citizens to actively engage in the political process or manage their government services, 21st century style.
Usability
Centralized usability tests and site metrics reviews across a more unified design would allow managers to re-vamp the UI/UX accordingly. Best practices could be realized and executed immediately across all sites. This includes design and editorial. Actively soliciting user feedback and executing cross-sites would be invaluable to the user experience as a whole.
Brand/design unity
In the corporate sense, “U.S. Government” is a brand. When a user arrives on an official U.S. Government Web site, it should be apparent. The brand and aesthetic should convey “this is an official U.S. Government Web site.” Fonts, colors, consistent top-level navigation or a uniform toolbar could achieve this. You can still retain micro-brands within the major. Agencies wouldn’t dilute their individual branding. They would just be more aligned with the U.S. Government style guide.
Content
A content management strategy, standardized writing style guide, solid editorial staffing and content managers that liaison with respective agencies would go a long way in presenting content in a more clear, concise, accessible format.
Financial
An open-source platform would allow for cheaper development costs. Not having to wait for budget allocation or go through the government contract proposal process for an entire Web project means more agencies will get a stronger Web presence. You could better staff and meet demands, especially with a strategy.
Strategic
A strategic management team would see the entire U.S. Government Web operations from a high-level perspective and direct the user experience accordingly, free from silo operations. It would work with key contacts within various agencies to assess objective, mission and help focus and execute the appropriate Web strategy. This includes social media activity.
Transparency
The more user-friendly the Web site, the easier it is to understand what’s happening throughout the public system. Agencies can receive feedback and interact with their core constituencies to know what services should be offered, and what shouldn’t. The side affect of a unified Web platform breeds transparency that allows us to hold the government accountable and more actively participate in the democratic process.
While I understand each agency may have a need for different tools or design, non-standard needs can be addressed and properly integrated. It doesn’t have to be cookie-cutter, just more unified, efficient and strategic. Actively collaborating with internal agency contacts allows them to focus on what they do best and leverage the expertise of a solid Web operations team.
America has the best and brightest Web minds in the world. There’s no reason why we can’t build a flexible but “united” U.S. Government Web platform that gives citizens a better customer experience than the 1.0 version we’re getting today.
Thoughts or solutions from others?
Can I agree with half of what you wrote? 🙂
My own pet peeve – and quixotic campaign – it to get what I call, not knowing the right terminology, a federal extranet. Here is what I mean: my agency has an intranet full of information useful to employees, and it has an internet presence for any Tom, Ricardo, or Hiroshi anywhere in the world who wants “public” agency information. But every agency other than mine treats me no better, info-accesswise, than a Lithuanian hacker. To be specific, there’s tons of info I need to do my DHS job on the Department of State intranet, but I can’t see it. Why not?
Doug
I think Henry’s on the right track, and the comments above regarding efficiencies of scale get to the heart of the matter. A federal cloud, broken out through strict federated identity management at varying security levels would drive down federal IT spend enormously. SW licensing, ease of use, common training models, and service levels provided by industry are all benefits. The most glaring issue I see, however, is what to do with the extraordinary number of custom and proprietary apps each agency is running on non-standards based systems in the famous “stove pipes”. To merely discard such tremendous IP as non-COTS waste would be overlooking the competitive advantage those apps give their respective agencies. I’d be interested in what others see as other problems to be overcome.
The only problem I see with your grand plan is funding. Most of the reason we are disjointed right now is because our web efforts are as stovepiped as our funding. And it would literally take an act of Congress to change that.
I think there are a lot of good solutions and thoughts posted on this blog on how best to leverage the ‘Cloud’ for federal websites. In my opinion one way to look at cloud computing is not only as a new technology platform but as a new way for the federal agencies to get increased purchasing power – a whole new purchasing paradigm that hopefully most will agree will help greatly to stretch the IT dollars. With deficit spending at all time high and our country looking at unprecedented debt levels, hosting the US Government web operations and other applications for that matter in the cloud – be it a private cloud for security reasons will be a great opportunity. The biggest caveat IMHO will be the ability and willingness of FCIO of various agencies to come together and agree to a platform and then negotiate hard with the vendors to help reduce their IT costs.