A Practical Path from Legacy Monolith to Composable Architecture

The Monolith is a Business Map, Not Only a Codebase

A monolith can be a sensible architecture when the business domain is compact, the team is small, the deployment model is simple, and the business changes in a coordinated way.

The difficulty usually appears later.

Over time, lending and banking platforms collect product variations, manual overrides, provider-specific rules, document logic, pricing exceptions, credit checks, valuation workflows, fraud integrations, servicing behaviour, operational queues, and reporting obligations.

Each addition makes sense when it is introduced. The combined effect, after years of delivery, is a platform where business capabilities are tangled through shared tables, hidden workflow states, reusable utility code, and assumptions made for specific integrations.

At that point, the monolith is hard to change because the business boundaries are unclear.

A change to onboarding touches credit decisioning. A change to decisioning changes document conditions. A change to servicing disrupts downstream reporting. A change to a third-party provider leaks into workflow logic because provider-specific statuses were never translated into an internal language.

The architectural problem is the loss of control over business meaning.

In many mature financial platforms, the monolith is several business systems sharing one deployment unit, one database, and one release process. Treating it as one large technical object pushes people toward rewrite thinking. Treating it as a set of business capabilities creates a more realistic path.

What Composable Architecture Should Mean

Composable architecture means independent, controlled change.

A composable platform has clear capability boundaries. It has explicit ownership of data and behaviour. It has integration contracts that teams can understand and support. It gives engineering and operations enough visibility to investigate behaviour across boundaries when something fails.

For a lending platform, this might mean separating credit decisioning from application workflow, isolating valuation orchestration from case management, creating a controlled boundary around credit bureau interactions, or protecting servicing and ledger behaviour from product-specific origination logic.

The shape depends on the platform. The principle is simple:

Start with the business capability, then decide the technical boundary.

Starting with technology encourages teams to split code before they understand the meaning inside it. Starting with a full replacement platform can turn a manageable modernization path into a high-risk programme.

A better question is:

Where does the business need safer, more independent change?

Find the First Safe Seam

The first modernization slice matters.

A slice that is too large becomes a rewrite in disguise. A slice that is too small becomes a technical exercise with little business value. A slice chosen only because it is visible to senior stakeholders can consume confidence instead of building it.

A good first seam usually has four characteristics.

First, the business feels pain there. The area slows delivery, creates manual workarounds, generates incidents, blocks provider change, or makes regression testing expensive.

Second, the boundary can be discovered. The team can trace the data, workflows, integrations, owners, screens, and downstream consumers involved.

Third, the change can be introduced gradually. The platform can route selected traffic, compare behaviour, preserve fallback, and avoid one irreversible cutover.

Fourth, the slice teaches the organisation something useful. It proves a modernization mechanism that can be reused.

In lending platforms, good candidates are often integration-heavy or rule-heavy areas: valuation instruction, credit search orchestration, document generation, affordability decisioning, KYC workflow, payment handoff, broker-facing submission, or reporting projections that depend on too much internal behaviour.

The best seam is rarely the cleanest box on an architecture diagram. It is the place where a controlled boundary can reduce real delivery risk.

A practical seam selection scorecard should ask:

• where the current business pain is visible,
• whether the boundary can be discovered,
• how much historical data is involved,
• whether the new path can run for selected products, tenants, or case types,
• whether fallback is possible,
• which downstream processes consume the result,
• which screens and operational journeys depend on the capability,
• what minimum observability is required before production traffic can move,
• whether operations can investigate failures,
• whether the slice teaches a repeatable modernization pattern.

This keeps the conversation grounded. The team is no longer asking which component looks old. It is asking which boundary will make change safer.

Example: Valuation as a Practical Modernization Seam

Valuations are a good example of a modernization seam that looks simple from a distance and becomes more interesting when the real flow is understood.

On paper, the process is straightforward. The lender creates a valuation instruction, sends it to a provider, waits for progress updates, and downloads the final report when the valuation is complete.

In practice, the flow becomes part of the application’s business process.

A provider-style valuation integration is rarely a single request and response. The platform may need to create the instruction, attach supporting documents, allocate the instruction, receive milestone callbacks, react to events such as panel allocation or booking, and then retrieve the completed documents when they become available.

A “document available” callback does not mean the platform already has the document. It means there is something to fetch. The application still has to retrieve the document list, inspect metadata and tags, decide which documents matter, and download the right content.

