GithubHelp home page GithubHelp logo

whitehouse / software-policy Goto Github PK

View Code? Open in Web Editor NEW
4.0 17.0 14.0 769 KB

Category Management Policy 16-1: Improving the Acquisition and Management of Common Information Technology: Software Licensing

Home Page: https://software.cio.gov

License: Other

Ruby 3.94% HTML 7.21% CSS 48.36% JavaScript 40.48%

software-policy's Introduction

Category Management Policy: Improving the Acquisition and Management of Common Information Technology: Software Licensing

The Office of Management and Budget is accepting public comment on draft guidance to improve the acquisition and management of enterprise software. This policy is the second in a series of category management policies to drive greater performance, efficiencies, and savings in commonly-purchased information technology goods and services. The first memo in the series, M-16-02, addressed the acquisition of laptops and desktops.

The proposed guidance is now open for public comment on this page. The public feedback period will be 30 days, starting on December 21, 2015, and closing on January 20, 2016. Following the public feedback period, OMB will analyze all submitted feedback and revise the policy as necessary.

Public domain

This project is in the worldwide public domain. As stated in CONTRIBUTING:

This project is in the public domain within the United States, and copyright and related rights in the work worldwide are waived through the CC0 1.0 Universal public domain dedication.

All contributions to this project will be released under the CC0 dedication. By submitting a pull request, you are agreeing to comply with this waiver of copyright interest.

Privacy

All comments, messages, pull requests, and other submissions received through official White House pages including this GitHub page may be subject to archiving requirements. See the https://www.whitehouse.gov/privacy for more information.

Developing on the site locally

This site uses Jekyll, Sass, Bourbon, Neat, and requires Ruby 2.x.

Install dependencies with Bundler:

bundle install

And run the site with Jekyll:

bundle exec jekyll serve --watch

If all goes well, visit the site at http://localhost:4000.

software-policy's People

Stargazers

 avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

software-policy's Issues

Email comment: Citizens Against Government Waste (CAGW) comments on OMB software policy

January 20, 2016

The Honorable Shawn Donovan
Director
Office of Management and Budget
Office of the Chief Information Officer
725 17th Street, NW
Washington, DC 20503

Re: Memorandum for the Heads of Departments and Agencies Regarding Category Management Policy 16-1: Improving the Acquisition and Management of Common Information Technology: Software Licensing

Dear Director Donovan,

On behalf of the more than one million members and supporters of Citizens Against Government Waste (CAGW), I am providing these comments regarding the proposed Memorandum for the Heads of Departments and Agencies regarding Category Management Policy 16-1: Improving the Acquisition and Management of Common Information Technology: Software Licensing.
CAGW strongly supports enhancing the efficiency of the federal government, and among other issues has been involved in efforts to improve software asset management and licensing. We are pleased that the Office of Management and Budget (OMB) has undertaken this task as part of the guidance under the Federal Information Technology Acquisition Reform Act of 2014 (FITARA), which CAGW supported.

Section 2 of the memorandum includes a requirement for the completion and reporting of an annual inventory of software license and subscription spending and enterprise licenses, including license count and usage. CAGW recommends that the reporting requirements include 1) the number of existing software licenses at the agency; 2) the number of software licenses used; 3) the amount of funding expended each year for software license compliance costs when an agency is not in compliance with the terms of the software licensing agreement; and, 4) a plan of action for bringing the number of software licenses into balance with the agency’s needs. This will provide a more accurate picture of the federal software landscape and improve oversight regarding software duplication.

Again, I appreciate the opportunity to provide comments for the proposed memorandum on behalf of CAGW. If you have any questions regarding this matter, please feel free to contact me or CAGW Director of Technology & Telecommunications Policy Deborah Collier at (202) 467-5300.

Sincerely,

Thomas A. Schatz
President
Citizens Against Government Waste

Build vs. Buy

Can you give some guidance about how the build vs. buy decision is made in relation to government software procurement?

software beyond simply acquisition into deployment and management

The language provided in the memo address a portion of the issues with enterprise software acquisition and deployment today but not all aspects. I am attaching edits and additions to the language around ensuring user adoption, management and metrics on deployment of actual applications for consideration. Please accept these suggested modifications and additions as our input on this vital topic.
CategoryManagementSoftware with suggested edits from Cisco Systems Inc 01-19-16.docx

