← Back to portfolio
Assessed 2026-06-03

SLIMS

PathFlow · CSCoE / DDC / Assay Workflows
Lead
Malvin Leuenberger
SMEs
Igor Spiaczka Wojciech Kwiatkowski
Provider org
CSCoE / DDC / Assay Workflows

Overall coverage

Transitional
57% 90 / 140 points
Coverage = unweighted mean of the 10 dimension coverages (not points ÷ max)

Maturity distribution

Modern 5Transitional 3Tech Debt 2
Headline finding
The benchmark validates the stakeholder’s initial view that the vendor model is the primary bottleneck affecting the overall modernization score. For the Platform, Hosting, and Infrastructure dimension, improvement appears harder to assess and less directly actionable than other areas. The key recommendation is to prioritize the vendor model and clarify whether it limits modernization through constraints such as platform dependency, lack of flexibility, operational ownership boundaries, or limited ability to replace components. A useful follow-up question for this area is: Can individual components be swapped in or out without requiring significant changes to the overall system? If the answer is no, this would indicate a modernization concern around modularity and vendor/platform coupling, even if the underlying hosting and infrastructure practices are relatively mature.
Primary modernization lever: Platform / Hosting / Infrastructure

Coverage vs. portfolio

app vs. avg (dashed)

Score vs. gap by dimension

Prioritized remediation

Register the dataset in a searchable catalog or inventory, including clear metadata, ownership information, system purpose, interfaces, and lifecycle status.
FAIR & Discoverability Impact High Effort Medium
Define and formally document a named data owner or data steward who is accountable for data quality, access control, compliance, lifecycle management, and issue resolution.
FAIR & Discoverability Impact High Effort Medium
Ensure all stored data is encrypted at rest using approved encryption standards.
IAM, Privacy & Security Impact Medium Effort Low
For selected critical services and data define Recovery Time Objective (RTO) and Recovery Point Objective (RPO) targets.
Resilience & Recovery Impact Medium Effort Low

Per-question assessment

click a dimension to expand · colored answer chips
FAIR & Discoverability 2 gaps 75%
The dataset or system is findable in a searchable catalog or inventory (e.g., ).
Partial
A named data owner or steward is formally assigned and documented.
Partial
Access and usage conditions, including legal and compliance constraints, are documented and available to users.
Yes
What is the percentage of the data uses standardized terminologies such as RTiS.
50-90%
Data lineage is captured for key data flows and is maintained over time.
Automated
IAM, Privacy & Security 1 gap 83%
The system uses the approved corporate identity provider for user authentication (e.g., Roche SSO via PingFederate, OAuth 2.0, OpenID Connect).
Yes
Data is encrypted in transit.
Yes
Data is encrypted at rest.
No
Secrets are managed in an approved central vault (e.g., HashiCorp Vault or AWS Secrets Manager).
Yes
Access rights and permissions are reviewed and formally certified at defined intervals.
Yes
No shared or generic privileged accounts exist in the production environment.
Yes
Platform / Hosting / Infrastructure 2 gaps 0%
Infrastructure is provisioned declaratively using Infrastructure as Code.
No
The system uses approved shared internal platforms or Golden Paths, where applicable. (e.g., Minerva Application Blueprint)
No
Architecture & Interoperability 4 gaps 38%
Can we swap in and out components without modifying the system.
No
All application services are exposed through clear and defined interfaces.
Partial
APIs, events, and data contracts are documented and governed.
Partial
API lifecycle management is actively implemented using Gravitee.
Partial
Reliability 2 gaps 50%
All critical services have defined SLAs and SLOs.
Partial
Major incidents are followed by systematic postmortems, and resulting corrective actions are tracked to closure in the backlog.
Yes
SLIs are defined and calculated for all established SLAs and SLOs, and are visible to stakeholders and system owners.
No
Scalability & Performance 2 gaps 25%
The system supports automated vertical and horizontal scaling based on real-time demand, where applicable.
No
Load and performance testing are performed routinely and included in major release cycles.
Partial
Deployment Automation 1 gap 90%
Core workloads are supported by a complete CI/CD pipeline.
Yes
Builds, tests, and deployments are executed through fully automated processes.
Yes
Automated quality gates are enforced before production deployment. (e.g., SonarQube)
Yes
Production rollback or deployment occurs regularly and within the last 6 months.
Partial
Build artifacts and dependencies are managed in a traceable and controlled manner.
Yes
Observability 2 gaps 67%
All critical services generate standard telemetry, including logs, metrics, and traces.
Partial
Observability data is available through approved central monitoring and observability tools.
Yes
Incident analysis can be performed across upstream and downstream dependencies.
Partial
Resilience & Recovery 1 gap 50%
Critical services and data have defined Recovery Time Objective (RTO) and Recovery Point Objective (RPO) targets.
No
Backup, restore, and recovery procedures, including assigned roles and responsibilities, are documented and tested.
Yes
Cost Transparency & FinOps 0 gaps 92%
Cost visibility is available at component, system, product family, or domain level.
System
Cost is reviewed regularly together with usage and business value by the owning team.
Yes
Architectural decisions explicitly consider cost as a primary decision variable.
Yes