U.S. flag

An official website of the United States government

Dot gov

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Https

Secure .gov websites use HTTPS
A lock () or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

Acquisition Challenges

Acquisition Challenges

Over the past year, we have identified common acquisition challenges related to acquiring cloud products and services with the help from Federal Agency and industry stakeholders. We encourage you to review and understand these acquisition challenges as you start the process of acquiring cloud products and services within your own Agency. Our goal is to continuously develop solutions for each of these common challenges and share them with all of you.

Color of Appropriated funds for Continuous Flow of cloud service consumption

With the consumption of services the government is driven to use Operations and Maintenance (O&M) funds per policy. O&M funding is one year money and needs to be obligated to an acquisition (e.g., contract, procurement) prior to the end of the Fiscal Year (FY). Flexibility to obligate funds beyond end of FY is difficult if legally allowed. With Continuing Resolutions (CRs) become the funding norm at the beginning of each new FY it is difficult to have O&M funding available. Do we need special definition of funding that can be flexible across the FY changes? This will become more of a factor the closer we get to true consumable services and not one year term licensing.

Metered Services, Pay as you Go billing

One of the five NIST essential characteristics for a commodity to be "cloud" requires that the commodity has some fidelity of consumption metering so that the government's cost can fluctuate based on actual periodic consumption. Many vendors are selling "cloud" type commodities that do not provide a high degree of metering and some require a fixed price for a minimum of one year.

Service VS. Product Distinctions

Many "cloud" software type offers were previously clearly products under any definition. The NIST definition of "cloud" defines these offers as services, which implicates different rules and regulations. Task Orders (TOs) are used for services while Delivery Orders (DOs) are used for products. Some of the service regulations are not a good fit for Cloud. As one example, the NAICs codes that are used for service providers do not fit well for the companies that provide cloud commodities. Another example requires products to be paid for in advance, while services must be paid for in arrears. Currently, many cloud resellers are selling their services via gift card which is paid for in advance - which is likely against the spirit of the regulations.

Cloud Governance

What should the governance structure be of your cloud acquisition? Without proper governance in place, many funding, contracting, and general communication failures are likely. In preparation for a cloud award, Program Management Offices (PMOs) should be able to answer questions such as:

  1. If a Time and Materials model contract is leveraged, who in the PMO is monitoring the burn rate of the funding and in charge of alerting others that it is time to add more funds?
  2. Who has the responsibility of assessing cloud utilization reports for chargeback incentive purposes?
  3. Who has the authority to provision new cloud services under a Task Order? Who has the power to give authority to a PMO member to provision new cloud services under a Task Order?

Who is the cloud finance point of contact that can reconcile a cloud bill when the agency receives an invoice? How does a Cloud Project Management Office or other program entity reconcile the consumption of IT services that are by the month, day, hour and minute? It's the equivalent of asking at what point you should stop looking at your electric meter outside your house because it is costing you too much of your time. Government has to find a balance between their resources and monitoring responsibility for cloud consumption.

Other questions to ask include: How consistent or different are the various vendor charging mechanisms? Are these mechanisms managed at the Infrastructure, Platform or Software -as-a-service layer? Does vendor infrastructure security impede the ability to manage these charging mechanisms at this granular of a scope?

FAR Constraints

The potential disconnect between treating cloud offers as either products or services leads to a host of complications because not all vendors align their offers to the Government's desired buying approach. As one example, the difficulty of treating the commodity as a service vs. a product creates difficulty for Contracting Officers (CO) in determining payment options and contract types. Vendors are likewise creatively characterizing their offers to help best fit the demands of Contract Officers, whether they truly fit commercial consumption models.

Lack of Industry Standard

Cloud computing has no dedicated international standard and few conventional standards across vendors and the industry. Some of the existing challenges are the differences among cloud models, how the industry is organized, pricing practices, data rights, service definitions, and security.

Common Terms & Conditions

Acquiring these services needs to be made consistent across the government.

Consumers need of Bounds of usage

The government will need to be given some bounds for consuming of IT services such that the government can effectively manage cost and contractual obligations for the purchase of these services. Some standards must be communicated so that overruns in usage will be avoided or controlled prior to potential breach. If given the perception that they have unlimited usage rights to the services, abuse will naturally occur without proper throttling or management.