Email comment: Belarc, Inc. comments on OMB software policy

It’s great to see your initiative on trying to manage the federal government’s software spend. There is little need to reiterate the ever increasing costs and huge potential for annual savings in this area. We would like to make the following comments:

• The memo mentions using DHS’ CDM tools to report on software inventory and usage. We believe that some Agencies have far more effective tools than the current CDM offerings and that the current CDM offering lacks some important capabilities for software license management, as follows:

o Enterprise wide capability. The software inventory and usage data must be readily available on a near continuous basis from all IT assets covering the enterprise. Many Agencies have many tens of thousands of IT assets across many geographic locations. The system should operate automatically and not rely on local servers and require any local admin time and effort to manage.

o Automatic discovery of complex server software, dependencies and related hardware details. Server software likely constitutes the majority of the federal government’s software spend. Vendors such as Microsoft, Oracle, IBM, SAP license their server software based on complex metrics. In order to determine the licensing position of these products it is necessary not only to discover the installation of the software, but also the dependencies between the virtual machines where the software is installed and the physical host machines; the hardware details such as CPUs, cores, whether hyper-threading is enabled; is the server part of a cluster; and even if the Options have been used or not (for Oracle). The current CDM toolset does not accomplish this.

o Discovery of expensive desktop software. Many government services are dependent on CAD and GIS (geographical information system) software, and these are often very expensive products. In our experience AutoCAD and ESRI are in particular use in the federal government. Your current CDM offerings do not adequately discover these products to enable licensing.

o Discovery and usage of Cloud software. This will likely become an ever increasing part of the government’s software spend. Licensing Cloud products may make counting devices easier, i.e. one user can access up to five devices for example, but tracking whether the user has actually used any of those devices or is no longer with the Agency will be important. The current CDM offering does not have this capability.

• There was little mention of the need to merge the discovered data with the Agency’s purchase records and licensing rules for the software products. This is especially important for complex server software where the licensing metrics are complex and some form of automation should be used to determine a true licensing position. In fact, this should ideally be done on a continual basis, where the discovery and usage data is automatically used to link to the latest purchase records and licensing metrics.

• There is likely a need to bring in outside expertise on negotiation with the major vendors, in particular Microsoft, Oracle, IBM and SAP. These people bring in years of experience, often with the software vendors themselves, to help the purchaser manage the licensing process more effectively.

Keeping a database of existing software

Much of the software purchased by the government is done separately by separate departments and sometimes separately within a single department. Purchasers are rarely aware that a software product has already be bought by someone else. The ESCT needs to create a database that contains lists all the software purchased along with dates, version and related technical specifications. Before anyone purchases new software, the protocol should require them to check this database to see if they can use the existing licenses. Additionally, it may be advantageous to purchase additional license based on existing purchases rather than initiate independent procurement.

Accountability for performance

My experience with enterprise-wide software license management has been constant and consistent failure. Contracts are allowed to lapse. Technical support is not adequately supported (particularly accounts/POC lines for technical personnel that actually execute the technical interface). Important elements of software lines are not included (or better, 'dropped' with no notice) and then are impossible to re-license. Changes to line item (or bundle) by vendors are not properly tracked, no notification to license holders is given, Allocation of costs is unreliable and unpredictable ("How much do I need to budget to renew my program's licenses for ABC software?" "Pricing isn't final yet, and we haven't finalized next year's buy. We'll send you a bill" "But that doesn't help my program budget development."). Oh - and my favorite - periodic recompetition of software fundamental to technical solutions ("a database is a database, why do you care if it's MS SQL, Oracle, or MySQL?", "Because you're about to break mission critical systems, and drive them onto expensive, high-risk rearchitecting. They are NOT form-fit compatible").

I have seen these issues re-appear in every organization that I have seen pursue centralized software licensing management - private sector, public sector - DoD, DHS. The incentive structure is entirely misaligned for the software management office - they are (uniformly) understaffed, overwhelmed, and not knowledgeable on the products they are managing. Software management offices are evaluated on compliance with reporting, and on meeting fiscal targets. At the extreme, every software management office I have seen would get better evaluations if they reduced all software expenditure to zero, and successfully filed weekly reports showing no cost growth, and 100% licensing compliance - i.e. if they turned off all the computers. Because the goals of the office are not mission-focused, but are administratively derived.

