ADR-001: Require a Middleware Layer Between Signals and Roche Systems

Context

Signals ELN is a SaaS platform operated by Revvity outside the Roche Corporate Network (RCN). Scientists using Signals need to access reference data from internal Roche systems (compound registries, sample management, analytical data stores) and, in some cases, write data back.

The question is whether Signals can connect directly to internal Roche systems or whether a dedicated middleware layer is required.

Decision

xRED ELN integrations between Signals ELN and internal Roche systems pass through a dedicated middleware layer hosted on Minerva (AWS EKS within the RCN). While direct connections are not technically impossible, they would face significant friction from the LEM platform team’s governance process — all programmatic access to Signals is expected to be routed through the DataRiver facade on MuleSoft, and bypassing this is unlikely to pass review.

Rationale

Network boundary

Internal Roche systems sit within the RCN and are not directly accessible from Revvity’s infrastructure. A secure, externally accessible entry point is required.

API governance

Per the LEM team’s integration rules, all programmatic access to and from the Signals platform within the RDT DIA R&D domain must be routed through the DataRiver Signals Facade on MuleSoft. DataRiver provides visibility into API usage, enforces rate limiting, and ensures the tenant-wide API quota (1,000 calls/minute) is managed across all consumers.

Authentication constraints

Signals supports only a single authentication header per outbound call for External Data integrations (Lists, Tables, Chemical Sources). This header is used for Basic Auth, with a client certificate and IP whitelisting. Internal systems often require different auth models (OAuth, API keys) that cannot be expressed in a single header.

Data transformation

Signals expects data in specific JSON formats with pagination support. Internal Roche systems rarely expose data in these formats. An adapter layer is needed to bridge the contract gap.

Operational independence

By decoupling Signals from internal systems through middleware, each side can evolve independently. Changes to an internal registry’s API do not require reconfiguration of Signals, and vice versa.

Alternatives Considered

Direct integration (Signals → internal systems)

Rejected. Not feasible due to the RCN network boundary, authentication constraints, and API governance rules. Would also create tight coupling between Signals configuration and internal API contracts.

VPN tunnel from Revvity to RCN

Rejected. Would bypass API governance, provide no rate limiting or usage visibility, and create a security exposure. Does not solve the data transformation or auth translation requirements.

Consequences

• All integration development requires deploying to the Minerva platform
• Additional operational complexity (Kubernetes, ArgoCD, Vault, Gravitee)
• Latency increase from additional network hops (Signals → MuleSoft → Gravitee → adapter)
• Central visibility into all Signals integration traffic via MuleSoft and Gravitee
• Internal systems are shielded from direct external access
• Integration contracts can evolve independently on both sides