This section summarises the fundamental decisions and the approaches that realise the quality goals. Each subsection below states which goal its choices serve.
| Quality goal | Solution approach | Link to details |
|---|---|---|
| Security | Sign-in through the central EnBW IAM, with roles from Savvy. The feature model decides per request, in the backend, which features the agent’s role, tenant, and context allow. Callers are verified with the telephone PIN before customer data is shown. Production App Services are private and reachable only through the Front Door WAF. Secrets are in Key Vault, accessed with managed identities. Dependencies are scanned by NexusIQ and SonarQube. | ADR 9.1, Authentication, Runtime Access Management (below), Deployment View |
| Availability | Managed Azure App Service, scaling out to several instances in production. Releases are deployed to a staging slot and swapped into production without downtime. Application Insights availability tests and Azure Monitor alerts detect outages. | Hosting strategy, Deployment View, ADR 9.3 |
| Performance | Backend query results that change rarely are cached in Redis, so repeated views do not call the backend again. Page load times are measured per page in production. | User interaction tracking |
| Interoperability / Fault tolerance | Each backend is reached through its own typed client in the infrastructure layer, which translates transport and service errors at the boundary. HTTP clients use resilience handlers for transient failures. A system status probe shows agents which backend systems are down. | Error Handling, Building Block View |
| Usability | All tenants and feature areas share one design language: the same controls, icons, and navigation patterns. Agents enter KBP per business case from ASI with customer, tenant, and context already set. The UI offers only features the feature model reports as visible and only the steps valid in the backend process state (e.g. ZAuV). Addresses, payment data, and contact data are validated before submission. A UX designer is being recruited to design and review agent journeys, using the tracked interactions as input. | Stakeholders, Runtime Access Management (below), Requirements overview |
KBP is an ASP.NET Core MVC application with an injected SPA as the main source for the presentation layer, inspired by the Vite.AspNetCore library.
Rationale: Mainstream, long-term-supported stacks (current .NET, Vue) let the partner developers work without special onboarding and keep the application patchable (Security).
| Usage | Technology |
|---|---|
| Backend Dev | ASP.NET Core MVC application with latest stable .Net version |
| Frontend Dev Core | latest Vue / Typescript / Pinia |
| Frontend Dev Ui Components | latest Vuetify / Material Design Icons |
| KBP Backend Mocking | JSONServer/Node ExpressServer |
| Approval tests | Playwright |
| Unit tests | xunit |
| Logging/Metrics | Application Insights |
| Documentation Arch/Detailed Design | Azure DevOps Code Wiki, published as a Hugo static site; Mermaid for the inline sequence diagrams, Archify JSON sources for the context, deployment, workflow and sequence diagrams (rendered to PNG and interactive HTML) |
Rationale: Azure is a constraint. Within it, managed App Service with staging-slot swaps, scale-out, and Application Insights availability tests and alerts is the most direct way to meet the Availability goal without running infrastructure ourselves. Bicep makes every environment reproducible, so a broken resource can be restored from the repository.
Rationale: NexusIQ, the SonarQube gate on new code, and least-privilege repository access address supply-chain and access Security.
Access is governed by a declarative, composable feature model rather than by authorization
attributes scattered across controllers. Features are declared as a hierarchy in features.json;
each feature carries one or more visibility handlers that are evaluated per request against
the current agent, tenant, process context, and environment. The composed decision controls the
frontend UI; the backend route is gated by the feature’s Azure AD policy handlers only. Tenant,
context and environment restrictions hide the UI but do not block the route (see
Feature Access Management).
Roles come from EnBW IDM/Entra groups mapped to authorization policies
(for example UserKundenberaterportalPolicy, AdminForderungsmanagementPolicy); see
Authentication.
Access is contextual and composable, not just role-based: the same feature can be shown only in a given tenant (EnBW, Yello), only in a given process context (e.g. Auftragserfassung, Emobility), only in certain environments, or hidden entirely — and because features are hierarchical, disabling a parent disables its whole subtree. The frontend learns which features are visible from the initial application data, so the UI never offers an action the backend would reject.
Standard ASP.NET Core authorization uses attributes such as [Authorize(Roles = "...")] or
[Authorize(Policy = "...")] on controllers and actions. It is important to be precise about what
this feature model does and does not add over that baseline:
AuthorizationRequirement/AuthorizationHandler and policies can check tenant, process
context, environment, or rollout state just as well. Composition, tenant-specific access, and
staged rollout are therefore not capabilities that only this mechanism can provide.features.json) as a readable hierarchy, rather than
being spread across attributes on many controllers and actions. This makes the overall access
model reviewable at a glance and keeps a single source that both the backend routing and the
frontend visibility consume.In short, the choice is primarily about where access is described and how it is kept consistent, not about being able to express rules that attributes cannot. The trade-off is a custom mechanism to maintain and learn; that cost is accepted for the single-source overview and the shared backend/frontend decision. Details of the mechanism and its handlers are in the Engineering Guardrails feature-management section.
| Quality goal | Scenario | Solution approach | Link to details |
|---|---|---|---|
| Security | An agent must not reach a feature their role, tenant, process context, or environment does not allow, even by calling the backend directly. | The feature’s Azure AD policy is evaluated per request and gates the backend route. Tenant, context and environment restrictions are enforced only in the UI and must be checked in the backend where they are security-relevant. | Feature Access Management |
| User Error Protection | The UI must not offer actions the backend will reject. | Backend routing and frontend visibility consume the same feature decisions, so the UI renders only features reported visible in the initial application data. | Building Block View |
Today KBP is a monolith: a single ASP.NET Core MVC application with an injected Vue frontend and one shared backend.
The intended direction is to evolve KBP into a shell (container) application that hosts microfrontends owned by the domain teams, moving to a vertically sliced architecture:
The motivation is team autonomy and independent delivery: domain teams have started to form, which is the organizational precondition for vertical slices. The detailed plan is maintained separately in the KBP Microfrontend Architecture Migration Plan.
Status: This is a target direction, not a committed decision. Whether and when it happens depends on priorities and business constraints, so the current monolithic architecture remains authoritative for all sections of this document. This note exists so the intent is visible; it does not describe the system as built. Related risk: Risks and Technical Debt.