Parent folderOpen Confluence

RWS Architecture article

Data Science and AI

Data Science and AI is the product-neutral architecture building block for data science, model development, and AI workload enablement. It states what DC 3.0 needs from this capabi

  1. Typeabb
  2. Statuscandidate
  3. Domainai
On this page
  1. ABB Data Science and AI
  2. Summary
  3. Capabilities
  4. Constraints
  5. Service Description
  6. Roadmaps
  7. Landing Zones
  8. Interfaces
  9. Dependencies
  10. EIRA Alignment
  11. Available SBB's

ABB Data Science and AI

Summary

Data Science and AI is the product-neutral architecture building block for data science, model development, and AI workload enablement. It states what DC 3.0 needs from this capability before a concrete SBB, product, or operating model is selected.

Capabilities

  • Provides data science, model development, and AI workload enablement.
  • Defines the functional, technical, security, and quality expectations that SBBs must satisfy.
  • Keeps service ownership, interfaces, and consumption boundaries visible before product selection.
  • Enables traceability from architecture intent to implementation, operational evidence, and consuming services.

Constraints

  • The resulting SBB must fit the platforms ownership model and document the support, lifecycle, and service-management boundary.
  • Security, privacy, logging, evidence, and compliance controls must be explicit enough to assess BIO2-aligned implementation where applicable.
  • AI workloads must follow data classification, access control, and platform isolation requirements.
  • GPU and accelerated capacity must be scheduled and governed as scarce shared resources.

Service Description

This ABB offers an AI platform service for notebooks, model training, model serving, and governed AI experimentation in DC 3.0. It is consumed by solution architects, platform teams, and service owners as the capability contract for selecting and shaping SBBs.

The service description remains implementation-neutral: product selection, hosting pattern, detailed runbooks, and service levels belong in the mapped SBB and related ADRs.

Roadmaps

  • Baseline: confirm scope, service ownership, constraints, and acceptance criteria for Data Science and AI.
  • MVP: validate the mapped SBB implementation and record the selected support and lifecycle model.
  • Next: add measurable service levels, evidence requirements, and roadmap dependencies once the SBB is selected.

Landing Zones

  • Private cloud landing zone in ODC-Amsterdam, following the RWS ICT Strategy 2025-2030 private-cloud direction.
  • Government cloud or external cloud landing zones only when the SBB documents the required control set, connectivity model, and data classification fit.

Interfaces

  • Notebook, model-serving, and pipeline APIs.
  • Container, storage, and identity interfaces.
  • Model registry and observability interfaces.

Dependencies

  • Depends on clusters-as-a-service for a supporting capability or integration boundary.
  • Depends on block-file-s3-storage for a supporting capability or integration boundary.
  • Depends on federated-authentication for a supporting capability or integration boundary.
  • Implemented by red-hat-openshift-ai as currently mapped SBB traceability.
  • Consuming ABB and SBB dependencies must be recorded as links when solution design identifies concrete upstream or downstream use.

EIRA Alignment

Available SBB's

  • red-hat-openshift-ai - Red Hat OpenShift AI is a candidate solution building block for the translated DC 3.0 ABB model. It remains candidate until the responsible architects confirm service ownership, support model, and acceptance criteria.