If you really want this to work, require that the position of software manager (and deputy) be filled on a rotating basis (temp not to exceed 18 mos) from an interior hire that has no less than 3 yrs program management experience (along with the requisite DAWIA certifications). Provide them with adequate staff and funding, and measure them on the ability of the organization to deliver to mission. Until that happens, software management offices will continue to be an albatross and a bureaucratic mire.

Oh - did I mention that the office won't be cheap? If you're looking for cost savings from enterprise licensure, please keep in the forefront of all planning that all cost savings (and much more) will be consumed by management and overhead.

Detailed software provenance disclosure

Here is a suggestion for this policy:

Given a piece of software under consideration, the provenance (aka. origin and license) of every third-party components included in that software should be well known and eventually disclosed by the provider.

The benefits are obvious: knowing the license is essential to be allowed to use the code; and knowing the detailed origin is important to evaluate the originality, quality and eventual bugs or security issues related to the software under consideration.

For that there are a few good free and open source tools that can help uncover provenance data:

BSA Comments

BSA | The Software Alliance (BSA) welcomes the opportunity to provide comments on the draft memorandum on Category Management Policy 16-1: Improving the Acquisition and Management of Common Information Technology: Software Licensing (“Draft Memorandum”).

As providers of software products and services that help advance the Federal Government’s mission, BSA members support the Office of Management and Budget (OMB)’s goals to improve the acquisition and management of software products and services through the adoption of best-in-class practices across the Federal Government. BSA, therefore, offers these comments to assist with your efforts.

Technology Neutrality

We applaud the Draft Memorandum reference to development of processes and guidelines to procure software products and services that “include alternatives analyses in a technology neutral manner that is merit-based, and considers such factors as performance, total cost of ownership, security, interoperability, ability to share or re-use, and availability of quality support.”

Indeed, it is very important that procurement practices adopted by Federal Agencies maintain a technology neutral approach. Procurement practices that mandate the use of specific technologies tend to freeze innovation, as well as force users to procure products that might not suit their needs and that are less secure and less cost effective.

We recommend that the Draft Memorandum further highlight the importance of technology neutrality, making reference to this principle in the body of the text rather than in a footnote. In addition, we recommend a specific reference be made to the memorandum sent by the U.S. Chief Information Office, the Administrator for Federal Procurement Policy, and the U.S. Intellectual Property Coordinator to all Chief Information Officers and Senior Procurement Executives on January 7, 2011 reminding that the Federal Government’s policy of selecting and acquiring information technology that best fits the needs of the Federal Government should be technology and vendor neutral.

Finally, it is also important that, while promoting procurement practices that are technology neutral, OMB considers the importance of appropriately relying on well-established standards, including open standards that are global, voluntary, and developed through industry-led multi-stakeholder processes.

Terms and Conditions Transparency

The Draft Memorandum reminds Agencies that they shall not agree to terms and conditions that prohibit the sharing of all prices, terms, and conditions with other Government entities (including posting pricing to the Acquisition Gateway). Although transparency is important, it is critical that vendors maintain their ability to offer pricing models tailored to best meet the specific Agency’s needs, including software customization, volume negotiated, and other elements.

BSA respectfully requests that the Draft Memorandum address this issue by clarifying that pricing should not be considered in isolation from other factors and that Agencies and vendors should have the latitude to conclude terms that best meet the Agency’s specific needs in the context of a procurement decision.

Government-wide Enterprise Software Agreements

According to the Draft Memorandum, the Category Management Leadership Council’s Enterprise Software Category Team (ESCT) will develop new government-wide enterprise software agreements for mandatory Federal Agency use. In addition, Agencies will need to justify and obtain high-level agency approval for the pursuit of new agreements that overlap with the ESCT mandated agreements.

The way customers, including Government Agencies, acquire and use software is changing rapidly. BSA members increasingly provide a wide array of data services, analytics, security solutions, connectivity, and much more. This is in addition to a full array of software solutions that are increasingly offered online as subscription based services, allowing customers to tailor their software needs in real time.

