Inside GSA's call for a better cloud portfolio

Some may not think the words “innovation” and “federal government” belong in the same sentence, but you might be surprised at what the General Services Administration, is setting out to do as it embraces the cloud.

Here’s a bit of background:

Believe it or not, the GSA stood up its first dedicated cloud computing effort almost seven years ago, and as you might imagine, moving vast swaths of the federal government to the cloud is no small task.

Recently, we took the opportunity to review the GSA’s Office of Citizen Services and Innovative Technologies request for information on five key areas the agency had identified where contractors could help the GSA build a better cloud portfolio. Below are our thoughts and insights into the five areas where the GSA sought advice:

1. Government-wide technology program experience

In our experience, there are three critical components: designing, implementing and evaluating. Because each scenario will be different and require customization that matches the differing missions of each agency, it’s imperative to examine closely the scope of the migration, security requirements and different workloads.

When implementing a move to the cloud, ideally it should be a seamless move for all parties, particularly end users. It’s important not only to have the ability to virtualize the current storage but also provide the flexibility to move that to the cloud.

2. Best ways to build a government-wide program

Challenges. Typically, the path to entry into the federal government space is quite difficult for startups and young companies. At the same time, it can be challenging to cover all the contractual obligations the GSA puts in place to secure a GSA contract. Finally, a huge limiting factor can be companies’ inability to be nimble with GSA schedules and the product timelines government contracts often require.

What does work. Using products that are easy to scale out, product schedules and professional services that are easily modified when needed, and vendors that are nimble and educated on how to work across the different types of agencies are all important considerations.

Flexibility and speed are also key. For instance, bear in mind that the approval process can be lengthy and placing line items into the contract often requires extra diligence. Also, remember that expedited orders don’t necessarily equal a fast implementation.

3. Striking the right balance between products and services

Hitting this balance correctly depends on the agency, its mission, and what applications are currently in use or planned to be deployed that will be successful in the cloud. Determine which applications the agency is using and which are good candidates for the cloud.

Following this cloud assessment, decide on which ones to move based on factors including the total cost of ownership against those applications, the planning phase of the move, as wells as knowing which vendors can actually move the applications and have a proven track record of doing so at the government level.

Lastly, we definitely recommend a debriefing on the lessons learned: the cloud is an evolving architecture with a constant influx of new products to handle different workloads and the migration of those workloads.

4. Forging productive partnerships

Among the biggest challenges with respect to cloud technologies are how the government agency itself is structured and its approach to how it handles employees managing its technology. For example, most agencies have a 2:1 contractor-to-government-employee ratio, and they also keep people on staff to support the various architectures.

With cloud adoption in the government, it’s important to consider that the government may start limiting the number of employees needed on staff from a prime contractor perspective.

And there also inhibitors and missing links to productive partnerships to keep in mind: Some large contractors may be reluctant to move data to the cloud because that means fewer people and fewer billable hours; also, hardware manufacturers (especially HDD sales) are losing lots of money to cloud providers.

5. Thinking like a startup

In the GSA’s request for information, it noted that the OCSIT consistently builds projects on small budgets with outsized impacts. In helping the GSA to think more like a startup, keep in mind that startups excel at bringing bold new products to market because they give their people lots of room to run. Try new approaches and experiment.

We recommend assembling teams of five to ten people, with a mix of recent college grads paired with some senior leadership that includes smart and creative engineers.

Also, start the move to the cloud with non-mission critical applications or low-risk ones. As these scenarios are tested, then start ratcheting up to the more mission-critical applications. At the same time, it’s important to duplicate these mission-critical applications in a test environment; it’s an excellent way to iterate and streamline.

And, of course, it keeps the day-to-day mission safe while being able to evaluate the problems that may arise in a production environment.

If the GSA keeps these insights and tips in mind (along with, no doubt, excellent suggestions made by other organizations in response to the request for information), we think they’ll find the ongoing shift to the cloud in an organization as vast as the U.S. government far easier to navigate successfully and without too many bumps in the road.

About the Author

Randy Hayes is the regional manager for federal government sales for Avere Systems.

Reader Comments

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above.

What is your e-mail address?

My e-mail address is:

Do you have a password?

Forgot your password? Click here

Washington Technology Daily

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.


contracts DB