A completed valuation package can contain several artefacts: lender report PDFs, applicant or customer copies, structured report data, and sometimes an audit-style PDF version of the same data.

This is where the integration stops being a simple API wrapper.

The platform needs to know which document updates application data, which document is for human review, which document is retained for audit, and which one can be ignored. Provider tags and mime types become operationally important. If those details are handled casually, the core workflow starts depending on provider-specific naming, document conventions, and milestone behaviour.

A cleaner boundary translates the provider flow into internal valuation events and internal valuation documents.

The core platform should receive business-level facts:

• valuation instructed,
• instruction accepted,
• appointment booked,
• valuation completed,
• report data received,
• report PDF received,
• valuation failed,
• valuation cancelled.

Provider references still matter. They need to be stored. Support teams need them when a case gets stuck or when the provider asks for a transaction identifier. Correlation between the internal case, the outbound instruction, the provider reference, the callbacks, and the downloaded documents is what lets operations explain what happened.

This is also where data decisions become real.

When a new valuation is instructed for the same case, should old valuation data be cleared immediately, or should it remain visible until the new report arrives? If the provider sends a completion milestone before the structured report data has been retrieved and mapped, should the internal workflow continue?

In many cases, the safer internal rule is to continue only after the platform has the data it needs. The external milestone is useful, but the internal business event should be raised when the application can safely move forward.

This kind of seam is useful because it has a visible business process, an external provider boundary, asynchronous callbacks, documents, structured data, retry behaviour, configuration, and operational investigation.

It can also be introduced gradually. The old workflow can remain in place while one lender, product, provider route, or valuation type moves through the new boundary first.

The value is not that valuation becomes a new service. The value is that the platform learns how to isolate a provider-heavy capability without pretending the rest of the monolith has disappeared.

Once that pattern works for valuations, the same discipline can be used elsewhere: credit search, KYC, document generation, payment handoff, or pricing.

Treat Data as the Hard Part

Most modernization plans underestimate data.

Code can often be moved more easily than meaning. Data carries old product decisions, migration history, manual workarounds, provider-specific quirks, and reporting assumptions. The same field can mean slightly different things to teams in origination, servicing, risk, finance, and business intelligence.

Extracting a capability is therefore a data and ownership exercise as much as a code exercise.

The team needs to understand who owns the data, who can change it, who consumes it, how historical values should be interpreted, and what happens during the transition.

In a lending platform, these questions become practical very quickly:

• Can a historical credit decision be recalculated, or is it an auditable event that must be preserved exactly as it happened?
• Can a customer status be derived, or is it part of the operational record?
• Can an application be resubmitted, or does that create a new credit footprint?
• Can a failed payment or servicing event be replayed safely, or could it create duplicate financial state?
• Can downstream reporting tolerate transitional states during rollout?
• Can old valuation data remain visible while a new instruction is in progress?
• Should workflow continue on a provider milestone, or only after report data has been retrieved, parsed, and stored?

These questions decide whether modernization is safe.

A practical modernization path includes translation layers, reconciliation checks, migration rules, and operational reporting around the transition. The new model can improve over time, but the movement from old to new needs to be controlled, explainable, and recoverable.

Integration Boundaries Can Accelerate Modernization

Modern financial platforms are integration-heavy.

Credit bureaus, fraud systems, KYC providers, open banking services, payment platforms, valuation providers, document services, servicing systems, CRM tools, data warehouses, and partner APIs all shape the behaviour of the core platform.

Some integrations are synchronous. Some are asynchronous. Some return ambiguous states. Some require manual review. Some have commercial or operational constraints that matter as much as the technical API.

When these integrations are poorly bounded, they slow modernization. Provider-specific statuses leak into workflow logic. Retry behaviour becomes inconsistent. Production investigation depends on raw payloads that are hard to find. Replacing a provider becomes a system-wide change because the provider’s concepts have become part of the internal domain.

A controlled integration boundary changes this.

It translates external behaviour into domain-meaningful events. It standardises failure handling where that is safe. It preserves correlation and provider references for support. It separates provider-specific concerns from core workflow decisions.

This does not make provider change free. It makes provider change more controlled.

That is enough to make a large difference.

Do Not Ignore the User Interface

Business boundaries are often visible in the user interface before they are visible in the backend code.

In many legacy platforms, the UI is tightly coupled to workflow states, database fields, document rules, operational queues, and provider-specific statuses. A screen may look like presentation logic, but in practice it often encodes business decisions: which action is available, which warning appears, which document can be generated, which case can progress, and which status operations should trust.

