Skip to main content

ADR-004: Data Services Portfolio & Naming Standards

Purpose: For platform engineers and architects, explains the data services portfolio strategy and naming standards for openCenter managed service blueprints.

Status​

Accepted

Context​

openCenter is building a narrow, operator-backed data services portfolio around its strengths: GitOps lifecycle management, opinionated blueprints, security hardening, air-gap packaging, and multi-cloud portability. The platform needs consistent naming standards and a clear sequencing strategy.

Decision​

Portfolio Sequencing​

QuarterService
Q1GA Managed Kafka (Strimzi-based)
Q2Preview Managed PostgreSQL (Zalando operator)
Q3GA Managed PostgreSQL
Q4GA Schema Registry / Event Governance add-on
Q5GA narrow CDC add-on (Debezium, PostgreSQL-first)

Naming Standards​

Data service blueprints follow the pattern: opencenter-<service>-<variant>

  • opencenter-kafka-standard — 3-broker HA production topology
  • opencenter-kafka-dev — single-broker development topology
  • opencenter-postgres-standard — 3-instance HA with streaming replication
  • opencenter-postgres-dev — single-instance development

Why Kafka First​

Kafka maps cleanly to an opinionated blueprint: declarative operator lifecycle (Strimzi), standardized topology, strong observability needs, and repeatable deployment patterns. The support boundary is easier to define early — openCenter manages platformed Kafka, not customer data architecture.

PostgreSQL is a strong second service but triggers more workload-specific expectations around HA semantics, backup/RPO, restore testing, and DBA tasks.

Explicitly Deferred​

  • Redis/cache services
  • Stream processing platforms
  • Object storage / data lake infrastructure
  • Generic workflow/integration platforms

These either require bespoke connector work, heavy DBA labor, or infrastructure-specific tuning that conflicts with openCenter's blueprint-led model.

Consequences​

Positive:

  • Predictable delivery with clear support ownership
  • Repeatable blueprint business with attachable day-2 managed services
  • Regulated-environment viability (air-gap, TLS, audit)

Trade-offs:

  • Narrow portfolio may not satisfy customers wanting a broad DBaaS catalog
  • Kafka operational complexity requires qualified storage profiles and runbooks before GA