Tech Radar and Roadmaps in Developer Portal

Engineering teams lack a centralized, interactive way to visualize and communicate technology adoption decisions and strategic roadmaps. This proposal introduces a Tech Radar (inspired by ThoughtWorks) and Roadmap Management capability for the internal developer portal.

Key Insight: Technology decisions scattered across wikis, spreadsheets, and tribal knowledge lead to duplicated evaluation efforts, inconsistent adoption, and poor visibility into the organization's technical direction. A unified Tech Radar provides the single source of truth for "what technologies should we use."

Problem Statement

Current State: Fragmented Technology Decisions

Evidence from Organizations

Problem	Impact
No central technology registry	Teams duplicate evaluation efforts
Decisions buried in meeting notes	New team members don't know what's approved
No deprecation visibility	Legacy tech persists without migration plans
Roadmaps in disconnected tools	Strategic direction unclear to ICs
No proposal workflow	Technology adoption feels arbitrary

Real Examples

Scenario 1: Duplicate Evaluation

"Three teams independently evaluated state management libraries over 6 months. Each produced different recommendations because they didn't know about each other's work."

Scenario 2: Hidden Deprecation

"We decided to deprecate Library X two quarters ago, but it's still in the 'approved' list on Confluence. New projects keep adopting it."

Scenario 3: Strategic Misalignment

"Leadership announced a 'cloud-native' strategy, but there's no roadmap showing what that means for teams. Each team interprets it differently."

Scenario 4: External Platform Changes Untracked

"Chrome shipped OffscreenCanvas and transferable streams six months ago, enabling us to move heavy media processing to worker threads. But nobody tracked this - teams are still blocking the main thread with canvas operations."

Use Case: Tracking External Platform Evolution

Beyond internal technology decisions, Tech Radar should track external platform capabilities that influence architectural direction.

Example: Browser Capabilities Driving Architecture

What to Track

Category	Examples	Why Track
Browser APIs	OffscreenCanvas, WebGPU, View Transitions	Enables new patterns, deprecates old workarounds
Runtime Changes	Node.js LTS, Deno features, Bun compatibility	Affects backend architecture decisions
Protocol Updates	HTTP/3, HTTP QUERY method, WebTransport	Influences networking layer design
Security Standards	CORS changes, Cookie policies, CSP updates	Requires application changes
Standards Bodies	W3C DTCG (Design Tokens), OpenAPI updates, TC39 proposals	Influences tooling and format decisions

Recording External Changes

Tech Radar entries for external platform changes should include:

## Technology: OffscreenCanvas + Transferable Streams

### Ring: Adopt
### Quadrant: Techniques

### Summary
Chrome 69+ supports OffscreenCanvas with transferable control, enabling
canvas rendering entirely in Web Workers without main thread involvement.

### Architectural Impact
- **Before**: Heavy canvas operations block main thread, causing jank
- **After**: Transfer canvas to worker, process frames off-thread
- **Migration**: Identify canvas-heavy components, refactor to worker pattern

### Affected Systems
- Video processing pipeline
- Real-time visualization components
- Image manipulation features

### Browser Support
- Chrome: 69+ (full support)
- Firefox: 105+ (partial)
- Safari: 16.4+ (partial)

### Action Items
- [ ] Audit current canvas usage across frontend
- [ ] Create worker-based canvas utility library
- [ ] Migrate video thumbnail generator (highest impact)
- [ ] Update performance guidelines

Example: Protocol Evolution (HTTP QUERY Method)

## Technology: HTTP QUERY Method (RFC Draft)

### Ring: Assess
### Quadrant: Techniques

### Summary
IETF draft proposes QUERY as a new HTTP method - like GET but with a request
body. Solves the problem of complex queries exceeding URL length limits.

### Architectural Impact
- **Before**: Complex search queries use POST (not cacheable) or URL encoding
- **After**: QUERY method allows request body with GET-like cacheability
- **API Design**: Can simplify search/filter endpoints

### Current Status
- IETF draft stage (not yet RFC)
- No browser/server support yet
- Worth tracking for future API design

### Action Items
- [ ] Monitor IETF draft progress
- [ ] Evaluate impact on current search APIs using POST
- [ ] Plan adoption once server/client support available

Example: Standards Body Decisions (W3C DTCG)

## Technology: W3C Design Tokens Community Group (DTCG) Format

### Ring: Assess
### Quadrant: Techniques

### Summary
W3C DTCG is standardizing a JSON-based design token format. Once finalized,
this will become the interoperability standard between design tools (Figma,
Sketch) and development toolchains.