The Draft Memorandum directs Federal Agencies to develop repeatable processes to aggregate software requirements and associated funding, as appropriate, for commercial enterprise software acquisitions. If this mandate were to create a single approach to be followed by all Agencies in every case, this could prevent Agencies from procuring the solutions that are most suitable and cost-effective to address their specific needs. A “one-size fits all” solution may not always be the best approach. BSA requests OMB clarify this requirement to ensure there is enough flexibility to accommodate specific Agency needs.

Federal Agencies must be able to procure cutting edge technology and although government-wide agreements will be developed, requirements that are too strict may prevent Agencies from benefiting from innovative technologies, services, and business models. It is very important that these agreements remain flexible to allow for efficient procurement of ever-evolving software offerings.

Finally, it is important to clarify what will be considered “best-in-class” software licensing agreements for the purpose of the Draft Memorandum, as well as which situations might fall outside the scope of the mandatory use of government-wide enterprise software agreements.

Commercial Terms

In order for the Federal Government to fully leverage and procure rapidly developing innovative commercial information technology (IT), including software, computer hardware, and cloud services, it is imperative that these products and services are procured based on commercial terms. Indeed, FAR 12.212 directs the Federal Government to acquire commercial software through commercial license terms. Yet, despite this mandate, Government Agencies routinely attempt to impose numerous FAR and agency supplemental terms that are inconsistent with commercial standard terms and practices. This deviation completely undermines the goals of leveraging commercial terms and best practices and streamlining procurement.

As OMB itself has recognized in a memorandum addressed to Chief Acquisition Officers and Senior Procurement Executives dated December 4, 2014, “greater attention must be paid to regulations related to procurements of commercial products and services, as the Government is typically not a market driver in these cases and the burden of Government-unique practices and reporting requirements can be particularly problematic, especially for small businesses”.

In this regard, BSA respectfully recommends the use of government-wide acquisition contracts based on commercial terms and the elimination of government contracts that impose burdensome government-unique requirements.

Further, it is very important that the Draft Memorandum make clear that government-wide enterprise software agreements should not mandate commercial software products and services be tailored for Federal Government use. Many commercial terms and conditions are inextricable parts of commercial offerings and should remain undisturbed.

Terms and conditions that effectively customize commercial items, including license metrics and deployment restrictions, should not be added to government-wide enterprise software agreements. Such terms would increase software costs by forcing contractors to charge higher prices for customized products and services and reducing competition as commercial software vendors could exit the marketplace, thereby preventing Agencies from fully benefiting from innovative commercial software. These terms would also run counter to Federal Government guidelines directing that commercial off-the-shelf (COTS) software should be leveraged as much as possible.

Procurement of customized software products and services should only be considered, if at all, on exceptional case-by-case basis, and certainly should not be instituted by government-wide enterprise agreements.

Finally, BSA urges that ESCT establish an ongoing dialogue with industry to inform the development of plans for moving to government-wide licensing agreement models, particularly for cloud-based solutions, before such models are finalized and implemented.

Use of Licensed and Supported Software by Federal Agencies and Contractors

Ensuring that Agencies are only using properly licensed software has long been a US government priority. Executive Order (EO) 13103 was issued in 1998 to further this objective. In May 2014, a report issued by the Government Accountability Office (GAO) confirmed that US Federal Agencies do not have adequate polices for managing software usage. GAO recommended that OMB issue a Directive to help Agencies improve their software license management practices. Proper software asset management would reduce the use of unlicensed or under licensed software, which would likely reduce contractual disputes and result in considerable cost savings. In addition, the use of unlicensed and/or unsupported software exposes Agencies engaged in such activity to higher risks of downtime, malware infections and other security vulnerabilities.

This Draft Memorandum is a step in the right direction and OMB should ensure that the recommendation to maintain inventories of software is fully implemented (Draft Memorandum page 3, item 2) and that such inventories include all software products and services acquired and deployed. When maintaining such inventories and managing their software asset management, Federal Agencies should refer to international best practices such as the ones established by voluntary, market-led standards. This approach to software asset management is likely to generate better results and increase efficiencies (please refer to next section for further details).

It is also important to point out that the use of unlicensed, under licensed, and/or unsupported software by government contractors in the performance of activities related to federal contracts is also a concern and, as mentioned before, could put government systems at risk of downtime, malware, and cybersecurity incidents. OMB’s engagement in helping address this issue would be extremely welcome. Federal Agencies should require their contractors to only use properly licensed software according to the license terms and conditions, and backed by expert technical support from a reputable vendor.

