Source: [Build for the change you can’t yet see](https://fireflysoftware.io/perspectives/architecture-for-change/)

Description: The Firefly perspective on modular architecture, business boundaries, and engineering for change.

Language: en

[Home](https://fireflysoftware.io/)/Architecture & transformation

# Build for the change you can’t yet see.

A Firefly perspective on making room for the next business decision.

A perspective from Firefly Software

A banking or insurance strategy eventually becomes a set of operating decisions: who serves the customer, who takes a risk decision, who executes the instruction and who owns the record. Architecture should express those responsibilities and make their cost and dependencies visible before the institution commits to change.

## Start with the business boundary.

Start with the service and its economics. A loan application must reach an authorized credit decision, disbursement and servicing. A claim must connect notification to coverage review, settlement and reconciliation. Front, middle and back office describe functions in these flows; they are not a fixed organization chart.

Ask which rules belong together, who may decide and which system owns each record. Include risk and actuarial data where relevant: the source, assumptions, model version and review evidence must remain understandable as work crosses systems.

## Make connections explicit.

Every connection introduces a dependency. Specify API and event schemas, permissions, version compatibility and the meaning of each status. Define where process state persists, how retries avoid duplicate business actions and how partial failures are reconciled and recovered.

Prove these decisions with tests and operational evidence. Business scenarios, data reconciliation, access checks and failure exercises should inform acceptance, alongside runbooks and named service owners.

## Choose independence deliberately.

Modularity does not require splitting everything into microservices. Each separation adds integration, monitoring and operational work. Compare that cost with the need to change a product, rule or channel independently and with the team’s ability to operate it.

Sometimes a well-structured application is the right foundation. Sometimes a capability needs its own service. Each boundary should exist for a reason you can state. How many there are matters less.

## Keep the next decision possible.

With AI, institutions can build more tailored software. Architecture determines whether that work becomes a reusable asset: a rule the business can change, a workflow another product can use or an interface that connects a new channel. Separate those assets from the infrastructure and providers they depend on.

At Firefly, we connect this design to progressive modernization. Start with a useful service, connect it to existing systems and retain the rules, software and knowledge created along the way. Each step should improve today’s operation and give the institution more room for its next business decision.

Modernizing one part at a time. Behind, your core system in graphite, kept and connected through a steel adapter plate and the APIs. In front, on the platform, three amber modules: the middle one, in dashed outline, is being replaced, and its replacement is snapping into the same place while the other two keep running.  Keep the systems that still serve the business. Connect new services through clear interfaces and modernize one part at a time.

[Explore the architecture](https://fireflysoftware.io/openplatform/architecture/)

Your next step

## Tell us whathas to change.

It might be a customer need, a business priority or an operating problem. We will assess the case for change with you, map who and what it involves, and plan a first step.

[Start a conversation](https://fireflysoftware.io/contact/)