The Proposed SAMOSA Act: The Good, The Bad, and The Ugly

News

December 12, 20225 Min.

Share on LinkedIn Share on Twitter Send an email

What is the SAMOSA Act?

The proposed SAMOSA Act (Strengthening Agency Management and Oversight of Software Assets) is a bi-partisan bill (S.4908) led by Senators Gary Peters and Bill Cassidy. It was circulated in September 2021 and has the following components:

Sections 1 & 2 of the Act are the title and definitions.
Section 3 gives agencies one year to complete a comprehensive assessment of software entitlements and software inventory.
Section 4 gives agencies 120 days after submission of the above assessment to complete and submit an optimization plan aimed to consolidate, reduce costs and improve licensing terms. Specifically, the plan must include at least five categories of software that shall be prioritized for conversion to “Enterprise Agreements” (a term that is left undefined in the proposed Act).
Section 5 calls for the OMB Director to submit, within two years of the Act, a strategy for adopting enterprise agreements in government, procurement policies, software entitlement management, use of OpenSource, and others.
Section 6 calls for submission of reporting, within three years of the Act, around government trends related to the Act, agency comparison, and others.

The Good: what’s working with the SAMOSA Act

Experience shows that waste in software and cloud can reach 30% or more, costing American taxpayers billions of dollars annually. Therefore, any legislation which promotes awareness of this waste and which drives greater transparency and cost savings in government is positive. Having a timely, complete, and accurate software and cloud inventory is also critical to achieving effective cybersecurity and other Information Technology objectives.

The Act refers to certain generally accepted IT Asset Management (ITAM) and Software Asset Management (SAM) practices, for example: understanding license entitlements, understanding license consumption, reconciling entitlements to consumption, and identifying risks and opportunities. Such practices, when properly implemented in a repeatable way, result in greater transparency, reduced costs, and mitigated risks.
The Act’s clear requirement for agencies within one year to generate: “the current software inventory of the agency, including software entitlements, contracts and other agreements or arrangements of the agency,” is perhaps the most valuable component as it creates a level of transparency in software utilization, if only for a single point in time, which does not currently exist.
The Act’s focus on leveraging economies of scale and the collective bargaining power of the Federal government should be applauded. The purchasing power of the government must be fully leveraged in all procurement negotiations with software vendors. This often means that certain procurement activities must be centrally managed.
The Act’s references to interoperability, limiting restrictions on licenses purchased, use of OpenSource software whenever possible, and others, are also generally positive and in line with industry best practices.
Importantly, tracking all software and cloud is critical to cybersecurity. This is well established in industry standards and best practices and is known as Cyber Asset Attack Surface Management (CAASM). The report from the Congressional investigation of the 2017 Equifax data breach is just one example demonstrating that organizations cannot secure the IT assets they don’t know they have. Legislation and guidance exist about cybersecurity aspects in software and cloud (from FedRAMP to the recent OMB M-22-18, as just a couple of examples), which agencies would need to address in conjunction with the proposed Act.

The Bad: what’s not working

The proposed Act falls short of calling for an overall governance framework for IT Assets (specifically software and cloud) in line with industry best practices. An example of such a framework is the ISO/IEC 19770-1 standard for IT Asset Management System, which establishes a cycle of continuous improvement (Plan-Do-Check-Act), addresses software/cloud cost optimization in its proper context of full lifecycle management, and considers dependencies with other critical IT objectives such as cybersecurity and Technology Business Management (TBM).

In an effort to drive true long-term cost improvements, the Act should require an overall governance framework for ITAM, designating a minimum percentage of the total agency software and cloud spend (1% is considered a minimal industry best practice) to be invested in implementing the people, processes, and technology elements of an ITAM governance framework. This ITAM investment would generate a typical Return On Investment (ROI) through cost savings achieved in the double-digit orders of magnitude.

Instead, the proposed Act “cherry picks” certain isolated ITAM activities such as an inventory and an optimization analysis, requiring such activities to be done on a one-time basis which, lacking a systematic and repeatable management system, renders such exercises obsolete the moment they are completed. Moreover, the proposed Act fails to specify key requirements even within such one-time activities. Examples include leveraging the FinOps methodology to optimize cloud consumption and rates, the cancellation of maintenance on undeployed software, the removal of deployed-but-not-used software, re-harvesting of license entitlements upon hardware retirement, the adoption of specific industry best practices for minimizing “shelfware as a service” in SaaS, and many other.

The proposed Act also fails to call for an ITAM/SAM “tsar" who can lead the adoption and execution of best practices across the government, driving the tracking, management, optimization, and cost-reduction efforts for all software and cloud assets across all agencies. Such a function may report to the U.S. CIO and be the focal point accountable for all related requirements (the MEGABYTE Act, this proposed Act, and others) within the government. It would be key to ensure that this function has the resources and authority with which to carry out its responsibilities.

The proposed Act’s call to increase the use of OpenSource could be a double-edged sword. While the lack of license cost is attractive, some OpenSource may be more exposed to security vulnerabilities.

