Skip Ribbon Commands Skip to main content

Introduction

The decision criteria below, established by NIHRFC0015, Decision Criteria for Selecting NIH Standards, represent the minimum set of decision criteria for determining architecture standards at NIH. Decision-makers can use these criteria as the basis for business case analysis (BCA). The criteria may be augmented or clarified as needed. However, all modifications should be documented.

When the author (i.e., domain team, ad hoc working group, or other body/individual proposing a standard) of a proposed architecture standard applies these criteria, it is recommended that they prioritize the relative importance of each criterion by assigning weights as applicable given the technical domain for which these criteria are being considered. The author is required to briefly document the justification for allocating these weights in their output reports. 

The intent of prioritizing, weighting, and applying these decision criteria is to ensure authors exercise the same level of analysis in considering architecture standards that a project manager exercises when developing a BCA for a potential investment. Doing so will enable other stakeholders to leverage this information in BCAs for investments that are based on these technical standards.

Drivers

The two NIH Enterprise Architecture enterprise principles that drive these decision criteria are:

  • Optimum Enterprise Benefit - Architectural decisions will maximize the overall benefit to the NIH by balancing the following criteria: accessibility, consistency, cost, diversity of business needs, flexibility, functionality, manageability, precision, risk, scalability, security, supportability and value.
  • Technology Components - The NIH Enterprise Architecture supports leading edge technologies to meet mission differentiating needs and requires mature, proven interoperable technologies in support of service environments. Technical diversity that does not tie to business needs is discouraged.


Decision Criteria

The decision criteria are:

  • Existing NIH Installed Base – evaluates NIH’s experience with the technology and the use and adoption of the standard throughout NIH ICs. A large NIH installed base is favorable because it suggests that NIH has the skills and competencies required to work with, support, service, or otherwise maintain the technical element. Existing NIH installed base also indicates that the technology or product being evaluated has proven itself to be a fit for NIH’s needs and the NIH environment.
  • Fit With Existing NIH Standards, Technologies, and Systems – evaluates any known interoperability issues a potential standard may have with existing technology standards such as compatibility with existing Enterprise System Monitoring (ESM) packages and processes. Products and standards that have a track record of cooperating within the NIH environment, or within environments similar to the NIH, expose the NIH to less risk than products that have yet to be proven and/or may have unknown issues, incompatibilities, or risks.
  • Maintainability/Supportability – evaluates the effort and specialized skill sets required to support a technology standard. For example, by minimizing the number of operating systems or database management systems, NIH can minimize the time, effort and expenditure needed to integrate applications and manage data. This will help to facilitate training and simplify staffing since skills requirements are streamlined.
  • Cost – evaluates the estimated total cost of ownership if NIH chooses to adopt the standard. The total cost of ownership will consider both the cost to procure the technology as well as the anticipated costs to transition, maintain, support and integrate the technology on an ongoing basis. Cost estimates based on market research statistics and independent research opinions will be used in the decision-making process.
  • Strategic Value – evaluates the breadth of product capabilities in order to leverage an investment. Products that offer more capabilities that could be leveraged in the future provide the NIH with more flexibility and scalability than do products without these advantages.
  • Flexibility – evaluates the breadth of the standard’s applicability to multiple stakeholder classes. For example, a product that meets the needs of multiple constituencies provides the NIH with greater enterprise wide implementation opportunities than do “niche” products that are adaptable to only a small set of constituencies (assuming capabilities are equal).
  • Security – evaluates the ability and/or effectiveness of the potential technology standard within the NIH security environment. Products that comply with existing NIH security policy or standards, and/or do not have any known conflicts with components such as NIH firewalls or DMZs represent less risk (implementation risk, cost risk, and security risk) than do products or standards that have yet to be proven and/or may have unknown issues, incompatibilities, or risks.
  • Vendor Viability – evaluates the health of the product vendor in terms of its stability, projected longevity, and likelihood it will exist in the future to support the product and later versions of the product. Vendor viability will be determined by its financial health, position in the market place, external research sources, and any market factors that could compromise the vendor’s existence. In the case of open source standards, where financial health and market coverage are not discerning variables, project and organization history will be addressed in the evaluation.
  • Industrial Installed Base – evaluates the use and adoption of the standard throughout industry in general (both commercial and public enterprises). A large installed base is an indication that personnel (internal or external to the NIH) and supplementary tools and products are available to support, service, or otherwise maintain the technical element.
  • Product Life cycle – evaluates the expected time the product will be in use and supported by the vendor and the ability to maintain currency of its functionality and operation. A longer life cycle is desirable from a training and hardware investment perspectives.


Last Updated: November 18, 2011