This matters during modernization.

A new backend boundary can still be constrained by an old UI that expects the old data shape, old status names, or old workflow sequence. A valuation boundary may produce clean internal events, while the case screen still expects provider-specific milestones, legacy document flags, or database fields populated in the old order.

Frontend modernization should follow the same seam-based approach as backend modernization.

The first step is to identify which screens, journeys, and operational views belong to the selected capability. Some can remain unchanged behind an adapter. Some may need an API facade or backend-for-frontend. Some may be replaced gradually, screen by screen or journey by journey.

Micro-frontends can help when different teams need independent ownership of different user journeys. They also add deployment, design-system, testing, and integration complexity. They should support clear product or capability boundaries, rather than becoming frontend technology fashion.

A practical modernization slice should include the UI surface area in its boundary assessment. The question is not only which backend component changes. It is also which users, screens, actions, and operational decisions are affected.

Composable Means Lower Coordination Cost

A platform can have many services and still require the same coordination as the old monolith.

This happens when services continue to share database assumptions, release together, require coordinated testing, duplicate business rules, or depend on each other in ways nobody owns. The organisation gets the overhead of a distributed system while keeping the release behaviour of a monolith.

Composable architecture should reduce coordination cost.

Conway’s Law is useful here. Software architecture often reflects the communication structure of the organisation that builds it. If teams are arranged around shared dependencies and unclear ownership, the system usually ends up with the same shape.

Team Topologies gives a practical way to think about this. A boundary should be small enough for one team to understand and own. It should also have a clear relationship with the teams around it.

Each boundary should answer a few simple questions:

• What business capability does this boundary own?
• What data does it own?
• What data does it only reference?
• Which behaviours are guaranteed by the contract?
• Which failure modes are visible to consumers?
• How will operations investigate problems across the boundary?
• Which screens and user journeys are part of this boundary?
• Can this area be changed, tested, deployed, or rolled back without moving unrelated areas?

A service boundary that still requires the same release meeting, the same regression cycle, and the same production bridge has limited value.

The goal is practical independence. A team should be able to change a selected capability with less risk, less coordination, and clearer operational evidence than before.

A Practical Modernization Sequence

A practical path from monolith to composable architecture is a repeatable sequence.

Step 1: Map Business Capabilities and Change Pressure

Identify where the business needs safer change.

Which areas are stable? Which are under constant commercial pressure? Which create incidents? Which delay releases? Which depend heavily on third parties? Which require expensive regression testing? Which areas are hard for operations to explain when a case gets stuck?

This creates a map of modernization pressure.

Step 2: Map Technical Coupling

Look at the codebase, data layer, integrations, deployment process, testing, operational ownership, and support paths.

The aim is to uncover coupling before choosing a modernization slice.

This step often reveals hidden dependencies: shared tables, batch jobs, reporting extracts, manual queues, document rules, workflow states, configuration lists, support scripts, and team knowledge that exists only in people’s heads.

Step 3: Choose One High-Friction but Bounded Capability

Select a slice that matters and can be controlled.

The first slice should reduce a real business or operational pain point. It should also teach the organisation how to modernize safely.

Provider-heavy areas are often good candidates because they combine business value, operational pain, and a natural external boundary.

Step 4: Establish a Controlled Boundary

Create an explicit boundary around the selected capability.

That boundary might be an API facade, an adapter, an anti-corruption layer, a modular internal component, a workflow boundary, a UI boundary, or a data access boundary.

For a valuation seam, the boundary may sit between the old workflow and the provider. It can own provider communication, callback handling, document retrieval, metadata interpretation, correlation, retry behaviour, and mapping from provider-specific data into internal valuation facts.

The UI surface should be considered at the same time. If existing screens depend on old database flags, provider-specific states, or historical workflow order, the team may need a facade or backend-for-frontend so the rollout does not force a full UI rewrite.

Step 5: Build Minimum Viable Observability for the Seam

In many legacy platforms, observability is part of the problem.

The monolith may have text logs, inconsistent identifiers, limited metrics, batch jobs outside the main request flow, and operational diagnostics that depend on database queries or specialist knowledge.

Trying to solve observability for the whole estate before the first modernization slice can stall the programme. A better approach is to build minimum viable observability around the selected boundary.

