Technology Readiness Assessment

Definitions

Technology Readiness Assessment (TRA)

the architecture document (report) that documents the assessed maturity of the critical technologies being used to develop a system or application

Classification

As illustrated in the preceding figure, Technology Readiness Assessment is part of the following inheritance hierarchy:

• Type: Concrete
• Superclass: Document
• Subclasses:
  • None

Responsibilities

The typical responsibilities of a Technology Readiness Assessment are to:

• Document the:
  • Results of performing a technology readiness assessment.
  • Assessed technology readiness levels (TRLs) of the critical technologies used in the development of the system
• Provide evidence that the critical technologies of the system or application are sufficiently mature to not present significant risk to the endeavor.
• Identify endeavor risks due to the use of potentially immature technologies.

Contents

The typical contents of a technology readiness assessment are:

• Endeavor Overview:
  • Endeavor Objectives
  • Endeavor Cycle and Schedule
• System Overview:
  • System Mission
  • System Architecture
  • Major Technologies
• Assessment Overview:
  • Assessment Team
  • Assessment Process
• Assessment Results:
  • Critical Technologies
  • Assessments by Technology
• Conclusions
• Appendices:
  • Major Issues
  • TBDs
  • Assumptions

Stakeholders

The typical stakeholders of the technology readiness assessment are:

• Producers:
  • Architecture Team
  • Independent Technology Readiness Assessment Team
• Evaluators:
  • Architecture Inspection Team
• Approvers:
  • Technical Leader
  • Project Manager
  • Customer Representative(s)
• Maintainer:
  • N/A
• Users:
  • Technical Leader, who uses it to understand endeavor risks due to the use of immature technologies and to identify alternative technologies that are more mature
  • Project Manager, who uses it to understand endeavor risks due to the use of immature technologies
  • Customer Representative(s), who use it to understand endeavor risks due to the use of immature technologies

Phases

• Business Strategy: Not Applicable
• Business Optimization: Not Applicable
• Initiation: Completed
• Construction: Possibly Updated
• Delivery: Archived
• Usage: Archived
• Retirement: Archived

Preconditions

The technology readiness assessment typically can be started if the following preconditions hold:

• The initiation phase is started.
• The architecture team has been staffed and trained in the assessment of critical technologies.

Inputs

The typical inputs to the technology readiness assessment include:

• Work Products:
  • Application Vision Statement
  • Technology Analysis
  • Technology Needs Assessment
  • Software Architecture Document
  • System Architecture Document
• Stakeholders:
  • Technology Domain Experts
  • Vendor Representatives

Guidelines

