Friendly forms, not spreadsheets
Server-rendered forms with validation for every catalog — create, edit, delete — so editors never hand-write YAML or touch a request ticket.
Telops · Group IT · Product Pilot App · 2025
Product Pilot Back Office
The authoring app behind the marketplace. It is where product owners and service owners manage their catalogs — products, applications, services, SLAs, assignment groups, and their translations — in friendly, validated forms. Everything they save becomes a Git-versioned artifact; from there the pipeline does the rest: review, release, publish, and sync.
This deck is the app we are building. For where it sits in the wider system see Platform; for the content-as-code method it implements see Content.
What owners do here
The back-office workspace for catalog owners; the pipeline handles release and sync.
01 · What it is
A back office for product and service owners
Product Pilot is the provider-facing authoring tool of the Service Engineering Platform. Its customers are the product owners and service owners who own catalog content: they create and curate it here, everything they save becomes a versioned artifact of record, and the pipeline carries it through review, release, and delivery — translated — through one API.
Review before it ships
A product manager edits what they own; a catalog owner approves governed changes. Every change is checked, approved, released, then published.
One API for every surface
A language-aware read API serves pinned catalog versions to the IT Hub Portal and other consumers — no direct coupling to JSM, Assets, or Confluence.
Artifact of record: Git-versioned YAML/JSON is the single source of truth. The database is a disposable index, rebuilt at any time from the artifacts with
reindex --all.
02 · The app in use
What owners actually see
A look at the back office product owners and service owners work in day to day. Click any screen to enlarge; use the arrows or your keyboard to move between them.
03 · Domains
Six bounded contexts, each versioned independently
Product Pilot owns five catalogs plus a shared terminology foundation. Each is a bounded context with its own schema, Git-backed directory, and release history. Colour shows the upstream system of record each catalog is aligned to.
catalog app · aligned to CMDB / JSM Assets
productsFully defined & mastered here · variants, options, pricing, SKU · orderable
applicationsCatalog layer over CMDB-mastered app metadata · orderable access
operations app · aligned to JSM Ops
servicesDefined here · not orderable — a dependency of products & apps
slasSLA metadata · preset types by convention to start
assignment_groupsCatalog-layer basics · membership synced from JSM Ops
translations · cross-cutting (dual role)
translationsUI i18n (
common.*) and managed domain copy (<catalog>.*) behind one abstractionSource of truth vs. reference
Product Pilot masters catalog content — what IT offers, how it is structured, priced, displayed, and supported. It is not the source of truth for operational or identity data other systems own; it imports and layers on top.
products — define
applications — import + layer
services — define + publish
slas — define metadata
assignment_groups — import + sync
Owned by other systems
- Knowledge base articles & playbooks — JSM / Confluence (read & used for context).
- Service monitoring — JSM Ops.
- Hardware assets — Intune / CMDB.
Product Pilot shows their relationships but never masters them.
04 · App layout
A Django app with seven modules, split by system of record
Apps are divided by their upstream system of record rather than one-app-per-catalog, with a shared engine underneath and a dedicated app for the publish/sync workflow. Domain apps never import each other's models — cross-domain links are artifact keys resolved through service interfaces.
Shared engine
catalog_coreArtifact store · schema registry · Git service · index base · reindex pipeline · role resolution
translationsCross-cutting: UI i18n + managed domain-entity translations
authoring apps build on the engine
Authoring (own the create / edit / validate workflow)
catalogCMDB / JSM-Assets-aligned · products, applications
operationsJSM-Ops-aligned · services, slas, assignment_groups
changes flow into governance
Workflow & delivery
change_managementcheck → approve → release → publish → sync (+ intake, Phase 3) · reads catalog + operations via service interfaces
deliveryDRF interface mirroring app capabilities: read, search, filter, translate, and submit edits
ai_assistLLM-assisted authoring · views, no models · deferred Phase 4+
Who depends on whom
catalog_core— no internal deps.translations→catalog_core.catalog,operations→catalog_core,translations.change_management→catalog_core; readscatalog+operationsvia service interfaces.delivery→ all of the above through services; API adapter for catalog reads, search/filtering, translations, and edits.ai_assist→catalog_core, read-only (deferred).
Thin adapters, fat services
Business logic lives in <app>/services.py. Views, CLI commands, and API endpoints are adapters only: parse input → call a service → render output. No validation or persistence logic in the edges.
05 · Tech stack
Boring, proven, server-first
A pragmatic Django stack with a light, modern front end. No SPA, no bespoke infrastructure — server-rendered pages enhanced just enough to feel fast.
Django + DRF
- Django for views, forms, and admin.
- Django REST Framework for the app API: reads, search/filtering, translated content, and edits.
- Business logic in
services.py.
Git + index DB
- Git-versioned YAML/JSON = source of truth.
- SQLite by default; Postgres via
DATABASE_URL. - DB is a disposable index (
reindex --all).
Tailwind v4 + Alpine + Lucide
- Tailwind CSS v4 (CSS-first
@themetokens). - Alpine.js for light interactivity.
- Lucide icons; Axpo brand tokens.
Microsoft Entra ID
- Delegated Entra sign-in (MSAL).
- User email read into the session.
- Allowlist-first roles to start.
uv + Ruff + tests
uvfor dependency management.- Ruff for linting.
- Django test suite with realistic fakes.
Container + WhiteNoise
- Dev container for local work.
- WhiteNoise for static serving.
- Deployed via GitHub Actions to Azure.
06 · Key concepts
The principles we hold to
A handful of decisions shape every module. They keep the system simple to reason about, cheap to rebuild, and safe to integrate later.
Artifact of record
Git-versioned files are authoritative; the DB only mirrors them and can be dropped and rebuilt at will.
Thin adapters, fat services
All behaviour lives in services.py; views, CLI, and API just translate to and from it — and stay in parity.
No model imports across domains
Cross-domain links (a product's service_key) are artifact keys resolved through a service interface, never a direct import.
Inside-out, integrations last
The core data model and forms work with zero external dependencies; JSM/CMDB and Weblate are designed up front but wired later.
Keyed, translatable copy
Artifacts store keys, not localized text. A pluggable provider serves a local store now and Weblate later — no catalog-code change.
Two roles, allowlist-first
Product manager edits owned records; catalog owner approves. Roles resolve from an allowlist now, from CMDB/Entra groups later.
07 · Connections
How it relates to the rest of the platform
Product Pilot exposes the same catalog capabilities through the back-office UI and an API. The API fetches catalogs and content, supports search/filtering and translations, and accepts edits through the same services. It does not write directly to JSM, CMDB, or Confluence — approved changes move through Git, PRs, tests, and the deployment pipeline.
Interfaces to Product Pilot
IT Hub Portal · Axpo HubReads catalog versions and translated content; searches and filters through the API
Back Office UIProduct and service owners edit catalogs through forms
Product Pilot APIMirrors app capabilities: fetch, search, filter, translate, and submit edits
all go through shared services in
Product Pilot app core
Catalog services validate reads and edits, resolve translated content, and write versioned artifacts.
approved edits become
Git artifacts · PRs · CI/CD pipeline
Tests, approvals, staging, production release, and system write-back happen here.
pipeline updates and syncs
Systems of record & services
CMDB · JSM AssetsReceives released catalog records; remains source for imported operational metadata
JSM OpsReceives released service and assignment-group sync after pipeline approval
ConfluenceReceives released knowledge and reference-content updates from the pipeline
WeblateShared translation service (Phase 4+) behind the provider abstraction
Out of scope: a direct LeanIX connection. Application metadata is read through the CMDB (JSM Assets); any LeanIX path is worked out later.
08 · Build order
Build the core, defer the integrations
We ship a working, self-contained back office first, then layer on versioning/release, then external system sync, then the translation service and enrichment. Each phase's shape is designed up front so the core never paints us into a corner.
Local back office
- All catalogs modelled; real forms (new / edit / delete).
- JSON-Schema + service-layer validation.
- Local Git store in a dedicated content folder, created at setup.
- Keyed translations behind the provider (EN/DE).
- Local two-role approval workflow; notifications mocked.
Versioning & release
- Add a Git remote and per-catalog semver.
- DB formalised as a disposable index.
- Version-pinned delivery API goes live.
- Per-catalog changelog / history from Git.
External sync
- Read intake from CMDB (JSM Assets).
- Publish to JSM on catalog-version release.
- Sync JSM-Ops assignment groups.
- Ownership-driven roles; approvals in JSM.
Translation service & enrichment
- Swap the local store for Weblate (no code change).
- AI-assisted authoring & wizards.
- Bulk operations.
- Richer SLA metadata.
Two rules govern the order: inside-out — the data model, forms, validation, and tests come first and stand alone; and integrations last — JSM/CMDB and the translation service are deferred, their shape designed up front but their wiring done later.
Companion overviews
This deck focuses on the Product Pilot app. Two companions cover the wider picture.