### Architectural Impact
- **Before**: Each design system uses proprietary token formats
- **After**: Unified format enables tool-agnostic token pipelines
- **Migration**: Evaluate current token format, plan migration path

### Why Track Now
- Draft spec is stabilizing
- Major tools (Figma Variables, Style Dictionary) aligning to spec
- Early adoption reduces future migration cost

### Action Items
- [ ] Evaluate current design token format vs DTCG spec
- [ ] Test Style Dictionary DTCG plugin
- [ ] Engage with design team on Figma Variables export format
- [ ] Plan incremental migration strategy

Integration with Roadmap

External platform changes should link to internal roadmap milestones:

External Change	Roadmap Milestone	Timeline
WebGPU stable in Chrome	GPU-accelerated visualization phase	Q2
View Transitions API	SPA navigation improvements	Q3
W3C DTCG spec finalized	Design system token format migration	Q4
Baseline 2024 features	Browser support policy update	Q1

Proposal: Tech Radar and Roadmaps

Target State

Tech Radar Visualization

The radar displays technology adoption status across four rings and four quadrants:

Rings (Adoption Status)

Ring	Meaning	Action
Adopt	Proven, recommended for broad use	Use by default
Trial	Worth pursuing, low-risk experimentation	Use in new projects with caution
Assess	Worth exploring, understand impact	Evaluate, don't commit yet
Hold	Proceed with caution, actively avoid	Don't start new usage

Quadrants (Technology Categories)

Quadrant	Examples
Languages & Frameworks	TypeScript, React, Go, Spring Boot
Tools	Docker, Kubernetes, Terraform, GitHub Actions
Platforms	AWS, GCP, Cloudflare, Vercel
Techniques	Trunk-based development, Feature flags, BFF pattern

Radar Visualization Component

Key Features:

• Interactive radar with hover/click for details
• Filter by quadrant, ring, or search term
• Technology detail panel with rationale, ADR links, adoption history
• Historical comparison view (compare radar across time periods)
• Export to PNG/PDF for presentations

Technology Proposal Workflow

Proposal Lifecycle

Proposal Template

## Technology Proposal: [Name]

### Summary
One-paragraph description of the technology and why it matters.

### Proposed Ring
[ ] Adopt  [ ] Trial  [ ] Assess  [ ] Hold

### Quadrant
[ ] Languages & Frameworks  [ ] Tools  [ ] Platforms  [ ] Techniques

### Problem Statement
What problem does this solve? Why now?

### Evaluation Criteria
- Performance benchmarks
- Security assessment
- Learning curve
- Community support
- License compatibility

### Evidence
- Proof of concept results
- Team feedback
- Comparison with alternatives

### Risks and Mitigations
| Risk | Mitigation |
|------|------------|
| ... | ... |

### Sponsor
[Name and team of the proposal sponsor]

Voting and Approval

Role	Capabilities
Contributor	Submit proposals, vote on proposals
Reviewer	Approve/reject proposals, request revisions
Admin	Manage radar, override decisions, configure settings

Approval thresholds (configurable):

• Adopt: Requires 3+ reviewer approvals
• Trial: Requires 2+ reviewer approvals
• Assess: Requires 1 reviewer approval
• Hold: Requires 2+ reviewer approvals (for deprecation)

Roadmap Management

Roadmap Structure

Roadmap Features

• Timeline View: Visual timeline with milestones and dependencies
• Milestone Management: Create, edit, track milestone status
• Dependency Tracking: Show relationships between initiatives
• Progress Indicators: Planned / In Progress / Completed / Blocked
• Export Options: PNG, PDF, embed code for documentation

Roadmap-Radar Integration

Roadmap milestones can link to:

• Tech Radar items (technology decisions)
• ADRs (architectural decisions)
• Related documentation

Technical Design

Data Model

technologies
├── id: UUID
├── name: string
├── description: text
├── quadrant: enum (languages, tools, platforms, techniques)
├── homepage_url: string
├── created_at: timestamp
└── created_by: user_id

radar_snapshots
├── id: UUID
├── technology_id: FK
├── ring: enum (adopt, trial, assess, hold)
├── rationale: text
├── snapshot_date: date
├── created_by: user_id
└── related_adrs: UUID[]

proposals
├── id: UUID
├── technology_id: FK (nullable for new tech)
├── proposed_ring: enum
├── status: enum (draft, review, approved, rejected)
├── sponsor_id: user_id
├── content: jsonb
├── created_at: timestamp
└── updated_at: timestamp

votes
├── id: UUID
├── proposal_id: FK
├── user_id: FK
├── vote: enum (approve, reject, abstain)
├── comment: text
└── created_at: timestamp

