What is composable architecture?

Your ERP was built when the business was half its current size. Now every new tool — a customer portal, a shipping integration, an AI-assisted quoting engine — has to be bolted onto a system that was never designed to carry that weight. Development slows, maintenance costs climb, and the people who know the old system inside-out become a single point of failure. Composable architecture is the structural answer to that problem. This article explains exactly what it is, why it matters for mid-market businesses, and how to move toward it without starting from scratch.

What does "composable architecture" actually mean?

Composable architecture is a design philosophy in which a business application is built — or rebuilt over time — as a collection of independent, interchangeable components, each responsible for one clear job, connected through well-defined interfaces (usually APIs). Think of it as LEGO rather than concrete: you can add a block, swap a block, or remove a block without dismantling the whole structure.

The term was popularised by Gartner around 2020 but the underlying idea is older: modular design, service-oriented architecture (SOA), and microservices all share the same DNA. What composable architecture adds is a business-level framing — it is not just a technical pattern but a deliberate strategy for keeping software aligned with a company that keeps changing.

Key concepts that travel with composable architecture:

• Packaged Business Capabilities (PBCs): discrete units of business functionality (inventory management, invoicing, route planning) that can be sourced, built, or replaced independently.
• API-first design: every component exposes its data and logic through a documented API, so nothing is locked inside a proprietary black box.
• Loose coupling: components depend on each other's interfaces, not on each other's internal implementation — meaning one component can change without breaking another.
• Event-driven integration: components communicate by publishing and listening to events (e.g. "order confirmed", "stock level updated") rather than direct calls, which reduces fragility.

Why is this relevant now? What changed?

For most of the last two decades, the standard answer to growing business complexity was a bigger monolith — an all-in-one ERP that promised to handle everything. That worked when processes were stable and integrations were rare. It no longer works when:

• A logistics company needs to connect its warehouse management system to three different carrier APIs, a customer self-service portal, and a real-time route optimisation engine — all introduced in the last 18 months.
• A manufacturing firm wants to add AI-driven demand forecasting without rebuilding its entire production planning module.
• A professional services firm needs a client-facing project dashboard that pulls live data from its internal FileMaker system, its accounting platform, and its CRM — simultaneously.

Monolithic systems struggle here not because they are badly built, but because they were built for a different era. Every new requirement means touching the core, retesting the whole, and risking a regression somewhere unexpected. The cost and fear of change grows with every year.

Composable architecture breaks that cycle by making change the norm rather than the exception.

How is composable architecture different from microservices?

Microservices is a technical implementation pattern: splitting an application into very small, independently deployable services, each running its own process. Composable architecture is the broader strategy — microservices can be one way to achieve it, but they are not the only way and are often overkill for mid-market businesses.

A practical composable system for a 50-person manufacturing company might combine:

• A FileMaker core handling production orders, stock levels, and custom workflows
• A REST API layer exposing that data to external systems
• A cloud-based Power BI or Metabase dashboard for management reporting
• A mobile web app for shop floor staff to log production steps
• An OpenAI-powered module that drafts customer quotes based on historical job data

None of those components need to be "microservices" in the strict technical sense. They just need to be loosely coupled and API-connected. That is composable thinking applied at a scale that is actually achievable without a team of 20 engineers.

What does composable architecture look like in practice?

Manufacturing: decoupling production planning from ERP

A mid-sized manufacturer runs its entire operation — purchase orders, production scheduling, stock management, customer orders — inside a single FileMaker ERP built over 10 years. It works well for the core process. The problem: every time the commercial team wants a new customer-facing feature (a delivery tracking page, an automated order confirmation email, a dealer portal), it requires modifying the monolithic FileMaker system, retesting everything, and deploying a new version.

With a composable approach, the FileMaker ERP stays as the system of record for production data. A lightweight API layer is added — FileMaker Data API or a custom middleware — that exposes order status, stock levels, and delivery dates as clean JSON endpoints. The dealer portal becomes a separate web application that reads from that API. When the portal needs a new feature, it is developed and deployed independently. The FileMaker core is not touched.

Result: the core ERP is stable and fast to maintain; the customer-facing layer evolves at the speed the commercial team needs.

Logistics: connecting carrier APIs without rebuilding the TMS

A logistics company manages shipments in a FileMaker-based transport management system (TMS). When a new carrier (PostNL, DHL, DPD) is added, someone manually copies tracking numbers from the carrier's web portal into FileMaker — every single shipment, every single day. When a shipment status changes, the customer has no idea until someone calls.

Composable architecture here means introducing a carrier integration layer: a set of API connectors, one per carrier, that push tracking events into FileMaker automatically the moment the carrier updates its system. Each connector is an independent component. Adding a fourth carrier means writing a fourth connector — not rebuilding the TMS. Removing a carrier means switching off one connector — nothing else changes.

The customer-facing tracking page is a separate web component that reads the same data via API. It can be redesigned, moved to a new domain, or replaced entirely without any impact on the TMS itself.

Professional services: AI-assisted proposals without replacing the practice management system

A consulting firm uses FileMaker to manage projects, staff allocation, and client records. Leadership wants AI-generated project proposals — feeding in client history, past project scopes, and staff capacity to produce a first-draft proposal document in minutes.

In a monolithic approach, this AI feature would have to live inside FileMaker, built as a custom FileMaker script or plugin — fragile, hard to update, and dependent on FileMaker's deployment cycle.