The problem with “Enterprise Agreements"

The biggest concern with the proposed Act relates to its misguided fixation on “Enterprise Agreements”, a phrase that can mean anything in the software industry depending on the terms and conditions specified. Some software vendors use this phrase rather freely, merely as a marketing ploy to give their customers the impression that they are getting a “good deal”. The commercial merits of the agreement matter more than what the vendor chooses to name their agreement paper. In many cases, “Enterprise Agreements” not only fail to save customers money over the long run but also ensure that customers are being charged for software they do not need nor will ever use.

Seemingly, the proposed Act’s intention here is to refer to a specific subset of enterprise agreements that are of the “unlimited“ (also known as “all you can eat”) type. Such “unlimited” agreements may look attractive in the short term to immature organizations lacking the ability to know how much software they need or have deployed, desiring therefore to buy an “insurance policy” against an over-deployment of licenses, thus circumventing the need to track assets. Typically, the software vendor makes customers pay dearly for their ignorance. These agreements then make the situation even worse for the customer by further reducing motivation to have strong control over software deployment sprawl during the term of the agreement due to its perceived “unlimited” status. Unfortunately, every party must eventually come to an end, and upon contract renewal time (usually after three years), deployment will have expanded out of control. With the baseline now artificially much higher, the software vendor is handed all the negotiation power to charge large sums of money for the next term, starting a vicious cycle. The customer is now forced to sign a new “unlimited” agreement to account for the excessive baseline and, therefore, can never move off or renegotiate the contract. Put another way, if the starting baseline includes waste, the solution must be to eliminate the waste, not to opt for unlimited waste at a fixed price for a limited term (also known as “kicking the can down the road”).

Unlimited licensing agreements have an even bigger problem, however. The disincentive to track and manage software and cloud assets may result in cybersecurity risks. It is simply impossible to secure software and cloud assets that are not granularly tracked.

Mandating a specific arbitrary number of “Enterprise Agreements” to migrate to also makes little sense. For some agencies, that number may be zero or, in fact, negative (where achieving cost savings may mean the agency must move away from certain costly and wasteful agreements it already has in place).

Finally, the “Enterprise Agreements” requirement may give undue advantage to the larger software vendors, as has already been pointed out in the October 11 article by FedScoop’s Nihal Krishan. Smaller vendors (including SaaS vendors) may have better products at better rates, but they have generally struggled to sell to the Federal government even before the new barriers raised in the proposed Act.

The American taxpayer does not benefit from lower competition and reduced ability to switch technology. Software procurement decisions must be based on factors such as (1) the product’s fit for purpose, (2) meeting critical requirements such as cybersecurity, and of course, (3) overall cost. It is unclear how the American people benefit if an arbitrary and undefined new “Enterprise Agreement” requirement overrides these basic factors going forward and why any weight is given to how the software vendor chooses to name their agreement paper.

The Ugly: a hard truth about a new law

Prior legislation (MEGABYTE Act, FITARA, and their related guidance such as OMB M-16-12 and others) already cover many of the requirements in this proposed Act. Had such legislation been adopted and enforced in full, agencies would have had much more effective IT Asset Management today, saving American taxpayers billions of dollars. Unfortunately, over the years, the adoption of such existing legislation, at least as it relates to IT Asset Management practices, has largely been subpar and superficial. This is due to a lack of organizational and individual accountability, a lack of budget and resources, and competing priorities. Simply having a new law repeating the same requirements will not solve the underlying problem of accountability and resources.

To sum it up

The SAMOSA Act contains many valuable provisions, alongside a few misguided ones and others that are still missing.

The Act should more precisely define ”Enterprise Agreements”, and require agencies to evaluate such agreements (whenever or not already in use with respect to the largest software vendors) for their actual cost reduction potential and flexibility of operation over the long term.
The Act should require a comprehensive governance framework for IT Assets such as ISO/IEC 19770-1 and the FinOps methodology for cloud financial management, to ensure government agencies evolve their maturity level in managing software and cloud costs to the next level, enabling the achievement of truly meaningful and repeatable savings and risk mitigation.
The Act should reinforce the need to comply with existing legislation, such as the MEGABYTE Act (2016). Also, to ensure agency execution around ITAM and cost reduction for software and cloud, the Act should require accountability and provide for the resources required. To drive meaningful long-term results, a minimum budget of 1% of the software and cloud spend should be allocated to the continuous tracking and management of software and cloud assets and to cost reduction efforts.
Toward that end, the proposed Act should call for the appointment of an ITAM/SAM “tsar" responsible for all ITAM/SAM activities across the government. This function should be accountable for the execution of all relevant legislation and for optimizing the government’s use of software and cloud to drive cost savings.

Senators Peters and Cassidy should be applauded for their intention to tackle the waste in our government’s software and cloud supply chain. With a few modifications and the adoption of IT Asset Management (ITAM) industry best practices, the SAMOSA Act could realize its full potential and save the American people billions of dollars while strengthening our government’s cybersecurity posture at the same time.