Data Rights

Government customers are concerned about the ability to maintain their data in a hosted solution they do not control. Agencies have the responsibility of ensuring that government-owned data is and will always be available and can be ported to another system if and when they so choose. It is critical that each cloud-acquiring agency retains not only ownership of the data it stores but also rights to access, modify or migrate it. Such an arrangement guarantees that the government can select and migrate to another CSP if it is not satisfied with the services it receives. THIS POINT SHOULD ALWAYS BE MADE CLEAR IN THE FINAL CONTRACT WITH THE CSP PRIOR TO THE ACQUISITION.

Appropriate Contract Types to protect Government

Time & Materials (T&M) Model - Since cloud services often accrue charges by the minute, hour, etc., charges vary from invoice to invoice over the period of performance. This closely resembles invoices for work done on a labor hour contract. This type of contract fits most closely to the billed utility and metering framework of cloud consumption. It is worth noting that the Federal Acquisition Regulations (FAR) only discusses the T&M model contract with respect to a labor contract. So, agencies must rely on FAR 1.102(d), which essentially says that if the FAR does not expressly forbid it, then it is permissible.

Firm Fixed Price (FFP) Model - Some agencies forbid the use of a T&M model contract for any purpose. For these agencies, an FFP contract may be best. Industry has responded to this issue with annual subscription or other FFP cloud service offerings. These offerings are commonly known as “reserved instances” in the case of IaaS products or “subscriptions” in the case of SaaS products. The FFP cloud contract sword is double-edged. This type of contract has the advantage of being able to change the number or complexion of cloud services at the touch of a button, but does not have the ability to save money when not using the cloud resource or take advantage of the trending falling prices of the cloud market.

If your agency has the ability to leverage both contract types, a blended, optimized solution is possible. Some agencies procure the bulk of their predictable annual compute needs on an FFP “reserved instance” or “subscription” basis and then use a T&M model in order for the remainder to save some money if annual usage turns out to be less than estimated. This blended model works best if you have a good handle on what your agency baseline for cloud computing needs are, not if you are just starting out in the cloud computing space.

Alternatively, some agencies are establishing Blanket Purchase Agreements (BPAs) in lieu of awarding cloud contracts. By doing so, their component sub-agencies or sub-bureaus may issue their own cloud task orders (TOs) against the BPA without having to run their own competitions. When the TO is created, contract type and funding type can be decided on then depending on the nature of the cloud computing requirement.

Total Cost of Ownership

The total cost of ownership is hard to calculate. Typically TCO models do not fit well because they do not take into account the cost offsets of replacing legacy infrastructure and personnel. In other scenarios, they do not take in the potential additional cost of running two parallel systems for a period of time while a new system and legacy system run at the same time.

Legacy Application Migration

Buying, configuring and implementing a new cloud service is difficult enough for government. When acquiring cloud services that are intended to replace a legacy application, an even greater challenge presents itself. There is an enormous amount of considerations and planning required.

Often, government agencies are reluctant to give up their highly customized legacy applications because they can't find the same all-in-one capability in one sole cloud-based application. This makes sense. Odds are there isn't a silver bullet cloud solution that exists that will have ALL the capabilities they had and will meet ALL their needs. However, is the legacy application going to have to be completely reconfigured for cloud so it is cloud optimized and ready? Is this application worth the time and resources to retool or is it time to go shopping for applications with similar capabiliites in the cloud marketplace? If the latter, assess the legacy application's highest value capabilities, perform a thorough survey of the cloud solutions market to find something similar and then customize the cloud-based application as needed. With the retirement or adaptation of one application and the institution of a new one, there is much to be overseen. It's not unsusal for a completely separate cloud professional services contract for a system integrator to also be needed. Overstretched IT departments and agencies without cloud expertise should incorporate contract staff into their acquisition planning.

Finally, when migrating to the cloud, it may be tempting to keep some application data on-prem while moving other application data to the cloud. Be wary of this data fragmentation, as housing it in multiple places may prove difficult to manage and integrate as time progresses. Keep your IT departments happy by not requiring them to manage legacy data siloes. This will liberate their time to deliver mission-enabling innovation for their agency.