Technology Assessment
Overview
Technology assessment evaluates technologies for strategic fit, technical feasibility, and competitive advantage. This skill covers frameworks for making informed technology decisions.
Required Frameworks
| Framework | Output Section | Required | Condition | |-----------|---------------|----------|-----------| | TRL Levels | Technology Readiness | yes | — | | Hype Cycle Mapping | Hype Cycle Position | yes | — | | Build vs Buy Matrix | Build vs Buy Analysis | yes | — | | Domain-Specific Due Diligence | Due Diligence | conditional | Applicable domain detected (AI/ML, Fintech, Healthcare, Infrastructure) |
Trend Indicators: Load and apply the trend indicator definitions from protocols/TREND-INDICATORS.md.
Critical Assessment Rules
Follow these rules to produce assessments that are honest, grounded, and actionable:
- Contextual Grounding: Always tie scores, recommendations, and analysis back to the user's specific context (team size, scale, budget, timeline). A technology that scores 5/5 for Google may score 2/5 for a 10-person startup.
- Honest Scoring: Do not inflate scores. A score of 2 or 3 is normal and valuable — it tells the user where the risks are. If a technology has known weaknesses, say so. Scores above 4 require strong justification.
- Decisive Recommendations: End every assessment with a clear recommendation. "It depends" is not a recommendation. If the answer genuinely depends, specify what it depends ON and give a recommendation for each scenario.
- Trend Indicators Everywhere: Apply INC/DEC/CONST trend indicators to every technology mentioned, not just the primary subject. Trend context helps the user understand trajectory.
- Domain Tailoring: When the user's domain has specific considerations (AI/ML, fintech, healthcare, infrastructure), extend the standard framework with domain-specific evaluation criteria rather than using a generic checklist.
- Always Consider Alternatives: Every assessment should mention at least 2-3 alternatives to the technology being assessed, with brief comparative notes. The user needs to know what else they could choose.
- Quantify When Possible: Prefer concrete numbers over vague qualifiers. "50k msgs/sec" is better than "high throughput." "$23k/year" is better than "affordable." "3-6 months" is better than "some time."
Assessment Dimensions
Technical Maturity
- Proven vs. emerging
- Stability and reliability
- Community/ecosystem size
- Documentation quality
Strategic Fit
- Alignment with business goals
- Competitive differentiation potential
- Integration with existing systems
- Scalability trajectory
Risk Profile
- Technology risk (will it work?)
- Adoption risk (will people use it?)
- Vendor risk (will they survive?)
- Security risk (vulnerabilities)
Economic Factors
- Total cost of ownership
- Time to value
- Resource requirements
- Opportunity cost
Technology Readiness Levels (TRL)
| Level | Description | Characteristics | |-------|-------------|-----------------| | TRL 1-3 | Research | Concept only, no implementation | | TRL 4-6 | Development | Prototype, limited deployment | | TRL 7-8 | Production | Proven at scale, enterprise-ready | | TRL 9 | Mature | Widely adopted, commoditized |
Gartner Hype Cycle Mapping
Position technologies on the hype cycle:
- Innovation Trigger: New technology emerges
- Peak of Inflated Expectations: Hype exceeds reality
- Trough of Disillusionment: Reality sets in
- Slope of Enlightenment: Practical use cases emerge
- Plateau of Productivity: Mainstream adoption
Build vs. Buy Framework
Build When:
- Core competitive differentiator
- Unique requirements not met by market
- Long-term cost advantage
- Internal expertise available
- Control is critical
Buy When:
- Commodity functionality
- Time-to-market critical
- Proven solutions exist
- Maintenance burden undesirable
- Lower total cost of ownership
Build vs. Buy Matrix
| Factor | Weight | Build Score | Buy Score | |--------|--------|-------------|-----------| | Strategic importance | 30% | 1-5 | 1-5 | | Differentiation | 25% | 1-5 | 1-5 | | Time to market | 20% | 1-5 | 1-5 | | Total cost | 15% | 1-5 | 1-5 | | Risk | 10% | 1-5 | 1-5 | | Weighted Total | 100% | X.X | X.X |
Show the math: For each factor, multiply the score by the weight. Sum the weighted scores for Build and Buy separately. The option with the higher weighted total wins. Example: Strategic importance Build=3, weight=30% → 0.90. Display both the individual weighted contributions and the totals.
Technology Stack Analysis
Layers to Assess
Infrastructure
- Cloud provider (AWS, Azure, GCP)
- Compute (containers, serverless, VMs)
- Storage and databases
- Networking
Platform
- Application frameworks
- Runtime environments
- Development tools
- CI/CD pipeline
Application
- Core product technologies
- Third-party integrations
- APIs and services
- Security stack
Stack Evaluation Criteria
| Criterion | Question | Weight | |-----------|----------|--------| | Performance | Does it meet requirements? | High | | Scalability | Can it grow with us? | High | | Maintainability | Easy to support? | Medium | | Security | Meets compliance needs? | High | | Cost | Fits budget? | Medium | | Talent | Can we hire for it? | Medium | | Community | Active ecosystem? | Low |
Scoring Calibration
Use these anchor definitions to ensure consistent scoring across assessments:
| Score | Meaning | Example | |-------|---------|---------| | 1 | Critical weakness, likely blocker | No production deployments exist; vendor may not survive 12 months | | 2 | Significant concern, requires mitigation | Works in limited scenarios but known scaling issues; small talent pool | | 3 | Adequate, meets minimum requirements | Production-ready with caveats; moderate community; reasonable cost | | 4 | Strong, clear advantage | Battle-tested at scale; large ecosystem; good cost/value ratio | | 5 | Exceptional, best-in-class | Industry standard; massive community; proven at extreme scale |
Inflation check: If your overall score is above 4.0, re-examine each dimension. Technologies scoring 4+ across all dimensions are rare — most have at least one weak area (usually cost, talent availability, or operational complexity). An assessment with all 4s and 5s is almost certainly inflated.
Trend Indicators for Technologies
Apply three-valued logic:
INC (Increasing adoption)
- Growing community
- Increasing job postings
- Rising search interest
- New investment/funding
DEC (Decreasing adoption)
- Shrinking community
- Declining job postings
- Migration to alternatives
- Vendor instability
CONST (Stable)
- Mature, established
- Steady usage patterns
- No major changes
Competitive Technology Analysis
Assess how competitors use technology:
| Competitor | Key Technologies | Strengths | Weaknesses | Trend | |------------|------------------|-----------|------------|-------| | A | [Stack] | [Advantage] | [Gap] | INC/DEC/CONST | | B | [Stack] | [Advantage] | [Gap] | INC/DEC/CONST |
Technical Due Diligence
For M&A or partnership evaluation:
Architecture Review
- System design and patterns
- Scalability approach
- Technical debt level
- Documentation quality
Code Quality
- Testing coverage
- Code review practices
- Security practices
- Performance benchmarks
Operations
- Deployment processes
- Monitoring and observability
- Incident response
- SLA track record
Team
- Skills and expertise
- Key person dependencies
- Knowledge documentation
- Retention risk
Domain-Specific Due Diligence Extensions
When the target company operates in a specialized domain, extend the standard four-area framework with domain-specific evaluation criteria. Every sub-item within Architecture Review, Code Quality, Operations, and Team must be covered — do not skip sub-items.
**AI/ML Co