This section is the decision log of KBP. Significant architecture decisions are recorded as architecture decision records (ADRs): one page per decision in this folder, following the MADR structure with a status, a date, the deciders, and the options that were weighed. A decision is never edited into something else; when it changes, a new ADR supersedes the old one and both record the link.
Older decisions were only described inline in the section where they apply. They are listed in Decisions described in other sections until they are migrated to ADRs.
| ID | Decision | Status | Date | Tags |
|---|---|---|---|---|
| 9.5 | Replace the deprecated Zaehldaten service with the Commodity Layer for meter data | accepted | 2026-09-30 | integration commodity-layer enwicore zaehldaten |
| 9.4 | Pass the MXO customer profile through untyped and project only the fields KBP uses | accepted | 2026-09-30 | integration mxo comtrol |
| 9.3 | Keep manual monitoring instead of adopting Azure SRE Agent | proposed | 2026-09-11 | operations monitoring cost tooling ai |
| 9.2 | Automate dependency update proposals with Renovate | rejected | 2026-09-25 | dependencies security tooling ci |
| 9.1 | Secure public access with EnBW IDM Keycloak as identity provider | accepted | unknown (before 2026-08-17) | security authentication identity |
No decisions with this status.
On the published site the log is generated from the metadata of the ADR pages and can be filtered by status. In the wiki the ADR pages are the sub-pages of this page.
Statuses are proposed, accepted, rejected, deprecated, and superseded. Their meaning,
the file and metadata conventions, and the template are in the
ADR guide.
| Decision | Summary | Where it is documented |
|---|---|---|
| Authentication and authorization | Centralized EnBW Identity & Access Management (Keycloak identity provider, roles synchronized from Savvy) secures the publicly reachable application. | ADR 9.1, Authentication concept |
| Feature-based runtime access management | Access is declared as a hierarchy in features.json and composed per request from role, tenant, context, and environment handlers, rather than from authorization attributes spread across controllers. |
Solution Strategy: Runtime Access Management |
| Clean Architecture layering | The KBP WebApp is decomposed into presentation, application, domain/core, and infrastructure layers with inward-pointing dependencies, verified by ArchUnitNET fitness functions. | Building Block View, KBP Clean Architecture |
| ComV3 commodity services | Order capture and tariff change use the ComV3 com-service (offers, rulesets) and com-order-service (order booking); the predecessor ComV2 is no longer used. |
Runtime View |
| Azure Cloud hosting | The application and all infrastructure run in the Azure Cloud (App Service, Application Insights, Bicep IaC). | Architecture Constraints, Solution Strategy |
| Microfrontend evolution (direction, not yet decided) | Intended move from the current monolith to a shell application hosting domain-team microfrontends with separated APIs, subject to priorities and business constraints. | Solution Strategy: Architecture Evolution, Migration plan |
New significant decisions are recorded as ADRs in this folder, not as rows in this table.