Monolithic versus modular software architecture

Your ERP does everything — and that's exactly the problem. Changing one pricing rule triggers a three-week change request. Adding a mobile app means rebuilding screens inside a system that was never designed for mobile. And every time the vendor releases an update, your IT team holds its breath. This article explains the architectural difference between monolithic and modular software systems, when each makes sense, and how to move toward something more flexible without starting from zero.

What does "monolithic" actually mean in business software?

A monolithic system is one where all functions — sales, purchasing, inventory, finance, HR — live inside a single, tightly coupled codebase or application. Everything shares the same database, the same logic layer, and the same deployment. When one part changes, it can affect every other part.

This is not inherently bad. Monolithic systems are often well-integrated, consistent, and easier to manage in the early stages of a business. A single system with a single database means no synchronisation headaches, no API failures between subsystems, and one place to look when something goes wrong.

The problem emerges with scale — both in size and in complexity. Once a monolithic system becomes the backbone of a mid-sized or growing business, its architecture starts working against you.

Why does a monolithic ERP start slowing you down?

Here is the typical progression:

1. The system grows to fit every process. What started as a clean ERP gains custom modules, workarounds, and bolt-on screens — all built inside the same structure. The codebase becomes dense and tightly coupled.
2. Every change carries risk. Adjusting the way a sales order is confirmed can break the invoice generation, the inventory reservation, and the reporting dashboard — because they all share the same underlying logic or database tables. Developers start spending more time regression-testing than building.
3. Deployment becomes a ceremony. Releasing a small improvement to one department means deploying the entire application. A bug in one unrelated module can kill a release that was ready.
4. Integration becomes painful. Connecting your ERP to an external tool — a webshop, a courier API, a modern BI platform — means building that connector deep inside a system that was never designed for it. The result is fragile, hard to document, and harder to maintain.
5. Vendor lock-in tightens. Your roadmap is now the vendor's roadmap. You wait years for features your business needs today.

A concrete example: a distribution company runs everything in a large ERP. They want to give their warehouse staff a simple mobile scanning app to confirm picks. In a monolithic system, that mobile interface has to be built inside the ERP itself — using the ERP's own UI toolkit, on the ERP's infrastructure, subject to the ERP's licensing. A two-screen app becomes a six-month project.

What is modular software architecture?

Modular architecture — sometimes called component-based or service-oriented architecture — breaks a system into distinct, loosely coupled parts. Each module handles one domain: orders, inventory, customer data, logistics, finance. Modules communicate through well-defined interfaces, most commonly APIs.

The key principle is separation of concerns: no module reaches directly into another module's data or logic. If you want the order module to know about stock levels, it asks the inventory module via an API call. It does not read directly from the inventory table.

This is not the same as microservices, which take this principle to an extreme (hundreds of tiny services, each with its own database and deployment pipeline). Microservices introduce their own complexity — distributed tracing, orchestration, eventual consistency — that is simply not justified for most mid-sized business software. The practical sweet spot is a small number of well-defined modules with clean API boundaries between them.

How does modular architecture look in practice?

Consider the same distribution company, rebuilt on a modular foundation:

• FileMaker as the core business layer: order management, customer data, purchase orders, and business logic live in FileMaker. It is the source of truth for operational data — the system your team actually works in every day.
• A separate web or mobile front end: the warehouse scanning app is a lightweight web application. It talks to FileMaker through a REST API. It has no knowledge of FileMaker's internal structure — it just sends and receives data. Changing the app's UI does not touch the core system at all.
• Specialist integrations via API connectors: Exact Online handles the accounting. Sendcloud handles shipping labels. A custom API connector synchronises orders and invoices in both directions. Each connector is a small, focused piece of code that does one thing well. Replacing Sendcloud with a different carrier later means replacing one connector — not re-architecting the ERP.
• AI services as an additional layer: a document-understanding model reads incoming supplier invoices and extracts line items. It sends structured data to FileMaker through the same API layer. The AI service has no access to the rest of the system — it is just another module with a defined input and output.

This is an API-first design: every capability the core system offers is available as an API endpoint, and every external service talks to the system through that layer. Nothing reaches in through the back door.

What are the real trade-offs?

Modular architecture is not a free lunch. Here is an honest comparison:

	Monolithic	Modular / API-first
