Skip Navigation
U.S. flag

An official website of the United States government

Dot gov

The .gov means it’s official.
Federal government websites often end in .gov or .mil. Before sharing sensitive information, make sure you’re on a federal government site.

Https

The site is secure.
The https:// ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.

Internet Explorer is no longer a supported browser.

This website may not display properly with Internet Explorer. For the best experience, please use a more recent browser such as the latest versions of Google Chrome, Microsoft Edge, and/or Mozilla Firefox. Thank you.

Your Environment. Your Health.

Non-Commodity Software

Rationale

Non-commodity software includes custom-built applications and substantially reconfigured commercial software. Examples include BRT (budget), CareerTrac, committees on promotion system, statistical and analytical software, grant application development and support, health and safety management, inventory management system, and many others. The current non-commodity software inventory reflects decades of adoption of I&IT software technology across the institute as the scientific mission has evolved and grown. However, divisions and offices have developed custom software solutions for their respective needs with varying line-of-sight connections to an integrated institute-wide strategy. As a result, NIEHS has opportunities to streamline, gain efficiencies, and make effective use of today’s rapidly evolving technology landscape. The institute must develop the ability to plan for its future application environment. To address this, NIEHS must implement a lifecycle strategy with guidelines and best practices that will drive an optimized non-commodity software environment.

Goals

Support Diverse Mission Functions and Domains

The institute provides non-commodity software to support broad functional capabilities across a diverse set of scientific, grant-making, and enterprise-wide mission areas. The types of supported functional capabilities include streamlining and automating business processes to maximize efficiency and transparency; monitoring and predicting costs and expenditures; tracking non-monetary resources, people, and materials; monitoring and informing staff about needed actions; managing and monitoring distribution of workload across staff to balance work and operate efficiently; controlling and sharing information with internal and external communities; characterizing and communicating outputs and impacts; scientific analysis and visualization, and many others. These capabilities are essential across all domains of the NIEHS mission.

Ensure Software Lifecycle Planning

NIEHS will conduct strategic planning for non-commodity software needs, addressing key challenges and gaps. The institute will implement lifecycle planning for all non-commodity software systems, including plans to stay current with related version releases. Existing and future non-commodity software will be secure, user friendly, innovative, state of the art, nimble, and meet customer needs. Staff will develop methods and approaches that enable the institute to adapt to changing conditions and anticipate changes (e.g., those related to security, new technologies, etc.). The non-commodity software environment will comply with federal, HHS, NIH, and NIEHS policies.

Implement Software Best Practices

NIEHS will use robust approaches to gather and prioritize business requirements, develop budget estimates, secure contracts, develop solutions focused on user experience, ensure compatibility with existing architecture, test solution delivery, fix bugs and defects, and deliver completed software. Staff will develop the skills and capacity to manage non-commodity software development activities according to project management standards and best practices.

The institute will identify opportunities to streamline and consolidate non-commodity software development based on cost-benefits analysis and foster collaborations for crosscutting needs. Non-commodity systems will be interoperable where it makes sense. Staff will develop methods and practices to coordinate non-commodity software development with hardware, middleware, and storage I&IT groups. Staff will implement standard metrics for measuring and assessing non-commodity software use, both internally and externally.

Strategic Capability Priorities

Non-Commodity Software Inventory

NCSW-01

two puzzle pieces that look like computer chips being put togetherNIEHS will maintain a well-characterized inventory of non-commodity software systems and their interdependencies. The inventory will provide the data needed to develop strategy-enabling analysis of needs, facilitating prediction of future needs, identifying areas of overlap, enabling better acquisition planning, and facilitating communication around change control. System success will be determined when it is editable by a key set of system owners and representatives, is regularly updated (once per year with business owners), has a specific champion or owner named for each tool, a comprehensive list of custom applications and the programs needed to support them, and once the required set of fields is established and 90 percent are complete.

NCSW-02

NIEHS will develop application profiles that map to the business owner, as well as the functional capabilities and mission domains. Adding functional capabilities and mission domain fields to the inventory will allow the institute to create a comprehensive management structure for the entire inventory, and know that nothing has been lost and everything can be included in an appropriate roadmap for budgeting. Success will be determined when each application is assigned to a domain area for tracking and budgeting. Budgets and contracts will include all applications assigned to a domain (i.e., no orphans).

NCSW-03

NIEHS will review the non-commodity software inventory regularly to assess compliance with approved architecture and update or retire applications that do not conform. Review will ensure that systems are secure and conform to the architecture. In turn, this will assure that the institute maximizes the capacity of the infrastructure while monitoring costs. Success will be understood by domain area leader satisfaction and when outdated and nonconforming applications are retired.

NCSW-04

NIEHS will decide what, if any, non-commodity software inventory information is made available on the Junction. Non-commodity software inventory information review will assure that content is accurate and that access to protected information is controlled. Success will be understood with inventory and content updates and removal of inappropriate information from the Junction.

Application Development Guidelines

NCSW-05