With respect to open source software, OMB should require Federal Agencies to (i) identify all open source software deployments as part of the newly established software inventory process and (ii) evaluate the costs and benefits of purchasing support and maintenance from a vendor expert in the operation of the applicable open source software.

Finally, BSA recommends that not only personnel involved in software license management but all Federal employees, including CIOs, Contracting Officers, and agency attorneys, be educated on the risks and contractual liabilities associated with the use of unlicensed software. We, therefore, suggest that specific reference be made to this issue when relevant training is mentioned on page 3, third paragraph, of the Draft Memorandum.

Software Asset Management

BSA applauds OMB’s recommendation that agencies should maintain inventories of acquired and deployed software and strongly suggests that those inventories be expansive in scope and based on the use of international standards such as ISO 19770-1:2012 for software asset management. We also recommend that such inventories fully consider license requirements for virtualization technologies.

For full visibility and transparency, BSA believes that the required software inventory and reports to OMB must expressly cover Software-as-a-Service (SaaS) and open source software deployments as well as all evaluation and test use of commercial software even if there is no direct cost involved in such use. Use of “free-of-charge” software, be it a free SaaS product, open source software, or an evaluation copy of proprietary software, can give rise to material financial, operational, and security risks and should not be overlooked in the new inventory process. By requiring an expansive software inventory, OMB can ensure that the applicable Federal Agency CIOs and CAOs have comprehensive knowledge of current software usage as well as insight into future requirements.

Transparent and verifiable software asset management (SAM) practices identify situations where entities are using unlicensed software as well as situation where the licenses they have far exceed the number of users. Under licensing creates legal liability, while over licensing creates inefficiencies. BSA has developed the Verafirm Certification program aligned with the global ISO 19770-1:2012 standard to help entities manage their software, remain compliant and secure, and increase efficiencies.

The lack of proper SAM practices can contribute to the use of software that is unlicensed, under licensed, or unsupported because IT managers may not have full visibility of the software deployed within their organizations. Federal Agencies should lead by example and adopt SAM practices based on international standards for their own procurement and software asset management, which can send a powerful example to enterprises in the United States and abroad while increasing efficiencies.

Conclusion

In light of our shared interests in the effective procurement and management of software products and services, BSA and its members appreciate the opportunity to submit these comments and we look forward to answering any questions and to continuing to work with you.

Sincerely,

Email comment: Symantec comments on OMB software policy

To whom it may concern:

Thank you for the opportunity to submit comments to the Draft Policy related to:
“Category Management Policy 16-1: Improving the Acquisition and Management of Common Information Technology: Software Licensing.”

We would be happy to schedule time at your convenience to discuss our following comments in more detail:

  1. Recommendation: Broaden the scope of the policy to include comprehensive software management. The capabilities of the CDM Tools that cover Software Management go well beyond requirements outlined in this draft policy. The US CIO should implement more of the CDM Tool capabilities to gather additional information to be used in making decisions on software usage. For example, a traditional Software Management tool can report on the patch status of installed software. It would be useful for agencies to know if installed software requires a patch, how long it has gone unpatched, how often a patch is required, etc. It may be worth considering another application if patching is a concern with the current software.

Benefits to Federal Government: Further consolidation of vendors (and software in use) by leveraging the full extent of data provided by software management tools. Risk management and reduction through patch management.

  1. Recommendation: Possible exemption for Cybersecurity tools.

Benefit to Federal Government: Improved public perception. Acquisition is already perceived as the roadblock to obtaining cutting edge cyber tools needed to protect Fed IT Systems. This policy could exacerbate the problem.

  1. Recommendation: Reflect unique circumstances in the policy.

Benefit to Federal Government: In many cases, discounts are negotiated to fit certain unique circumstances (quantity, term of contract, combined with a larger purchase, to help align with customer budget, etc.) As such, a discount to Agency X may not apply to Agency Y.

  1. Recommendation: The SW Inventory Report should note if the product is installed, or simply sitting on a shelf (known as “shelf-ware”.) Without such granular reporting, an agency report can reflect having a certain capability, but there is no way to determine if the capability is being used.

