< Back To Paradigm

Case Study: FERA

FERA (Front End Re-Architecture) was a major architectural initiative within the Paradigm surgical platform between v1.0 and v2.0.

Context

Between v1.0 and v2.0 of Paradigm, the system was already deployed in clinical environments. Stability was critical. At the same time, the existing front-end architecture limited our ability to safely evolve the product.

I led the FERA initiative to address foundational architectural limitations while the system remained active in the field and under regulatory oversight

The Problem

The v1.0 front-end had structural characteristics that increasingly constrained development:

  • Minimal automated test coverage, resulting in frequent regressions when code was modified.

  • Tight coupling between UI logic and hardware interfaces, requiring live hardware connections for development and testing.

  • Architectural decisions optimized for early iteration, but not long-term maintainability.

As a result, even small changes carried risk. Validation cycles were heavy, bug fixes were high-friction, and new feature development compounded technical debt.

At the same time, the system was deployed in clinical settings and subject to regulatory requirements. We could not afford instability, nor could we halt feature development for v2.0.

Constraints

FERA was not a greenfield rewrite.

  • The system was actively deployed in surgical environments.

  • Stability for intra-operative workflows could not be compromised.

  • Regulatory traceability and documentation had to remain intact.

  • v2.0 feature commitments still needed to be delivered on schedule.

  • Hardware integration requirements were fixed.

We needed architectural improvement without production disruption.

Strategy

Rather than pursuing a full rewrite, I structured FERA as a controlled, phased migration with explicit isolation and parallel delivery tracks.

The re-architecture was developed in a dedicated feature branch separate from the legacy code base. This prevented architectural contamination and minimized instability risk in production.

By isolating the new architecture:

  • The legacy branch continued supporting clinical deployments without disruption.

  • Stability fixes remained traceable and contained.

  • The new architecture could evolve deliberately without partially migrating abstractions into production.

  • Integration boundaries were explicit and controlled.

This separation allowed both systems to evolve safely until vertical slices were ready for integration.

Parallel Tracks

FERA proceeded along two coordinated efforts:

  1. Legacy Track
    Continued stabilizing and fixing defects in the v1.0 code base to support active clinical deployments.

  2. Re-architecture Track
    Designed and implemented a new front-end architecture to support long-term maintainability and safer iteration.

This ensured production stability while building the foundation for v2.0.

Architectural Changes

The new front-end architecture was intentionally structured around MVVM principles, clearly separating presentation, state management, and hardware-facing model logic.

Key changes included:

  • Introducing View-Model layers to decouple UI state from hardware interfaces.

  • Abstracting hardware-dependent models behind interfaces.

  • Enabling runtime configuration of Mock or Real model implementations.

  • Allowing mixed mock/real configurations to support targeted feature development and testing.

  • Establishing clearer separation of concerns to support incremental automation.

This architecture allowed the front-end to operate independently of physical hardware when needed, significantly improving development velocity and enabling safer experimentation. Real hardware integrations could still be exercised without modifying higher-level logic.

The goal was structural resilience and long-term sustainability.

Phased Migration via Vertical Slices

FERA was executed incrementally using vertical slices.

- Phase 1: Architectural Foundation

Defined the MVVM based architecture and abstraction boundaries.

- Phase 2: Initial Vertical Slice

Implemented a single end-to-end feature slice within the new architecture. This validated:

  • Architectural assumptions

  • Integration boundaries

  • Runtime performance

  • Mock vs real model switching

The slice coexisted with the legacy system without destabilizing deployments.

- Phase 3: Incremental Expansion

Additional vertical slices were introduced iteratively. Functionality was gradually migrated into the new architecture while:

  • Continuing bug fixes in the legacy system

  • Supporting active clinical deployments

  • Delivering new features required for v2.0

This avoided a disruptive cut-over and reduced migration risk.

Long-Term Impact

FERA reduced regression risk, improved development velocity, and established a sustainable architectural foundation for future releases.

The system transitioned from a tightly coupled, hardware-dependent front-end to a modular architecture capable of:

  • Isolated testing and simulation

  • Safer refactoring

  • Parallel feature development

  • Controlled integration into regulated releases

Most importantly, it enabled the product to evolve without compromising clinical reliability.

Lessons Learned

This effort reinforced that architecture is as much about sequencing and risk management as it is about structure. In regulated environments, evolution must be deliberate, isolated, and incremental. The most impactful change was not adopting MVVM, but creating clear boundaries that allowed the system to evolve safely while continuing to serve clinicians