backoffice
Multi-service finance back-office monorepo hosting the Accounts WCF/ASMX service, the Suppliers repository service, an Accounts GraphQL query API, and their three SQL databases.
Health score
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.
Facts
| Languages | csharp, sql |
| Frameworks | WCF, ASMX, HotChocolate 16, MassTransit (AmazonSQS), Autofac 9, MediatR 12.5 |
| Runtimes | .NET Framework 4.7.2, .NET 10, .NET Standard 2.0 |
| Tests / CI | good / CI in place |
| Last commit | 2026-07-23 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Payments and finance (system generated; curate in repo-owners.json to override) |
| Product area | Phenix |
| Hosted | On-prem Deployed to our own machines
|
| Releases | 9 release pipeline(s): \finance\backoffice\backoffice Accounts Archive Database CI; \finance\backoffice\backoffice Accounts Database CI; \finance\backoffice\backoffice Accounts Service CI; \finance\backoffice\backoffice Accounts Service Stealth; \finance\backoffice\backoffice Accounts graphql; \finance\backoffice\backoffice Suppliers Database CI; \finance\backoffice\backoffice Suppliers Service CI; \finance\backoffice\backoffice Suppliers Service Stealth; \finance\commission\backoffice Accounts graphql - Stealth |
| Integration | wcf, soap, graphql, masstransit, rest |
| Source | Open in Azure DevOps |
Risk flags
Each flag links to its glossary definition.
Dependencies in context
Entanglement
kernel Bound into the core by 2 mechanism(s).
- Pinning dependency: application-framework
- Speaks WCF (host)
Detaches when its pinning dependencies are cut or multi-targeted (application-framework); and when its WCF surface gains a modern interface or its WCF calls move to one.
Depends on / used by
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
No chance (frozen core)The deliberately frozen legacy core. Policy, not tooling: minimal change flows through these systems, on a slow scheduled cadence with coordinated maintenance windows. Named in the two-speed strategy as frozen legacy core: protect the core, release the rest. Changes here go through the slow scheduled cadence and coordinated maintenance windows.
- 18 system(s) depend on this repo; during a rolling deploy they will talk to old and new versions at once, so responses must stay compatible
- Serialized state or messages in flight (Redis or queues): new code must deserialize objects written by the previous version
SQL Server exit
Blocked by a shared databasesqlserver:Accounts is shared, so this system cannot change engine on its own: every sharer moves in convoy. Either agree the move with all sharers as one programme, or first split this system's data out behind an owned API, then follow the steps below.
- Inventory the schema and query surface of sqlserver:Accounts, sqlserver:Suppliers, sqlserver:AccountsArchive: tables, stored procedures, triggers, cross-database joins and anything else engine-specific.
- Confirm the target: PostgreSQL (relational model; keep transactions and joins, swap the engine).
- Replatform to modern .NET first (see the recommended actions): current PostgreSQL and MongoDB drivers and EF Core providers target modern .NET, and doing one risky change at a time is cheaper than doing two.
- Data access is not through an ORM, so port the SQL by hand: translate T-SQL constructs, replace stored procedures with application code or target-native equivalents, and add integration tests around the queries that matter first.
- Stand up the target alongside SQL Server, backfill with an ETL pass (pgloader or an export/import job), then dual-write or replicate until parity is proven.
- Move reads to the target, watch correctness and latency, then cut writes over and keep SQL Server read-only until confidence is earned.
- Decommission the SQL Server database and remove the connection strings and firewall paths that pointed at it.
Containerisation
Feasible after replatformingAppropriate eventually, but not from here: the legacy runtime and the hosted WCF surface both have to go first, and that work is already in this repo's recommended actions.
- .NET Framework only runs on Windows; practical (Linux) containers need modern .NET
- Hosts WCF or SOAP endpoints, which have no home on modern .NET; consumers need a modern interface first
- Replatform to modern .NET first (see the recommended actions), replacing the hosted WCF/SOAP surface with REST, gRPC or messaging so consumers can follow. Containerising then becomes routine.
- Add a Dockerfile and make the app read all configuration from environment variables and the secrets manager, never from machine-local files.
- Log to stdout and expose a health check endpoint so ECS can supervise it.
- Adopt the shared ci.yml pipeline template with the container parameters (awsRegion, containerAfterBuild, ecsTerraformRepo), which is exactly how the estate's existing AWS services deploy.
- Define the service in the Terraform repo, deploy to a non-production environment, then shift traffic and disarm the deployment-group release pipeline.
Recommended actions
Replatform backoffice to modern .NET
Runs on .NET Framework 4.7.2, .NET 10, .NET Standard 2.0, out of mainstream support. Blocked until stage 2 cuts: application-framework.
Impact: Unblocks 18 dependent system(s)
proposedAssessment notes
backoffice
Purpose
Core finance back-office monorepo with three solutions: Accounts (main back-office logic — ledgers, commission, automatch, receivable/payable — plus the TC.Phenix.Services.Client package), Suppliers (repository service for supplier data, fronted by Accounts), and AccountsGraphQL (HotChocolate query layer over Accounts for front-end apps). The README notes the solutions share many projects and are tightly coupled.
Tech stack
Mixed-era C#: the Accounts and Suppliers hosts are .NET Framework 4.7.2 WCF (.svc) and ASMX web services (AccountsPayableService.asmx, BookingServiceFacade.asmx); most libraries multi-target netstandard2.0/net472/net10.0; the GraphQL API runs HotChocolate 16 on .NET 10 with Autofac and MediatR. Messaging via MassTransit over Amazon SQS (Phenix_BackofficeAccountsMasstransit). Database projects use Create/Change dbdeploy-style SQL scripts.
Deployment
Largest assigned entry: 9 release pipelines under \finance\backoffice covering Accounts Service (+Stealth), Suppliers Service (+Stealth), Accounts GraphQL (+Stealth), and Accounts / Accounts Archive / Suppliers databases; 6 YAML build pipelines in-repo (build-accounts.yml, build-suppliers.yml, build-graphql.yml, database and library builds) using shared azure-pipelines-templates.
Dependencies
Internal (via TC NuGet packages): application-framework (TC.Phenix.ApplicationFramework), tc-connectionbroker, tc-exceptions, tax-service (TC.Phenix.Tax.Api.Client/ServiceContract), service-fee-api (TC.ServiceFee.Api.BackOfficeClient), backoffice-documentation-booking (TC.Documentation.Booking.Contract), card-payments (TC.CardPayments.ServiceBus.Events handler endpoint), custom-data-fields-api (TC.CustomDataFields.API.Client). Also consumes TC.Cache, Cognito auth client, contact-centre and customer-portal contracts. External: New Relic metrics adapter, AWS SQS and Cognito.
Data stores
Three owned SQL Server databases with script-based deployment: Accounts, Suppliers, AccountsArchive. GraphQL logs to MongoDB (bookingGraphQL_logs); Redis used via TC.Cache/ConnectionBroker for caching.
Integration points
Inbound: WCF wsHttp/basicHttp endpoints (Phenix, CustomerPortal bindings), legacy ASMX SOAP services, GraphQL over HTTP (/api/accounts-graphql/graphql). Async: MassTransit events over Amazon SQS, including card-payments service-bus events. Outbound: REST/WCF clients to tax, service-fee, documentation, custom-data-fields and supplier services.
Code health
Good test coverage in structure: ~17 test projects including SpecFlow ledger tests, MassTransit event tests, GraphQL integration tests and benchmarks, with generated SpecFlow documentation. Very active — last commit 2026-07-23; docs folder covers GraphQL, automatch and commission.
Modernisation risks
The Accounts/Suppliers hosts remain on .NET Framework 4.7.2 WCF/ASMX with XML config transforms, while libraries already multi-target .NET 10 — the host migration (CoreWCF/gRPC, prepared by application-framework's protobuf work) is the critical path. Acknowledged tight coupling across the three solutions and shared projects makes independent deployment risky, and the Accounts database is a de-facto integration point for many downstream backoffice-* estate services. High priority given its central finance role and 9 production pipelines.