For a valuation seam, this means being able to trace one case from the internal workflow to the outbound instruction, provider reference, milestone callbacks, document availability, document retrieval, report-data mapping, and workflow continuation.

The first goal is not a perfect observability platform.

The first goal is that engineering and operations can answer basic production questions without guesswork:

• what was sent,
• what came back,
• what was stored,
• what failed,
• what was retried,
• whether the case can safely continue.

This also changes team behaviour. A boundary is only safe when the team that changes it can observe it, support it, and explain its behaviour in production.

Step 6: Add Auditability and Rollout Controls

Before production traffic moves, the team needs evidence and control.

Add audit events, reconciliation reports, fallback paths, and rollout segmentation. In critical financial platforms, these are part of the architecture.

For asynchronous provider flows, this includes visibility across the whole chain: internal case, outbound instruction, provider reference, callbacks received, documents available, documents downloaded, report data mapped, and workflow continuation.

Step 7: Route Selected Traffic Through the New Path

Start small.

Use product, tenant, provider, workflow, or case-type segmentation where appropriate. Compare behaviour. Watch operational signals. Keep fallback available.

The first production release should prove that the boundary behaves correctly under real conditions, not only in a test environment.

Step 8: Learn, Harden, and Repeat

The first slice should prove the modernization mechanism.

If the slice improves boundaries, testing, observability, ownership, rollout control, and operational support, the organisation has gained more than a new component. It has gained a pattern for future change.

Metrics That Matter

Modernization should be measured by change confidence, not by the number of services created.

Useful measures include:

If an organisation creates ten new services but still needs the same five teams on every release call, the architecture has not become meaningfully more composable.

Modernization value is visible when a high-friction capability can be changed, tested, deployed, and supported with materially less coordination than before.

One Possible Technology Path

These principles can be applied in Microsoft, Java, AWS, Azure, GCP, Kubernetes, Kafka, PostgreSQL, or mixed enterprise environments.

In a Microsoft-oriented financial platform, the existing .NET Framework monolith might remain the system of record during the transition. A new boundary can be introduced around a selected capability using modern .NET services or a modular internal component. A facade can control routing between old and new paths. Feature flags or configuration can limit the new route to selected products, tenants, or case types.

For a valuation seam, the new boundary might handle provider authentication, instruction creation, allocation, callback processing, document retrieval, structured report mapping, and correlation. The old workflow can continue to own the wider case journey while receiving cleaner internal valuation events.

On the frontend side, a backend-for-frontend can protect existing screens from changes in the provider model. A selected operational screen can be modernized when the business journey requires it. Micro-frontends become useful when ownership of user journeys needs to move independently across teams, but they should be introduced with the same discipline as backend services.

Messaging can be introduced where it improves reliability and reduces coupling, especially around callbacks, document retrieval, and retryable work. Observability can build on the organisation’s existing monitoring stack, OpenTelemetry, or application-level correlation.

Technology enables the path. Boundary quality, data ownership, operational support, UI impact, observability, and migration discipline define whether the path is safe.

Leave Stable Areas Alone

A credible modernization roadmap should identify areas to leave in place.

Some legacy components are stable, low-risk, rarely changed, and well understood operationally. Modernizing them may consume engineering capacity without reducing meaningful business risk.

A practical roadmap should distinguish between four actions:

• Extract high-friction, high-change capabilities.
• Wrap stable systems that need modern access.
• Stabilise unstable components that need targeted remediation.
• Leave alone predictable, low-change legacy assets.

This distinction matters.

It shows the business that modernization is an investment discipline, not a technology campaign. The strongest modernization programmes create confidence because they improve the organisation’s ability to change the platform safely. They do not try to make every old component new.

What We See in Practice

Modernization succeeds when teams stop treating the monolith as one large technical object and start treating it as a map of business capabilities with different levels of risk, ownership, and change pressure.

In integration-heavy financial platforms, the first valuable step is often a controlled boundary around one painful capability.

That might be a valuation process, a credit search flow, a document generation path, a pricing lookup, a reporting projection, or a customer-facing API facade.

The exact slice matters less than the discipline behind it: clear ownership, controlled data access, testable behaviour, safe rollout, UI awareness, and operational visibility.

That is where modernization becomes credible to the business.

Because change becomes safer.

Closing

Composable architecture is the result of deliberate boundary work, repeated safely over time.

For financial platforms, the practical modernization path is usually incremental. Identify the capability under pressure. Create a controlled boundary around it. Route a small slice through the new path. Learn from it. Then repeat.

