The Problem
A next-generation sequencing platform entered development with critical architecture decisions already embedded in the design. But the system had been shaped in pieces. Assay, automation, software, and data teams had each advanced their components without a shared definition of how the full sample-to-answer workflow would behave as an integrated system.
Leadership and team transitions had compounded the problem. The original rationale behind key design choices had not been preserved, so the team was building on architectural assumptions that no one could fully trace back to user needs or operational requirements.
The architectural ambiguity was creating concrete risks across the system:
- No shared definition of the sample-to-answer workflow connecting lab, software, automation, and data behavior
- Component teams optimizing their own layers without visibility into cross-system dependencies
- Run planning logic that exposed unnecessary complexity to the operator instead of resolving it through defaults and case logic
- Metadata field naming that was vague and inconsistent, creating risk for data variability and audit traceability
- LIMS integration treated as a given without real mapping of data handoffs, source-of-truth ownership, or key definitions
- Unclear boundaries between what the architecture needed at launch versus what belonged in future expansion
The platform needed an architecture defined from the workflow out, not assembled from components in. As the design progressed, each layer was accumulating complexity that would become harder to build, harder to integrate, harder to validate, and harder for customers to use.
System Architecture Approach
Led end-to-end architecture definition across assay development, automation, software, bioinformatics, data systems, and operational workflows. The work focused on defining the integrated system architecture from the user workflow outward, connecting what happens in the lab to what the software needs to do, what the data systems need to support, and what the operator needs to see and control.
"The platform needed an architecture defined from the workflow out, not assembled from components in."
- Mapped the full sample-to-answer workflow and defined architecture boundaries, interfaces, and dependencies across all layers
- Restructured run planning to move complexity out of the operator's hands, defining background defaults and case logic for a simplified interaction
- Standardized metadata field naming and definitions to eliminate ambiguity, reduce data variability, and support audit traceability
- Defined source-of-truth tables and data keys for cross-system mapping, replacing assumptions with explicit ownership of where each data element lived and how it moved
- Mapped actual LIMS integration requirements, replacing hand-waved assumptions with defined data handoffs, field mappings, and system boundaries
- Established metadata and run-planning strategy to support scalable workflow execution across instruments and configurations
- Separated launch-critical architecture from future-state functionality to clarify build scope and reduce integration risk
Outcomes
- Established a shared end-to-end system architecture across lab, automation, software, and data layers
- Defined 16 launch-critical features grounded in user workflow, assay failure mitigation, and operational requirements
- Simplified the operator experience by restructuring run planning around background logic and sensible defaults
- Resolved metadata naming and definition gaps that were creating data variability and audit risk
- Defined explicit data mappings, source-of-truth ownership, and integration boundaries for LIMS and cross-system handoffs
- Reduced downstream integration and validation risk by clarifying layer dependencies before build
- Secured executive phase-gate approval to proceed
Why This Worked
The work succeeded because the platform was treated as an integrated operational system, not a collection of independently designed components.
Rather than letting each team continue to optimize their own layer, the engagement established a shared architectural definition that connected what happens at the bench to what the software controls, what the data systems capture, and what the operator needs to act on. That end-to-end view exposed where complexity was accumulating without justification: run planning that burdened the user with decisions the system should have handled, metadata definitions that would have created downstream data quality problems, and integration points that had been assumed rather than designed.
The team did not need to replicate the competitor's architecture. It needed a cleaner one: a system designed from the workflow out, built to deliver the required performance with less integration burden and less customer friction.