NIEHS will establish and maintain application guidelines that provide appropriate constraints for what programming languages, platforms, application servers, and versions are used for non-commodity software development. Guidelines will prevent any disallowed uses, while maintaining as much flexibility as possible. Lack of guidance creates vulnerabilities, inconsistencies, and unevenly administered policies. Guidance will help avoid unexpected costs and downtimes (e.g., Cold Fusion 7 upgrades). Success will be understood with a central repository that is easily accessible, distributed to contractors, and updated as needed. NIEHS will develop use cases of significant contracts or activities that use the guidelines. Guidelines are nonexistent at the institute level, although they are frequently set at the contract or project level.

NCSW-06

NIEHS will provide training and education for researchers and developers on best practices for developing open-source software. Training will enhance consistency and security. Success will be understood by training on open-source software each year, positive training participant surveys, and elimination of inappropriate software cases.

Non-Commodity Software Staffing and Organization

NCSW-07

NIEHS will establish an ongoing group to support non-commodity software goals and priorities. The institute will develop the ability to plan for its future application environment. To address this, a group needs to be established (or an existing group assigned) to lead institute partners in implementing lifecycle strategy, guidelines, and best practices that will drive an optimized non-commodity software environment. Success will be understood as a group exists and is effective.

NCSW-08

NIEHS will ensure that non-commodity software development projects include appropriate levels of federal project management. Project management assures accountability and project completion. The institute Project Management Office (PMO) will manage this as it gets up and running. Success will be understood by improved management and user satisfaction.

NCSW-09

NIEHS will continue to develop a solution delivery organization and process to assist application owners with end-to-end understanding and solutions for their requirements. Right-size project management will be used to maximize successful projects and customer satisfaction. Success will be understood as projects are completed on time, on schedule, and within budget, and customers get what they need.

Non-Commodity Software Future-State Planning

NCSW-10

NIEHS will develop a three-year plan for needed enterprise architecture changes in coordination with the Information Technology Architectural Review Group (ITARG). Planning will help create standard parameters to prioritize non-commodity software development and coordinate enterprise architecture to adapt to changing needs. Success will be understood as a plan is developed and standard parameters to prioritize non-commodity software development exist.

NCSW-11

NIEHS will create a three-year non-commodity software requirement roadmap for each domain. Roadmaps will include broad requirements and expected costs for development, operations, and retirement and will inform budget and help set realistic expectations. Details will be critical for setting priorities within and across domains. Success will be understood as each domain area has a leader who submits priorities and provides a high-level plan for each domain, and as all software items are represented in domain roadmaps.

NCSW-12

NIEHS will facilitate discussions of application transition and adoption as part of planning processes. This planning will help address why systems are developed but not adopted. Success will be understood as the PMO facilitates these kinds of discussions at the outset of projects.

NCSW-13

NIEHS will establish procedures and opportunities to elaborate needs and system requirements so they are serving needs of the users and stakeholders. Too many tools are developed that do not meet user needs and are perceived to be a waste of resources. Sometimes, these are duplicative of other efforts. Success will be understood as the PMO and solution delivery organization are facilitating these kinds of discussions at the outset of projects.

Facilitating Day-to-Day Non-Commodity Software Interactions

NCSW-14

NIEHS will communicate non-commodity software policies, procedures, events, and deadlines clearly to the entire community. Lack of transparency slows productivity and fosters inconsistency. Success will be understood as updates on application development guidelines, patching schedules, availability of new servers, and contact information are updated regularly in plain language. Opportunities for multidirectional communication are evident. Both pull-and-push communication methods are used.

NCSW-15

NIEHS will improve onboarding and startup for non-commodity software contractors (e.g., create new onboarding SOPs and default images). Non-commodity software staff, and especially new contractors, experience delays in getting new computers, servers, and authorizations, and this incurs hidden costs. Success will be understood as new default images are created for contractor machines that include the most common development tools to support non-commodity software activity and as SOPs for onboarding contractors are improved.

NCSW-16

NIEHS will develop hardware standards and default images for widely used development stacks, and a process to identify standards for optimal performance. Standards will set appropriate expectations for hardware performance and inform strategic planning for hardware purchases and capacity. Success will be understood as regular discussions about software dependencies on hardware occur, hardware standards and software images are available and installed, and standards for optimal performance are circulated.

NCSW-17

NIEHS will analyze policies and procedures for gaps and inconsistencies and create a process for approval of non-commodity software. Procedures are needed to ensure a coordinated, flexible, and interactive environment that operates smoothly and efficiently. Success will be understood as no (or minimal) surprises for business teams and I&IT providers.

Non-Commodity Software Theme Map

I&IT Landscape Agility Analytics Communications & Transparency Foster Collaboration Governance Optimize Resources Workforce Development

Non-Commodity Software

NCSW-05

NCSW-16

NCSW-11

NCSW-01

NCSW-02

NCSW-04

NCSW-14

NCSW-07

NCSW-17

NCSW-03

NCSW-09

NCSW-10

NCSW-12

NCSW-13

NCSW-06

NCSW-08

NCSW-15

See Appendix A: I&IT Priorities Support NIEHS Strategic Themes

Back
to Top