Platform Evolution
Assessment run-2026-07-27-1 · 213 of 213 repos assessed
Repos / phenix-connectionbroker-api

phenix-connectionbroker-api

Skeleton .NET 6 web API intended to expose ConnectionBroker endpoint lookups to Angular frontends, currently a stub returning hardcoded placeholder URLs.

54 · ambermediumlooseAWSZDD: not applicableapidormant

Health score

54

0 to 100 across seven weighted factors; nothing is hidden. Green is 75 and above, amber 50 to 74, red below 50. How scoring works.

Runtime currency / 25
4
End-of-life runtime outside .NET Framework
Legacy transport / 15
15
No legacy WCF or SOAP surface
Test posture / 15
0
No tests
Security hygiene / 15
15
No credentials found in source
Dangerous coupling / 15
15
No dangerous coupling detected
Activity / 10
0
Dormant: no meaningful change for two years or more while still deployed
Deployment hygiene / 5
5
CI in place
Health over time
2026-07-27 (run-2026-07-27-1): 54
Baseline 54 recorded 2026-07-27. The trend fills in with each monthly assessment run.

Facts

Languagescsharp
FrameworksASP.NET Core 6
Runtimes.NET 6
Tests / CInone / CI in place
Last commit2025-05-20
OwnerOwner unknown (mapping to be curated)
DomainPlatform services (system generated; curate in repo-owners.json to override)
Product areaPhenix
HostedAWS Deployed to AWS
  • build "phenix-connectionbroker-api" (azure-pipelines.yml): AWS signal "useTFVarsDeployment: true"
Releases0 release pipeline(s):
Integrationrest
SourceOpen in Azure DevOps

Risk flags

Each flag links to its glossary definition.

Dependencies in context

Laying out the graph…
greenamberreddata store (square, dashed link)Node size follows fan-in. Click any node to open it.

Entanglement

loose No binding mechanisms apply: this system needs no untangling work.

    Depends on / used by

    Depends on (1)
    tc-connectionbroker
    Used by (0)
    No internal dependents.

    Migration playbooks

    Generated from this repo's assessment data: what is feasible, what blocks it, and the steps in order. Ratings: green means actionable now, amber means sequence other work first, red means blocked, grey means not applicable.

    ZDD adoption

    Not applicable

    Not a deployed service (libraries, database definitions, desktop apps) or a retirement candidate not worth the investment. Retirement or consolidation candidate; do not invest in ZDD adoption.

    SQL Server exit

    Not applicable

    No SQL Server dependency is recorded for this repo. Nothing to migrate.

    Containerisation

    Retire instead

    This repo is a retirement or consolidation candidate; containerising it would be investment in something we intend to switch off.

    Recommended actions

    Review phenix-connectionbroker-api for retirement

    Dormant (last commit 2025-05-20) yet still release-linked, and nothing depends on it. Confirm remaining use, then retire and disarm its pipeline.

    Impact: Shrinks the estate before the expensive work begins

    proposed

    Assessment notes

    phenix-connectionbroker-api

    Purpose

    Per the README, "a web API to return endpoints of our APIs for consumption by Angular frontends" — i.e. an HTTP face over the ConnectionBroker endpoint registry so browser apps can resolve service URLs. In practice the single EndpointsController returns hardcoded placeholder values (google.com, bbc.co.uk, and an INCONTAINER-dependent dummy), so the repo is a deployed skeleton rather than a finished service.

    Tech stack

    One Phenix.ConnectionBroker.Api project on .NET 6 (ASP.NET Core minimal hosting, nullable/implicit usings). Three NuGet references: Swashbuckle, TC.ConnectionBroker.Api 1.7.3 and TC.Diagnostics.HealthChecks.AspNetCoreExtensions (TC health-check endpoint mapping). No data access, no auth wiring, default appsettings.json only.

    Deployment

    Included via build->yaml-deploy with 0 classic releases: build pipeline phenix-connectionbroker-api from the in-repo azure-pipelines.yml, using the shared InternalOSS/azure-pipelines-templates ci.yml with containerAfterBuild: true and useTFVarsDeployment: true — i.e. built into a container in the phenix namespace and deployed to AWS (eu-west-1, functional area phenix). No Dockerfile or Terraform in-repo; all of that comes from the shared templates.

    Dependencies

    Internal: TC.ConnectionBroker.Api (tc-connectionbroker) — although the package is referenced, the stub controller does not yet call into it. External: none.

    Data stores

    None. The eventual endpoint data would come from the ConnectionBroker configuration, but nothing is wired up.

    Integration points

    Inbound REST (GET /Endpoints, GET /Endpoint/{SystemName}) with Swagger in development and TC health checks. No outbound calls at present.

    Code health

    Minimal: a single controller with hardcoded responses, no test projects, a two-line README ending in "TODO", and no commits since 2025-05-20 (over a year dormant). CI exists and produces a deployable container.

    Modernisation risks

    Medium. It runs on .NET 6, which is past end-of-support, has no tests, and appears to be an abandoned prototype that nonetheless has a live containerised deployment path. The pragmatic question is whether the endpoint-resolution capability is still wanted: if yes, it needs finishing (real ConnectionBroker integration, .NET 8+, tests); if not, the pipeline and deployment should be retired rather than left serving placeholder URLs.

    Data store follow-up (2026-07-28)

    Follow-up scan of project files, configuration and the central Terraform repos confirmed the empty data_stores list is correct. The broker itself is stateless: it hands out connections but holds none of its own.