roadmaps
├── id: UUID
├── title: string
├── description: text
├── start_date: date
├── end_date: date
├── owner_id: user_id
└── visibility: enum (public, team, private)

milestones
├── id: UUID
├── roadmap_id: FK
├── title: string
├── description: text
├── target_date: date
├── status: enum (planned, in_progress, completed, blocked)
├── dependencies: UUID[]
└── linked_technologies: UUID[]

API Endpoints

Endpoint	Method	Description
/api/radar	GET	Get current radar state
/api/radar/history	GET	Get historical snapshots
/api/radar/technologies	GET/POST	List/create technologies
/api/radar/technologies/:id	GET/PUT/DELETE	Manage technology
/api/radar/proposals	GET/POST	List/create proposals
/api/radar/proposals/:id/vote	POST	Vote on proposal
/api/roadmaps	GET/POST	List/create roadmaps
/api/roadmaps/:id/milestones	GET/POST	Manage milestones

Visualization Library

Recommendation: D3.js

Option	Pros	Cons
D3.js	Maximum flexibility, strong community	Higher learning curve
Zalando Tech Radar	Pre-built radar	Limited customization
Chart.js	Easy to use	No native radar ring support

D3.js provides the flexibility needed for interactive features (hover details, filtering, animations) while being well-maintained with strong community support.

Implementation Roadmap

Phase 1: Foundation

Goal: Basic radar visualization with static data.

• [ ] Set up database schema for technologies and snapshots
• [ ] Create radar visualization component (D3.js)
• [ ] Implement basic CRUD API for technologies
• [ ] Add quadrant filtering and search
• [ ] Deploy read-only radar with curated initial dataset

Phase 2: Proposal Workflow

Goal: Enable collaborative technology proposals.

• [ ] Implement proposal submission form
• [ ] Add voting mechanism
• [ ] Create reviewer dashboard
• [ ] Build notification system for proposal updates
• [ ] Enable proposals for tech leads

Phase 3: Roadmap Management

Goal: Timeline-based roadmap capabilities.

• [ ] Create roadmap data model and API
• [ ] Build timeline visualization component
• [ ] Implement milestone management
• [ ] Add dependency tracking
• [ ] Enable roadmap-radar linking

Phase 4: Integration

Goal: Connect with existing systems.

• [ ] Link radar items to ADRs
• [ ] Integrate with developer portal search
• [ ] Add RSS/webhook notifications
• [ ] Enable embed codes for documentation
• [ ] API documentation with OpenAPI spec

CLAUDE.md Integration

Add to project CLAUDE.md:

## Tech Radar

### Technology Selection
- **Always check** Tech Radar before adopting new technologies
- **Prefer** technologies in Adopt ring
- **Document rationale** when using Trial or Assess technologies
- **Never use** Hold technologies without explicit exception approval

### Search Strategy
When selecting technologies:
1. Check Tech Radar for existing decisions
2. Search for related ADRs
3. If not found, consider submitting a proposal

### Prohibited
- Adopting Hold-ring technologies without exception
- Creating duplicate technology evaluations
- Ignoring deprecation timelines

Success Metrics

Metric	Before	Target	How to Measure
Duplicate evaluations	Common	Rare	Track proposals for same tech
Technology decision visibility	Low	High	Survey: "Do you know where to find tech decisions?"
Time to find approved tech	Minutes	Seconds	Task timing study
Deprecation compliance	Unknown	>90%	Audit usage of Hold technologies
Proposal turnaround time	N/A	<2 weeks	Track proposal lifecycle duration

Risks and Mitigations

Risk	Mitigation
Radar becomes stale	Quarterly review cadence, ownership per quadrant
Too many proposals	Proposal limits per quarter, required sponsor
Gaming the voting system	Weighted votes by expertise, reviewer oversight
Visualization performance	Pagination, quadrant-based lazy loading
Adoption resistance	Start read-only, gradually enable contributions

Open Questions

1. Should roadmaps support cross-roadmap dependencies?
2. What retention policy for historical radar snapshots?
3. Integration priority: ADRs, wikis, or project management tools?
4. Should we support custom quadrant labels or enforce standards?
5. How to handle technologies that span multiple quadrants?

Related Principles

• G1: Single Source of Truth - Centralized technology decision registry
• G2: Version-Controlled Documentation - Tech decisions in version control

Related: Agent-Friendly Knowledge Base | Back: Proposals Overview

References

• ThoughtWorks Technology Radar - Original tech radar concept
• Zalando Tech Radar - Open source radar implementation
• Backstage Tech Radar Plugin - Spotify's developer portal radar
• AOE Technology Radar - Another radar implementation example