Benefit to Federal Government: Lowered risk profile and cost of ownership, and compliance with various Federal mandates. If it is determined that an agency owns but is not using certain tools (especially those used for patching and security) the agency could lower its risk profile by deploying those tools. Similarly, once tools are deployed the agency would be in compliance with applicable mandates. Ensuring software is actually deployed benefits the government (the capability of the software is realized) and the taxpayer (money spent is actually providing a service.)

  1. Recommendation: SW Inventory Report should note if the product is ‘end of life’ or out of maintenance.

Benefit to Federal Government: Lowered risk and improved compliance. If a product is at its end of life, or is no longer covered by a maintenance contract, chances are great that Vulnerabilities are no longer being patch. This creates a Threat Vector which can be easily exploited by a would be attacker.

Please feel free to contact the undersign should you wish to discuss our comments further.

Ken Durbin
Unified Security Practice Manager
Public Sector
www.symantec.com

Email comment: Flexera comments on OMB software policy

Ladies and Gentlemen:

I am the President and CEO of Flexera Software, the leading global technology, consultancy, service provider and subject matter expert in the area of Software Asset Management (SAM) and Software License Optimization. We serve myriad US Federal Agencies as well the largest companies in the world, helping them significantly reduce software spend and waste, and improve software procurement practices to ensure they are buying only what they need and using what they have. In sum, we help customers gain the expertise they need to negotiate better deals with software vendors by helping them manage their software agreements more effectively.

Perhaps more so than any other organization, we are intimately familiar with the industry best practices around SAM/Software License Optimization. In some cases we have been the innovators of those best practices; in other cases, we have provided automation to make implementation easier.

With all of this in mind, we congratulate you in taking the important step of putting forward guidance on better software management in the federal government. Based on what we have learned through over 20 years of experience, we believe that effective software license management can save the federal government up to 25 percent of its $9 billion annual software spend, or $2.25 billion.

As such we are offering the following commentary and recommendations in connection with the OMB’s Category management Policy 16-1: Improving the Acquisition and Management of Common Information Technology: Software Licensing. Once you have had the chance to review these comments, we would be happy to meet with you to provide further insights into our commentary or respond to questions you might have as you move to finalize this policy document.

Very Truly Yours,
Jim Ryan
President and CEO
Flexera Software

Flexera Software Commentary: OMB Category Management Policy 16-2 (FITARA)

Relevant Policy Section: Agency Strategies – Centralizing and Improving Software Management

In item 1), “Appoint a software manager…” we believe that you have captured several important aspects of effective software management. However, we would recommend that in bullet 1, which starts “Develop and implement a plan…”, you add a second sentence which includes the essential data elements necessary for any plan. For example, you might consider adding “This plan should be data driven and rely on A, B, C and D.

Also in item 1), under bullet 3, “Develop a vendor management strategy…” our experience in this area tells us that improving relationships with suppliers is generally one outcome of an effective software management program in which the customer has reliable data on software licenses purchased, deployed and used. With these three bits of information, a customer’s vendor management becomes less of a contentious exercise and more of a collaborative effort that focuses on bringing new capabilities to bear as opposed to annual data-devoid arguments over software entitlements. Therefore, we recommend that you alter this bullet to read “Develop a data-driven vendor management strategy…”

In item 2), “Maintain comprehensive annual inventories,” our experience in this area is clear. Effective software license management is not possible as a periodic (i.e. once annually) process. A single instance of license non-compliance at any point in time throughout the year can trigger expensive true-up penalties charged by vendors during an audit. Accordingly, software inventories, license count management and usage must be tracked on a continual basis to ensure continual compliance, minimizing waste and software license audit risk exposure. As a result of requiring this more rigorous process, OMB will achieve more rapid and significant cost savings, which will be reflected in the annual reporting called for in these guidelines. Therefore, we would recommend that you alter item 2) to replace the word “annual” with the word “continual” so that it reads “Maintain comprehensive continual inventories of software license and subscription spending and enterprise licenses, including license count and usage.”

Also in item 2), the two bullet points call out dates – September 30, 2016 for the commencement for using the recommended tools to report on software inventory and usage, and August 31, 2016, for the agencies to report to OMB on their software license inventories. In our experience, implementing the necessary Software Asset Management people, processes and technology to enable the reports called for in this section requires considerable time for tool selection, up-front planning and implementation. Accordingly we view these deadline dates to be extremely unrealistic, making noncompliance virtually assured.

