Skip to content

ADR-009: Reuse call-center KPI patterns with responsive refinements

Note: This ADR was originally numbered ADR-001 but was renumbered to ADR-009 during the 2026-01-28 namespace consolidation to resolve collision with ADR-001-cost-metric-selection.md

Status: Approved Date: 2026-01-28 Deciders: @cloud-architect, @product-owner, HITL/Manager

Context

The ITSM demo overhaul requires KPI cards with click-to-filter functionality and responsive design across 25%-200% zoom levels. We have three existing dashboards with proven patterns:

  • call-center (1034 LOC): KPI cards with kpi_card_reference, @capture decorator pattern, responsive grids
  • bi-dashboard (302 LOC): Multi-page navigation, KPI click triggers control updates (va.set_control)
  • kpi-dashboard (263 LOC): Tabbed content containers, AgGrid pagination

The question is whether to build from scratch or reuse existing components.

Decision

Extract and adapt call-center patterns with responsive refinements from bi-dashboard.

Specifically: 1. KPI Cards: Reuse call-center/app.py:48-97 kpi_card_reference pattern 2. Tabs: Reuse call-center/custom_components.py:74-86 make_tabs_with_title 3. Grid Layout: Reuse call-center/app.py:101-133 Grid with min_row_height 4. Click Actions: Adopt bi-dashboard/app.py:44-60 vm.Action pattern 5. Table Pagination: Adopt kpi-dashboard/app.py:231 dashGridOptions pattern

Consequences

Positive

  • 70% code reuse: ~500 LOC reusable from 700 LOC total implementation
  • Battle-tested patterns: call-center has 1034 LOC validated in production-like environment
  • Consistent UX: All dashboards share common interaction patterns
  • Faster implementation: 2-3 hours vs 8-10 hours from scratch
  • Lower maintenance burden: Fixes to shared patterns benefit all dashboards

Negative

  • Tight coupling to Vizro 0.4.0+ API: kpi_card_reference requires Vizro >=0.4.0
  • CSS not DRY: Responsive zoom CSS duplicated across call-center and ITSM
  • Learning curve: Developers need to understand Vizro's @capture decorator model

Risks

  • Risk 1 (Vizro API changes): Probability LOW, Impact MEDIUM
  • Mitigation: Pin vizro==0.4.0 in pyproject.toml, add snapshot tests to detect API drift

Alternatives Considered

  1. Build from scratch: Rejected because it duplicates proven patterns and increases development time by 300%
  2. Use React + custom components: Rejected because Vizro is already adopted enterprise-wide
  3. Fork call-center as template: Rejected because unnecessary divergence and merge conflicts

References

Evidence

  • Architecture diagram: N/A (component composition, not new architecture)
  • Code reuse analysis: tmp/cloud-infrastructure/coordination-logs/cloud-architect-2026-01-28.json
  • Reusable LOC estimate: 500 LOC / 700 LOC total = 71% reuse