In a composable approach, the AI capability is a separate service: a Python-based API endpoint that receives a client ID and project type from FileMaker, queries the relevant records via FileMaker Data API, calls the OpenAI API with a structured prompt, and returns a formatted proposal draft. FileMaker triggers the process with a single script step. The AI logic lives outside FileMaker and can be updated, retrained, or replaced without touching the practice management system.

How do you move toward composable architecture without starting over?

This is the question most business owners and IT managers actually need answered. The answer is: incrementally, starting at the edges.

Step-by-step: moving from monolith to composable

1. Map your current system's boundaries. Identify which parts of your monolith are stable and core (unlikely to change often) versus which parts are volatile (need frequent updates, face external integrations, or cause the most maintenance pain). The stable core stays; the volatile edges become candidates for extraction.

2. Identify your first "strangler fig" candidate. The strangler fig pattern means building a new independent component alongside the old system, routing relevant traffic to it, and gradually letting the old code wither. A good first candidate: a reporting dashboard, a customer-facing portal, or a single integration (e.g. your accounting sync). Pick something that causes real pain but is not the beating heart of your operation.

3. Add an API layer to your existing core. Before you can connect anything, your existing system must be able to talk to the outside world. If you're on FileMaker, enable the FileMaker Data API or build a custom middleware that exposes the records and operations other components will need. Document it properly — an undocumented API becomes a new monolith.

4. Build the first new component independently. Use the right tool for the job, not the tool you already have. A customer portal might be a React web app. A reporting layer might be Metabase pointed at a replicated database. An AI module might be a FastAPI Python service. Keep it small and scoped — one job, one component.

5. Define the contract, then protect it. The API contract between your core and your new component is a promise. Both sides depend on it. Version your API endpoints (e.g. /api/v1/orders) and never change a published version's response structure without versioning up. This discipline is what makes composable architecture actually work long-term.

6. Repeat with the next pain point. Composable transformation is not a project — it is an ongoing operating mode. Each time you need a new capability, ask: "Is this better as a new independent component, or does it genuinely belong in the core?" Most of the time, new capabilities belong outside the core.

What are the trade-offs and real gotchas?

Composable architecture is not free. Here are the honest downsides:

• Operational complexity increases. Instead of one system to monitor, you now have five. Each component can fail independently. You need logging, alerting, and someone who understands the full picture.
• API versioning is hard to sustain without discipline. If you don't rigorously version and document your APIs, you end up with undocumented dependencies that are just as brittle as any monolith — except now the brittleness is hidden across component boundaries.
• Data consistency becomes your problem. In a monolith, transactions are easy. Across distributed components, you have to think carefully about what happens when one component updates and another doesn't receive the event. This is an engineering problem most business teams underestimate.
• The up-front investment in the API layer is real. Exposing your FileMaker or legacy ERP data cleanly via API takes time and care. It is not a weekend project. But it is also a one-time foundation investment — every subsequent component benefits from it.

For most mid-market businesses, the right answer is a pragmatic composable approach: not full microservices, but a thoughtfully modularised system where the most volatile parts are independent and the stable core is protected and well-exposed via API.

Composable architecture checklist: are you ready?

Before starting, check where you stand:

• Do you know which parts of your current system change most often?
• Does your existing core system expose a documented API (or can it)?
• Do you have a clear owner for the integration layer (middleware, API gateway)?
• Is your team comfortable maintaining multiple small components rather than one large system?
• Do you have monitoring and alerting for each component independently?
• Have you documented the data contracts between your current systems?
• Is there a clear business pain point driving the first new component — not just architectural ambition?

If you answered "no" to three or more: start with the API layer and the strangler fig approach before attempting full composability.

FAQ

Is composable architecture only for large enterprises? No. The principle scales down well. A 30-person logistics company with a FileMaker TMS and two carrier API connectors is already composable in a meaningful sense. The important thing is the mindset — build new capabilities as independent components from day one, rather than always extending the core.

Does composable architecture mean I have to move to the cloud? Not necessarily. Composable architecture is about how components relate to each other, not where they run. You can have an on-premise FileMaker core, a cloud-hosted web portal, and a locally-deployed AI service all working together composably. Hybrid is common and often the right answer.

How does composable architecture affect my vendor lock-in risk? It reduces it significantly — if each component exposes a documented API and is independently replaceable, you can swap out any vendor without rebuilding everything. This is one of the most underrated strategic benefits for businesses that have been locked into a single ERP vendor for years.

What is the difference between composable architecture and just using a lot of SaaS tools? Using many SaaS tools without a deliberate integration strategy is fragmentation, not composability. Composable architecture requires intentional API design, a clear system of record, and deliberate decisions about where each capability lives and how components communicate. Ad-hoc SaaS sprawl is the opposite of composable — it creates new monolithic dependencies you don't control.

Can FileMaker be part of a composable architecture? Yes — and it is a natural fit for the core system-of-record role in many mid-market composable setups. FileMaker's Data API, combined with custom middleware or an API gateway, allows it to act as a well-exposed data and logic core while independent web apps, mobile apps, AI services, and third-party integrations are built around it.

---

If your business is at the point where your current system is slowing you down more than it is helping you move — where every new integration feels like open-heart surgery — composable architecture is worth taking seriously as a structural solution, not just a technical trend. At Loggix, we help businesses work through exactly this kind of transition: mapping what should stay in the core, designing the API layer that makes everything connectable, and building the independent components — whether that is a tailored web application, a carrier API connector, or an AI module inside your existing FileMaker environment — that let your software grow the way your business does. If you want to think through what a composable approach would look like for your specific situation, that conversation is a good place to start.