The goal is to make the platform easier to change, one proven boundary at a time.

In critical financial platforms, modernization earns trust through controlled production change, not cleaner diagrams.

Sources and Further Reading

This article is based on practical delivery experience in legacy financial platforms, supported by established modernization, architecture, operations, and resilience patterns.

Incremental modernization and legacy replacement

• Martin Fowler — Original Strangler Fig Application

A foundational reference for incremental legacy replacement. Useful background for the argument that controlled, step-by-step modernization is often safer than a large cutover rewrite.

• Martin Fowler — Strangler Fig Application

A later summary of the pattern and its role in gradual legacy system replacement.

• Microsoft Azure Architecture Center — Strangler Fig pattern

A practical cloud architecture view of gradually replacing selected parts of a legacy system while the old and new paths coexist.

• AWS Prescriptive Guidance — The strangler fig pattern

Useful context for applying the pattern to large monolithic systems and reducing migration risk.

Domain boundaries and integration seams

• Martin Fowler — Bounded Context

A short explanation of why different parts of a business domain need explicit model boundaries.

• Martin Fowler — Domain-Driven Design

Useful background for the article’s focus on business meaning, domain language, and capability boundaries.

• Microsoft Azure Architecture Center — Anti-Corruption Layer pattern

Relevant to provider-heavy modernization seams where external models, statuses, and data structures should not leak into the internal domain.

• Eric Evans — Domain-Driven Design: Tackling Complexity in the Heart of Software

Foundational book behind bounded contexts, ubiquitous language, and anti-corruption layers.

Frontend modernization

• Sam Newman — Backends for Frontends

Practical explanation of using a dedicated backend layer for a specific frontend or user experience.

• Microsoft Azure Architecture Center — Backends for Frontends pattern

Useful enterprise architecture reference for BFFs, especially when different clients or screens have different needs.

• Thoughtworks Technology Radar — Micro frontends

Good short reference for splitting frontend applications around independently owned user journeys or features.

• Peltonen, Mezzalira, Taibi — Motivations, Benefits, and Issues for Adopting Micro-Frontends

Useful because it covers both benefits and trade-offs, including duplication, payload size, coupling, and monitoring complexity.

Observability and operations

• OpenTelemetry Documentation

Vendor-neutral reference for collecting and exporting telemetry data such as traces, metrics, and logs.

• OpenTelemetry — Signals

Clear explanation of traces, metrics, logs, baggage, and profiles.

• Google SRE Book — Monitoring Distributed Systems

Strong reference for production monitoring and the four golden signals: latency, traffic, errors, and saturation.

• Google SRE Workbook — Monitoring

Practical material on monitoring dependencies, metrics, structured logging, and operational visibility.

• DORA — Software Delivery Performance Metrics

Useful reference for measuring modernization outcomes through delivery and operational performance rather than counting the number of services created.

Team boundaries and organisational design

• Mel Conway — How Do Committees Invent?

Original paper behind what later became known as Conway’s Law.

• Martin Fowler — Conway’s Law

Short modern explanation of the relationship between organisation structure and software architecture.

• Martin Fowler — Team Topologies

Concise introduction to the Team Topologies model and why team structures matter for software flow.

• Team Topologies — Key Concepts

Overview of the four team types, three interaction modes, and the idea of aligning teams with value streams.

• Matthew Skelton and Manuel Pais — Team Topologies: Organizing Business and Technology Teams for Fast Flow

Useful book for thinking about team ownership, cognitive load, platform teams, enabling teams, and stream-aligned delivery.

Financial services change and operational resilience

• FCA — Implementing Technology Change

Relevant background on how financial firms manage technology change, the impact of change failures, and practices used to reduce incidents caused by change.

• Bank of England — Operational resilience of the financial sector

Useful context for resilience expectations around important business services, IT outages, cyber incidents, and third-party supplier failure.

• Bank of England — Operational resilience in a macroprudential framework

Broader context on how operational disruption can affect firms, financial market infrastructures, and the wider financial system.

• PRA SS2/21 — Outsourcing and third-party risk management

Useful background for provider-heavy platforms and third-party dependency thinking.

• EIOPA — Digital Operational Resilience Act, DORA

EU financial services context for ICT risk management, cyber resilience, incident reporting, and operational resilience.

• EUR-Lex — Regulation (EU) 2022/2554 on digital operational resilience for the financial sector

Primary legal text for DORA.