Therefore, our recommendation is to provide an additional year for compliance, and thus modify the text so that it reads:

• “No later than September 30, 2017, agencies shall, to the extent practicable, leverage…”, and
• Beginning August 31, 2017”, and each year thereafter, all departments and agencies shall provide to OMB an annual report of their software license inventory

Also in item 2), in reviewing the first bullet, which reads “… agencies shall, to the extent practicable…” we believe it is important to call out the use of technology tools to help enable the implementation of best practices in software management. Software Asset Management/Software License Optimization is the generic name for a host of capabilities recognized as the industry-standard for solving the problems contemplated by FITARA and these policy guidelines. Having done the work for years, we are confident that CDM or CMaaS tools are not designed for Software Asset Management and would be insufficient, in and of themselves, to ensure compliance with FITARA and OMB’s policy guidelines. Further, CDM/CMaaS tools may not necessarily provide sufficiently comprehensive functionality to deliver effective software license management as called for in these policy guidelines, which is a highly specialized field. Accordingly it is critical that any technology capability called out provide sufficient guidance for effective compliance. Including industry-standard technology descriptors (i.e. Software Asset Management/Software License Optimization) is therefore important to help ensure compliance with these policies.

Therefore, our recommendation is to modify bullet 1 in item 2) so that it reads “No later than September 20, 2016, agencies shall, to the extent practicable, leverage technology that enables implementation of industry best practices and standards for software license management, such as Software Asset Management (SAM)/Software License Optimization (SLO) tools, Continuous Diagnostics and Mitigation (CDM) tools and Continuous Monitoring as a Service (CMaaS) to report on software inventory and usage.”

Additionally, as you know, FITARA, and OMB’s guidelines effectively call for the government to implement industry-accepted SAM/Software License Optimization best practices. The leading technology analyst firm, Gartner, outlines the six essential SAM practices, most recently in a July 29, 2015 report, “Use Gartner’s Tool Decision Framework for SAM to Create your Roadmap.” A copy of that report is attached for your convenience. Those industry-accepted best practices are:

 Platform Discovery: Discovery is the act of interrogating networks to identify network-attached physical and virtualized platforms upon which software executes. This is a foundational activity to effective SAM
 Inventory: The purpose of inventory is to extract and identify all software executing in the environment - also foundational to SAM.
 Reconciliation: Reconciliation harmonizes contract, purchase and product use rights information with normalized inventory data to establish an effective license position (ELP) — the balance of licenses purchased to licenses consumed. ELP forms the basis of compliance, risk-reduction, audit defense, contract (re)negotiations, license "true ups" and optimizing software spend.
 License Optimization: Optimizing license position means reducing the number, type and expense of licenses needed and in use, as appropriate. A typical approach to optimization models reconciled data to examine software, its entitlements, environment and actual usage to recommend the appropriate license type. Optimization is also essential for ensuring the government understand what software it has, what it’s using, and what it needs when negotiating new contracts with vendors.
 Sharing Information: SAM tools both consume and produce data and information, which they must share to be useful. Gathering technical, financial and contractual data in a central system of record for IT assets enables the Federal CIO to manage vendors effectively, and software assets from requisition through retirement.

Given your emphasis on best practices, we believe these six elements, as described by Gartner, are appropriate for inclusion in any federal guidance policy. Therefore, we would recommend adding another sentence along the lines of: “At a minimum, this technology must facilitate automated (1) Comprehensive software/hardware platform discovery; (2) Platform and Software Inventory; (3) Software Inventory Normalization (4) Contract, Purchase and Product Use Rights Reconciliation; (5) License Optimization (6) SAM Data Sharing Capabilities.” That bullet concluding sentence would remain as is - “The agency's centralization plan shall explain how this capability will be implemented.”

Under item 3), which starts “Aggregate Agency Requirements and Funding” you are to be commended for linking software management to agency funding requirements. At the same time, while in this item you note that “Agencies shall develop repeatable processes,” you miss the opportunity to encourage automation of processes – which is a private sector best practice, and which spurs moves from labor-intensive Excel-based software inventory management to more efficient and effective automated software tools.

Therefore, we would recommend that item 3), you alter the first sentence after “Aggregate Agency Requirements” to read “Agencies shall develop automated, repeatable processes to aggregate software requirements…”

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.