Technology Radar

A Technology Radar is a visual tool for tracking technologies, techniques, and tools relevant to your organization. It helps teams make informed decisions about technology adoption.

Radar Structure

Ring Definitions

Ring	Definition	Action
Adopt	Proven, recommended for broad use	Use by default
Trial	Worth pursuing, ready for projects	Use with caution
Assess	Worth exploring, understand impact	Experiment only
Hold	Proceed with caution, don't start new	Migrate away

Quadrants

### Languages & Frameworks
Technologies for building applications

### Tools
Development, build, and operational tools

### Platforms
Infrastructure and runtime platforms

### Techniques
Practices, patterns, and approaches

Sample Technology Radar

Languages & Frameworks

#### Adopt
- **C# 12 / .NET 8**: Latest LTS, excellent performance
- **TypeScript**: Type safety for frontend
- **React 18**: Stable, wide ecosystem

#### Trial
- **Blazor WASM**: C# in browser, evaluate for admin tools
- **Rust**: For performance-critical services
- **htmx**: Simple interactivity without SPA complexity

#### Assess
- **F#**: Functional programming for complex domains
- **Bun**: Fast JavaScript runtime, watch maturity

#### Hold
- **.NET Framework**: Migrate to .NET 8
- **AngularJS**: End of life, migrate to React

Platforms

#### Adopt
- **Kubernetes**: Container orchestration standard
- **Azure**: Primary cloud provider
- **PostgreSQL**: Default relational database
- **Redis**: Caching and session storage

#### Trial
- **Azure Container Apps**: Simpler than AKS for some workloads
- **EventStoreDB**: For event sourcing projects
- **Pulumi**: Infrastructure as code with real languages

#### Assess
- **CockroachDB**: Distributed SQL, evaluate for global apps
- **Neon**: Serverless Postgres, watch development
- **Fly.io**: Edge deployment platform

#### Hold
- **SQL Server**: High licensing costs, prefer PostgreSQL
- **MongoDB**: Consistency issues, prefer PostgreSQL

Techniques

#### Adopt
- **Event Sourcing**: For audit-heavy domains
- **CQRS**: When read/write patterns differ significantly
- **Trunk-Based Development**: Fast integration, feature flags
- **Infrastructure as Code**: All infrastructure in Git

#### Trial
- **Domain-Driven Design**: For complex business domains
- **Micro Frontends**: For large frontend teams
- **Contract Testing**: API compatibility verification

#### Assess
- **Cell-Based Architecture**: Fault isolation at scale
- **AI-Assisted Development**: GitHub Copilot, evaluate productivity

#### Hold
- **Long-lived Feature Branches**: Merge conflicts, integration hell
- **Manual Infrastructure**: Everything must be codified

Radar Entry Template

## GraphQL Federation

**Ring:** Trial  
**Quadrant:** Languages & Frameworks  
**Added:** 2024-Q1  
**Last Updated:** 2024-Q2

### What is it?
Apollo Federation enables building a unified GraphQL API from 
multiple independent subgraphs, each owned by different teams.

### Why this ring?
- Successfully piloted in Product Catalog team
- Reduced BFF complexity by 40%
- Good developer experience
- Moving to Adopt pending production validation

### Considerations
- Requires Apollo Gateway infrastructure
- Team training needed
- Schema governance process required

### Related
- ADR-015: GraphQL Strategy
- RFC: GraphQL Federation Implementation

Radar Governance

// Technology request workflow
public class TechnologyProposal
{
    public string Name { get; set; }
    public string Quadrant { get; set; }
    public string ProposedRing { get; set; }
    
    public string Problem { get; set; }
    public string Solution { get; set; }
    public List<string> Alternatives { get; set; }
    
    public string ProofOfConcept { get; set; }
    public List<string> Risks { get; set; }
    public string MigrationPath { get; set; }
    
    public string Sponsor { get; set; }
    public List<string> Reviewers { get; set; }
}

// Review process
public enum ReviewOutcome
{
    Approved,           // Add to radar at proposed ring
    ApprovedDifferent,  // Add at different ring
    NeedsMoreInfo,      // Request additional details
    Rejected,           // Don't add to radar
    Deferred            // Revisit later
}

Radar Review Cadence

### Quarterly Review Process

1. **Week 1-2**: Collect proposals
   - Teams submit new technology proposals
   - Existing entries nominated for ring changes
   
2. **Week 3**: Architecture review
   - Review all proposals
   - Evaluate against criteria
   - Make recommendations

3. **Week 4**: Publication
   - Update radar visualization
   - Communicate changes
   - Update documentation

Evaluation Criteria

### Criteria for Ring Placement

#### Moving to Adopt
- [ ] Used in production for 6+ months
- [ ] At least 2 teams have experience
- [ ] Documentation and training available
- [ ] Support/maintenance plan exists
- [ ] No significant production issues

#### Moving to Trial
- [ ] Successful proof of concept
- [ ] Clear use case identified
- [ ] Team willing to pioneer
- [ ] Fallback plan exists
- [ ] Limited blast radius

#### Moving to Hold
- [ ] Security vulnerabilities
- [ ] Vendor/community abandonment
- [ ] Better alternatives exist
- [ ] High maintenance burden
- [ ] Migration path documented

Communication

### Radar Change Announcement

**Subject:** Technology Radar Update - Q1 2024

**New Additions:**
- GraphQL Federation → Trial
- Temporal.io → Assess
- Azure Container Apps → Trial

**Ring Changes:**
- OpenTelemetry: Trial → Adopt
- Dapr: Assess → Trial
- WCF: Hold (migration required by Q4)

**Removed:**
- jQuery (migration complete)

**Action Required:**
- Teams using WCF: Begin migration planning
- New projects: Consider GraphQL Federation for API layer

**Resources:**
- Full radar: [link]
- ADR index: [link]
- Training calendar: [link]

Key Takeaways

1. Visual Communication: Radar makes tech decisions visible
2. Continuous Evolution: Update quarterly, not annually
3. Clear Criteria: Define what each ring means
4. Governance Process: Formal process for additions/changes
5. Action-Oriented: Each ring implies specific actions

---

💡 Flashcard

What are the four rings of a Technology Radar?

Click to reveal answer

✅ Answer

Adopt (use by default), Trial (use with caution on suitable projects), Assess (explore and experiment), Hold (don't start new work, migrate away).

Click to see question

💡 Flashcard

How often should a Technology Radar be updated?

Click to reveal answer

✅ Answer

Quarterly reviews are recommended. This allows enough time to gather experience with technologies while keeping the radar current and actionable.

Click to see question

Loading quiz...