Initial simplicity	High — one system to deploy and manage	Lower — multiple components to coordinate
Speed of early development	Fast — no integration overhead	Slower upfront — API design takes time
Change impact	High — changes ripple across the system	Low — changes are contained within a module
Scalability	Limited — the whole system must scale together	Flexible — scale only the components that need it
Integration with external tools	Painful — often requires deep, fragile customisation	Natural — APIs are already designed for it
Vendor dependency	High	Lower — modules can be replaced independently
Operational complexity	Lower	Higher — more moving parts to monitor

The honest conclusion: if your business is small, your processes are stable, and your software is genuinely meeting your needs, a well-built monolithic system is perfectly valid. The argument for modularity is strongest when you are growing, when your processes are changing, or when you need to connect your core system to a growing ecosystem of specialist tools.

How do you move from monolithic to modular without starting over?

You do not have to rebuild from scratch. The most practical approach is the strangler fig pattern: you do not demolish the old system — you gradually build new capabilities around it, routing functionality through modern, API-connected modules until the old monolith is carrying less and less weight.

In practice, this looks like:

1. Identify the highest-friction boundary first. Where does your monolithic system slow you down the most? For most companies, it is either external integrations (connecting to webshops, accounting, logistics) or front-end limitations (mobile access, customer portals). Start there.
2. Expose that boundary as an API. If your core system is FileMaker, use FileMaker Data API or a custom REST layer to make that domain's data available without tightly coupling anything to FileMaker's internals.
3. Build the new module against that API. A new mobile app, a new customer portal, a new BI dashboard — built as a separate application that speaks to the core through the API. Test it in parallel with the old approach.
4. Decommission the old interface gradually. Once the new module is stable, retire the old bolt-on screen or manual process it replaced. The core system still holds the data and the logic — only the surface has changed.
5. Repeat for the next boundary. Over 12–18 months, a formerly monolithic system gains clean API boundaries, replaceable front ends, and the ability to connect to new tools without surgery.

This approach keeps the business running throughout the migration and avoids the catastrophic risk of a big-bang rewrite.

Checklist: is your architecture becoming a bottleneck?

• A small change to one process regularly requires testing in three or more unrelated areas
• Adding a mobile or web interface to your core system requires significant ERP customisation
• Connecting a new external tool (accounting, logistics, e-commerce) takes months, not days
• Your team avoids making improvements because "touching that part is too risky"
• You are waiting on a vendor roadmap for features your business needed last year
• Onboarding a new developer takes weeks because the codebase has no clear boundaries
• Scaling one part of the system (e.g. warehouse operations) means scaling the whole thing

If you checked three or more, the architecture is already a business constraint — not just a technical one.

FAQ

Is FileMaker a monolithic system? FileMaker is flexible enough to be used either way. Out of the box, many FileMaker solutions are built as a single file with all logic and UI in one place — a monolithic approach. But FileMaker also supports the FileMaker Data API, which means it can serve as a well-bounded core business layer in a modular architecture. The difference is in how you design it, not the tool itself.

Do I need microservices to be modular? No. Microservices are one extreme of modular design, and they come with significant operational overhead — container orchestration, distributed tracing, service mesh configuration. For most mid-sized businesses, a small number of well-separated modules (five to ten) with clean REST APIs between them delivers most of the benefit with a fraction of the complexity.

How long does a migration from monolithic to modular take? Done incrementally (the strangler fig approach), a meaningful improvement is visible within three to six months. A full migration for a mid-sized business typically takes one to two years — but the business keeps running throughout, and each completed module delivers immediate value.

What if our team does not have the API design expertise? This is the most common blocker. API design is a discipline — getting the data contracts right, handling versioning, managing authentication. It is worth investing in this expertise early, either by training internal developers or bringing in a partner who has done it at scale. A poorly designed API is harder to fix later than a monolithic system.

Can we keep our existing ERP and still move to a modular architecture? Often, yes. The question is whether your ERP can expose its data and functions through a proper API. Many modern ERPs do. If yours does not — or only does so through expensive licensed connectors — that itself is an argument for replacing or supplementing the ERP with a more open core system.

---

If this architectural challenge sounds familiar — a system that has become too rigid to keep up with the business — Loggix works with companies to map out a practical path forward. Whether that means building a tailored FileMaker solution with clean API boundaries, developing custom web or mobile front ends that connect to your existing core, or designing the API integrations that let your systems talk to each other without fragile workarounds, the starting point is always a concrete conversation about where the bottleneck actually is.