NASA Technology Readiness Levels: A Software Development Perspective

NASA’s Technology Readiness Levels (TRLs) have become a standard way to assess the maturity of technologies in certain industries like aerospace and defense. Originally developed by NASA in the 1970s, TRLs provide a consistent framework for evaluating how close a technology is to being deployment-ready. This framework has become increasingly relevant for modern software development, particularly in technical startups dealing with emerging technologies.

The Original NASA TRL Scale

Basic Research (TRL 1-3)

  • TRL 1: Basic principles observed and reported

    • Software Equivalent: Initial research, proof of mathematical concepts
    • Example: Researching a new encryption algorithm

  • TRL 2: Technology concept formulated

    • Software Equivalent: Basic architectural design, theoretical application
    • Example: High-level system design documents

  • TRL 3: Experimental proof of concept

    • Software Equivalent: Initial prototype or POC implementation
    • Example: Basic working implementation in a sandbox environment

Applied Research (TRL 4-5)

  • TRL 4: Technology validated in lab

    • Software Equivalent: Working prototype with core functionality
    • Example: MVP with basic features running locally

  • TRL 5: Technology validated in relevant environment

    • Software Equivalent: Integration testing in staging environment
    • Example: Application deployed to staging with test data

Development (TRL 6-7)

  • TRL 6: Technology demonstrated in relevant environment

    • Software Equivalent: Beta testing with real users
    • Example: Limited production release with early adopters

  • TRL 7: System prototype demonstration in operational environment

    • Software Equivalent: Production pilot with full feature set
    • Example: Full system deployed to select customers

Deployment (TRL 8-9)

  • TRL 8: System complete and qualified

    • Software Equivalent: Production-ready system with complete testing
    • Example: System deployed with full monitoring and support

  • TRL 9: Actual system proven in operational environment

    • Software Equivalent: System in production with real users/load
    • Example: Widely deployed application with proven reliability

Key Differences in Software

While NASA’s TRL system translates well to software, there are some key differences. For a deeper exploration of how different methodologies intersect in technical organizations, see my post on Science vs. Engineering in Startups.

  1. Iteration Speed: Software development typically moves faster through these levels due to lower physical constraints and faster deployment cycles.

  2. Continuous Updates: Unlike physical systems, software often continues to evolve post-TRL 9 through updates and new features.

  3. Environment Definition: “Relevant environment” in software can mean different things - from simulated load to actual user behavior.

Practical Applications

Using TRLs in software development can help:

  • Set clear milestones for development progress
  • Communicate readiness to stakeholders
  • Make informed decisions about technology adoption
  • Structure development and deployment phases
  • Assess and manage technical risk

Risk Assessment Using TRLs

One of the most valuable applications of TRLs in software development is risk assessment. Each TRL transition represents different types of risks:

  • TRL 1-3: Technical feasibility risk
  • TRL 4-5: Integration and scaling risk
  • TRL 6-7: User adoption and performance risk
  • TRL 8-9: Operational and maintenance risk

This risk framework can be particularly valuable when making decisions under uncertainty in technical projects.

Conclusion

While NASA’s TRL system was designed for space technology, its principles apply remarkably well to software development. By understanding these parallels, teams can better structure their development process and communicate progress to stakeholders. The key is adapting the framework to match software’s unique characteristics while maintaining the rigorous evaluation approach that made TRLs valuable in the first place.

You can use these levels to help categorize work into different maturity buckets. The work of TRL 1-3 (research phase) is fundamentally different from TRL 4-5 work (validation phase), and TRL 6-7 work differs from TRL 8-9 work (production phase). These might be handled by different teams, using different processes, with different metrics tracked for each. Understanding these distinctions upfront helps avoid the common pitfall of trying to manage early-stage research work (TRL 1-3) with the same methodologies used for production systems (TRL 8-9).