• The use of an immature technology during the acquisition or development of a system can be a significant source of risk to the endeavor. Therefore, any technology used during standard development should have reached adequate maturity before development starts. Otherwise when practical, an alternative more mature technology should be used.
• A technology is major if the standard will depend on that technology to meet its requirements within acceptable schedule and costs (e.g., development, production, operation) constraints.
• A critical technology is any major technology that may be sufficiently immature (e.g., new or novel) to be a potential source of significant risk to the endeavor.
• A critical technology may involve hardware, software, and/or data.
• A technology is identified as critical at the beginning of the technology risk assessment process before the amount of risk and the level of maturity or immaturity is assessed.
• The definition of Technology Readiness Levels (TRLs) will vary depending on whether or not the associated critical technology is being developed as part of the system under development or is being reused, whereby reuse can include Commercial-Off-The-Shelf (COTS), organizational-internal reuse, Open Source reuse, Government-Off-Shelf (GOTS), or Non-Developmental Item (NDI). The following table provides example definitions for both new and reused critical technologies:
  
  

  	Definition for
  TRL	New Critical Technology	Reused Critical Technology
  1	Theory Exists: The basic theory underlying the critical technology exists.	N/A
  2	Technology Envisioned: A vision of the critical technology including its properties and uses exists. Basic research is beginning to be turned into applied research and development.	N/A
  3	Proof of Concept Exists: There exists a proof of concept implementation of important parts of the basic theory underlying the critical technology. Critical technology could exist in low-fidelity breadboard (hardware) or prototype/simulation (software) form. The critical technology’s place within the system architecture has been determined.	N/A
  4	Demonstrated in Lab Environment: The critical technology has been successfully demonstrated in the laboratory or verified via initial component testing. Critical technology could exist in high-fidelity brassboard (hardware) or prototype (software) form. The critical technology does not yet implement all functional and quality requirements allocated to it. The critical technology has not been successfully integrated with the rest of the system under development.	N/A
  5	Integration Tests Passed: The critical technology has been successfully integrated with the rest of the system under development as verified by integration testing. Initial testing or analysis verifying implementation of allocated quality requirements are underway.	N/A
  6	System Tests Passed: The system including the critical technology has passed system testing, thereby verifying that the critical technology implements the functional and quality requirements that have been allocated to it.	Technology Under Development: The critical technology is under development. Its availability date is scheduled, but the technology is not yet available (e.g., vaporware).
  7	Alpha Tests Passed: The system including the critical technology has been successfully demonstrated in a realistic production environment by an initial small set of Alpha users, who did not expect achievement of all quality requirements (especially reliability and robustness). The rate of reported defects/failures and the rate of new versions is very high.	Initial Unsupported Version Available: An initial unsupported version of the critical technology is available. All relevant systems incorporating the critical technology are still under development. The critical technology may not adequately implement all relevant functional requirements of the system under development. The rate of reported defects/failures and the rate of new versions is very high.
  8	Beta Tests Passed: The system including the critical technology has been successfully demonstrated in a realistic production environment by a larger set of Beta users. The rate of reported defects/failures and the rate of new versions is high.	Initial Supported Version Available: An initial supported production version of the critical technology is available. The critical technology (1) adequately implements the essential functional and quality requirements of the system under development and (2) has been incorporated into one or more commercial, governmental, or military pilot systems, where it has enabled these systems to successfully accomplish their mission objectives during Beta testing. The rate of reported defects/failures and the rate of new versions is high.
  9	Operational Tests Passed: The functional and quality requirements of the system under development that have been allocated to the critical technology have been successfully verified in the operational environments via Operational testing. The critical technology has been proven to work in its final form and environment under expected conditions. The rate of reported defects/failures and the rate of new versions is decreasing.	Successful Pilot Usage: The critical technology (1) adequately implements the relevant functional requirements of the system under development and (2) has been incorporated into one or more commercial, governmental, or military pilot systems, where it has enabled these systems to successfully accomplish their mission objectives during actual usage in their operational environments. The rate of reported defects/failures and the rate of new versions is decreasing.
  10	Successful Production Usage: The functional and quality requirements of the system under development that have been allocated to the critical technology have been proven through successive successful accomplishment of the system’s mission objectives. The rate of reported defects/failures and the rate of new versions is low and stable.	Successful Production Usage: The critical technology (1) adequately implements the relevant functional and quality requirements of the system under development and (2) has been incorporated into one or more commercial, governmental, or military roduction systems, where it has enabled these systems to successfully accomplish their mission objectives during actual usage in their operational environments. The rate of reported defects/failures and the rate of new versions is low and stable.

  
  
• It is important to measure the maturity of COTS critical technology with regard to relevant quality factors that are typically not adequately implemented in commercially available products (e.g., security, reliability, safety, performance, and capacity).
• A technology readiness assessment can be performed by:
  • The architecture team to help them determine what critical technologies to incorporate into the architecture
  • An independent team of assessors (i.e., funded by and reporting to the customer representative) to determine if the architecture includes inappropriately-chosen immature technologies.
• This is a living document that is developed incrementally and iteratively in parallel with other documents.
• The technology analysis is typically done at the enterprise level during a business reengineering endeavor, whereas this document is typically produced at the system level.
• In September 2003, the US Department of Defense published a TRA Deskbook.

Conventions

Technology Strategy is typically constrained by the following conventions:

• Work Flow
• Content and Format Standard
• MS Word Template
• XML Template
• Inspection Checklist

Examples

• Example Technology Readiness Assessment