Good ERP architecture connects finance, customers, orders,purchasing, inventory, projects and other operations without turning theentire organisation into one inseparable application.
The central challenge is balance. ERP modules need shared identities,data and processes, but they must also be understandable, testable andchangeable. Too little structure creates duplicated records andinconsistent rules. Too much coupling makes every change risky.
A sound architecture therefore starts with business capabilities andclear boundaries. It defines who owns each item of data, how modulescommunicate, where rules run and how the platform can be extendedwithout editing its core repeatedly.
This guide explains conventional layered architecture, modular ERParchitecture, APIs, events, plugin design, deployment choices and themetadata-first direction planned for Sevenlake.
What is ERP architecture?
ERP architecture is the structural design of an enterprise resourceplanning system: its applications, modules, data, integrationinterfaces, shared services, deployment model and operationalcontrols.
It answers questions such as:
- Which business capabilities belong in which module?
- Where is customer, product or financial data mastered?
- How do sales, stock, purchasing and accounting interact?
- Which services are shared across the platform?
- How can an implementation be customised safely?
- How are external systems and legacy software integrated?
- Can modules be upgraded independently?
- How are security, audit and reporting applied consistently?
- Can the system run in the required cloud or local environment?
Architecture is not merely a technology diagram. It defines thelong-term cost of change.
The main layersof an ERP system architecture
Layered diagrams are simplified, but they help separateresponsibilities.
LayerResponsibilityExamplesExperiencePresents tasks and information to users and external channelsWeb application, mobile interface, portal and reportsApplicationCoordinates use cases and transactionsConfirm order, receive goods and approve invoiceDomainRepresents business concepts, rules and state changesCustomer, product, order, stock movement and journal entryDataStores operational records and historyRelational data, documents, search indexes and audit recordsIntegrationConnects modules and external systemsAPIs, messages, imports, exports and adaptersPlatformSupplies shared technical capabilitiesIdentity, permissions, workflow, notifications andconfigurationOperationsBuilds, deploys, observes and recovers the systemEnvironments, monitoring, backups and release management
The layers do not have to be separate servers. They areresponsibilities that should remain clear even inside one deployableapplication.
Begin withbusiness capabilities, not screens
An ERP module should represent a coherent business capability ratherthan an arbitrary menu category or collection of tables.
Possible capability boundaries include:
- Customer and contact management.
- Sales and quotations.
- Order management.
- Product and pricing.
- Inventory and warehousing.
- Purchasing and suppliers.
- Manufacturing and planning.
- Projects and time.
- Billing and accounts receivable.
- General ledger and financial reporting.
These areas overlap. A sales order refers to a customer, products,prices, tax, availability and credit. The architecture must allowcollaboration without giving every module permission to changeeverything.
Define ownership forshared concepts
For each important concept, distinguish:
- System of record: the authoritative source.
- Reference: data another module can read.
- Snapshot: values deliberately copied to preservehistory.
- Derived data: values calculated from authoritativeinputs.
- Projection: a read-optimised view assembled for aparticular task.
For example, an order should reference the customer but may alsostore the invoice and delivery addresses used when the order wasconfirmed. If the customer changes address later, the historical ordermust not silently change.
Data ownership is more precise than saying that all modules share onedatabase.
What is modular ERParchitecture?
Modular ERP architecture divides the platform into boundedcapabilities with explicit contracts. Modules can collaborate whilekeeping their internal implementation and data rules controlled.
A useful module normally contains:
- Its domain entities and rules.
- Application services or use cases.
- Permission requirements.
- API contracts and emitted events.
- Database migrations or owned schema.
- User-interface contributions.
- Configuration and metadata.
- Tests and operational information.
Modularity is not achieved merely by placing code in differentfolders. A sales module is not independent if it writes directly intoinventory and ledger tables.
Benefits of modulararchitecture
- Teams can understand a smaller area.
- Rules have clearer ownership.
- Modules can be tested in isolation.
- Extensions can target defined contracts.
- Implementations can select relevant capabilities.
- Changes have a smaller blast radius.
- Some modules may eventually be deployed or scaled separately.
Costs of modulararchitecture
- Boundaries require deliberate design.
- Shared concepts need governance.
- Cross-module transactions become more complex.
- APIs and events require compatibility management.
- Duplicate read models may need reconciliation.
- Testing must cover module interaction as well as localbehaviour.
The objective is manageable coupling, not zero coupling.
Modular monolith ormicroservices?
A modular monolith contains well-separated modules within onedeployable application. Microservices place selected capabilities inindependently deployed services that communicate over a network.
QuestionModular monolithMicroservicesDeploymentOne main deployable unitMany independently deployed servicesTransactionsEasier across modulesDistributed consistency requires deliberate designOperationsSimpler infrastructure and diagnosisGreater need for automation and observabilityScalingApplication generally scales as a unitSelected services can scale independentlyTeam autonomyBoundaries enforced mainly in codeBoundaries reinforced by runtime separationFailure modesFewer network boundariesPartial failure and message delay are normal concerns
Microservices can be appropriate when capabilities need independentrelease, scaling, security boundaries or team ownership. They should notbe the default merely because the ERP is large.
A disciplined modular monolith is often a strong starting point. Itpreserves the option to extract a module later if the organisational andoperational need becomes real.
Cloud-native approaches commonly use microservices, containers anddeclarative APIs to create loosely coupled systems, but they also relyon robust automation and observability. These are operationalcommitments, not free architectural benefits. Cloud Native Computing Foundation
Design cross-moduletransactions carefully
ERP processes commonly cross several boundaries. Confirming a salesorder might:
- Validate the customer and credit position.
- Fix price and tax values.
- Reserve stock.
- Create purchasing or production demand.
- Schedule fulfilment.
- Produce accounting consequences later.
There are several architectural options.
Synchronous coordination
One application service calls modules directly and completes a sharedtransaction.
This is straightforward inside a modular monolith but creates tighterruntime coupling.
Event-driven coordination
The order module records confirmation and publishes an event.Inventory, planning and other modules react.
This reduces direct coupling but introduces eventual consistency,duplicate delivery, ordering and failure-recovery concerns.
Process manager or saga
A coordinator tracks a multi-step process and handles timeouts orcompensating actions.
This is useful for long-running work but should not replace a simplelocal transaction unnecessarily.
For every cross-module process, define what must be immediatelyconsistent and what can follow later. Users need to understandintermediate states such as “order confirmed, allocation pending”.
ERP data architecture
ERP data has a long life and wide impact. The architecture shoulddistinguish operational truth from reporting convenience.
Master and reference data
Customers, suppliers, products, currencies, tax codes, units andchart-of-account structures require clear ownership and controlledchanges.
Avoid creating a universal “master data” module that owns everythingin name but understands nothing in practice. Ownership should remainclose to the business capability responsible for quality andmeaning.
Transaction data
Orders, receipts, stock movements, invoices and journal entriesshould preserve the facts that applied at the time. Reconstructinghistory from today's master data is unreliable.
Audit history
Record significant state changes, approvals and adjustments withuser, time, reason and relevant before-and-after values. Auditinformation should be designed around business significance, not justdatabase change logging.
Reporting and analytics
Operational modules should not be overloaded by every analyticalquery. Read models, a reporting store or data warehouse may combineinformation for analysis.
Reports still need traceability to authoritative transactions, agreeddefinitions and controlled refresh behaviour.
APIs as architecturalcontracts
APIs should express business capabilities, not expose tablesdirectly.
Prefer operations such as:
- Confirm an order.
- Allocate stock.
- Approve a supplier invoice.
- Post a journal.
over unrestricted updates to generic records.
A business operation can enforce permissions, validation, statetransitions and audit consistently.
The OpenAPISpecification provides a language-neutral way to describe HTTP APIstructure and syntax. A formal contract supports documentation, testingand client generation, but it does not by itself create a stablebusiness API.
Version APIs deliberately
Avoid breaking consumers without warning. Distinguish additivechanges from changes to meaning or behaviour. Maintain an inventory ofdeployed versions and retire old endpoints deliberately.
OWASP identifies improper API inventory management as a securityrisk, noting the importance of current documentation and awareness ofdeployed hosts and versions. OWASPAPI Security Top 10
Authorisationbelongs at the operation and data level
Authentication establishes identity. ERP authorisation must alsodecide:
- Which business functions the user can perform.
- Which companies, locations or records they may access.
- Which fields they may view or change.
- Whether the action conflicts with another responsibility.
- Whether approval is required.
Do not rely solely on hiding a button in the user interface. EveryAPI and background operation must enforce the relevant rules.
Events and integrationarchitecture
Events describe business facts that have occurred:OrderConfirmed, GoodsReceived orInvoicePosted.
They allow modules and external systems to react without the sourceknowing every consumer. This supports extensibility, but only when eventcontracts are managed carefully.
Define:
- Event meaning and owner.
- Stable identifiers.
- Time and business date.
- Schema and version.
- Ordering expectations.
- Duplicate-handling requirements.
- Sensitive-data treatment.
- Retry and dead-letter behaviour.
- Retention and replay policy.
Do not use events as an excuse to lose accountability. Someone mustmonitor failures and reconcile business outcomes.
Integrating systems withoutAPIs
Legacy applications may require supported file exchange, databaseviews, middleware or a local agent. Keep the adapter at the edge of theERP architecture so that legacy formats do not spread into the domainmodel.
Use an anti-corruption layer to translate external identifiers,statuses and data structures into the ERP's own terms.
ERP plugin architecture
An ERP plugin architecture lets developers add or change behaviourthrough supported extension points rather than editing the platformcore.
Possible extension types include:
- New business modules.
- Additional entities and fields.
- Validation and calculation rules.
- Workflow steps.
- User-interface components or views.
- Reports and document templates.
- Import and export formats.
- External-system connectors.
- Background jobs and event handlers.
A plugincontract needs more than a loading mechanism
Define:
- Manifest and identity.
- Version and compatibility range.
- Dependencies on platform and other modules.
- Permissions requested.
- Installation and upgrade migrations.
- Registered APIs, events and UI contributions.
- Configuration schema.
- Uninstallation and data-retention behaviour.
- Health and diagnostic information.
- Licence and provenance.
Without lifecycle rules, extensions become permanent patches.
Protect the core
Plugins should use public contracts rather than internal tables andprivate functions. Direct access is tempting because it is fast, but itmakes upgrades fragile.
Where deep access is unavoidable, make the dependency explicit andtest it against future platform versions.
Sandboxing and trust
An extension can access sensitive ERP data or execute importantoperations. Review its source, permissions, dependencies and updateprocess. “Plugin” does not imply that untrusted code is safelyisolated.
Marketplace governance, signing and permission controls can help, butthey must be implemented and demonstrated rather than assumed.
Shared platform services
ERP modules benefit from common services where consistencymatters.
Useful shared capabilities include:
- Identity and access control.
- Organisation, company and tenant context.
- Number sequences and identifiers.
- Localisation, currency, units and calendars.
- Workflow and approvals.
- Business rules.
- Notifications.
- File and document management.
- Search.
- Audit and activity history.
- Import and export.
- Scheduling and background work.
- Configuration and feature management.
Shared services should remain focused. A generic workflow engineshould coordinate tasks and approvals; it should not become anundocumented location for every module's business logic.
User-interface architecture
ERP interfaces repeat patterns: lists, forms, searches, relatedrecords, approvals, dashboards and task workspaces.
There are three broad approaches.
Hand-built interfaces
Developers control every interaction. This provides design freedombut repeats common work and can create inconsistency betweenmodules.
Configured genericinterfaces
Forms and lists are assembled from configuration. Delivery is faster,but the platform can become restrictive for distinctive tasks.
Metadata-rendered interfaces
The platform interprets a structured model of entities, fields,relationships, permissions, validation and views. Developers can reuseplatform behaviour while extending specialised interactions wherenecessary.
The strongest approach is often layered: metadata for common businesspatterns plus deliberate extension points for task-specificexperiences.
Metadata-driven ERParchitecture
Metadata can describe more than screen layout. A coherent applicationmodel may include:
- Entities, fields and relationships.
- Data types and constraints.
- Business rules and calculations.
- Permissions and ownership.
- Workflows and state transitions.
- Views, forms and navigation.
- APIs and events.
- Localisation and display information.
- Imports, exports and mappings.
- Module dependencies and versions.
The advantage is that several platform behaviours can be producedfrom the same definition. A field's type and permission can influencestorage, validation, forms, APIs, import and audit rather than beingredefined separately.
The risk is creating an internal language so complex that only theplatform authors understand it. Metadata needs a documented schema,validation, versioning, migration, debugging and escape routes forspecialised code.
Configuration,customisation and extension
ERP architecture should distinguish three change levels.
Change typeExamplePreferred treatmentConfigurationApproval threshold or numbering patternStored, validated settingMetadata customisationAdditional entity, field, rule or viewVersioned application definitionCode extensionSpecialist optimisation or external protocolSupported plugin or service contract
If every change requires source-code modification, upgrades becomeexpensive. If every possible behaviour is forced into configuration, theconfiguration language becomes an application platform of its own—oftena poorly documented one.
Provide a clear progression from simple settings to structuredmetadata and finally to code.
Cloud, self-hosted andhybrid deployment
Architecture should separate application behaviour fromdeployment-specific configuration. The Twelve-Factor App methodology,for example, treats values that vary between deployments—such as servicelocations and credentials—as configuration rather than source code.
Deployment choices affect:
- Identity integration.
- Network access to local systems.
- Data residency.
- Backup and recovery.
- Monitoring and support.
- Update responsibility.
- Scaling and availability.
- Security controls.
Do not promise that one ERP package will run unchanged in everyenvironment. Test supported combinations and assign operationalownership clearly.
Security architecture forERP
ERP systems concentrate commercially sensitive information andpowerful operations. Security must be systemic.
Address:
- Authentication and session management.
- Role and attribute-based authorisation.
- Company, tenant, location and record boundaries.
- Separation of duties.
- Encryption and secret management.
- Input and integration validation.
- Audit and tamper awareness.
- Dependency and extension governance.
- Backup, recovery and incident response.
- Data retention and deletion.
Security decisions should be enforced by common platform mechanismswhere possible, while modules declare their specific permissions andconstraints.
Observability andoperational architecture
Technical monitoring must connect to business outcomes.
In addition to CPU, memory and error rates, monitor:
- Orders stuck in a processing state.
- Failed stock allocations.
- Unposted or unbalanced financial work.
- Integration queues and reconciliation differences.
- Duplicate messages.
- Scheduled jobs that did not complete.
- Permission and configuration changes.
Use correlation identifiers across modules and integrations so onebusiness transaction can be traced.
Design backup restoration and disaster recovery around theconsistency of data, messages, files and external commitments—not onlythe database server.
Common ERP architecturemistakes
One shared database withno ownership
Every module can update every table. Development feels fastinitially, but rules and dependencies become impossible to govern.
A microservice for everynoun
The system gains network calls, distributed transactions andoperational overhead without real independence.
Customisation by editingcore code
Each implementation becomes a private fork that is difficult toupgrade.
Generic extensionpoints without semantics
Hooks such as “before save” encourage hidden behaviour andunpredictable ordering. Prefer business-specific operations andevents.
Reportingagainst uncontrolled operational joins
Large queries bypass module meaning and create fragile dependencieson internal schemas.
Metadata without toolsand versioning
The application becomes declarative in theory but opaque inpractice.
APIs without lifecyclemanagement
Old versions, test endpoints and undocumented integrations remainexposed indefinitely.
An ERP architecture reviewchecklist
- Modules align with clear businesscapabilities.
- Important data has an accountableowner.
- Historical transactions preserverelevant snapshots.
- Cross-module consistencyrequirements are explicit.
- APIs express business operationsrather than unrestricted table updates.
- Events have stable meaning, schemasand ownership.
- Extensions use documentedcontracts.
- Plugin installation, upgrades andremoval are designed.
- Configuration, metadata and codeextensions are distinguished.
- Permissions apply consistentlyacross UI, API, jobs and imports.
- Integration failures can be retriedand reconciled.
- Reporting does not destabiliseoperational workloads.
- Deployment-specific values areseparated from application definitions.
- Monitoring covers businessprocessing as well as infrastructure.
- Data export and eventual replacementare possible.
The planned SevenlakeERP architecture
Sevenlake is exploring an open-source, metadata-first platform forERP, CRM and custom operational applications.
The intended architectural direction includes:
- Business applications defined through shared metadata.
- User interfaces generated or rendered from that metadata.
- Reusable and composable modules and templates.
- AI-assisted application creation and customisation from businessrequirements.
- Extensibility for developers.
- Data import and export.
- API-based interoperability.
- A goal of cloud or self-hosted deployment choice.
- An open-source core and future community participation.
The goal is to let common platform services interpret a structuredapplication model instead of requiring developers to rebuild forms,validation, permissions and interfaces for every module. Developerscould then concentrate on domain-specific rules, integrations andspecialised experiences.
Metadata could also give AI assistance a controlled model to modify.Rather than generating isolated source files, the AI could work withentities, relationships, rules, permissions and views that the platformcan validate.
These are design goals, not currently available productioncapabilities. Sevenlake is at the vision and architecture stage, movingtowards a proof of concept. The runtime, UI renderer, SDK, modules,connectors and marketplace still need to be built and demonstrated.
Important questions remain open, including module contracts, metadataversioning, migration, extension isolation, supported technologychoices, performance and operational governance.
Frequently asked questions
What are themain components of ERP architecture?
ERP architecture normally includes user interfaces, applicationservices, domain modules, data storage, integration interfaces, sharedplatform services and operational infrastructure. The boundaries andcontracts between them matter more than a particular diagram.
What is modular ERParchitecture?
It divides ERP capabilities into cohesive modules with explicit dataownership and interfaces. Modules can collaborate without gainingunrestricted access to each other's internal logic and data.
Is microservicesarchitecture best for ERP?
Not automatically. Microservices support independent deployment andscaling but add network, data-consistency and operational complexity. Amodular monolith is often a sensible starting point unless there is ademonstrated need for runtime separation.
What is ERP pluginarchitecture?
It is a defined extension system through which modules, rules,interfaces, integrations and reports can be added without editing theplatform core. A reliable plugin architecture also covers compatibility,permissions, migrations, updates and removal.
Should ERP modules shareone database?
They can share database infrastructure while retaining logicalownership of schemas or tables. The critical rule is that modules shouldnot bypass each other's business contracts through uncontrolledwrites.
What is metadata-driven ERP?
It represents application structures—such as entities, fields,relationships, permissions, rules and views—as structured definitionsinterpreted by the platform. This can improve consistency and reuse, butmetadata still requires engineering discipline and lifecyclemanagement.
Can an ERP run inthe cloud and on-premises?
Some platforms support several deployment models, but portabilitydepends on architecture, dependencies, licensing and supportedoperations. Each target environment must be tested and supportedexplicitly.
Build for change, nottheoretical purity
ERP architecture succeeds when the system can support an integratedbusiness while remaining understandable and adaptable.
Start with capability boundaries and data ownership. Use synchronouscalls, transactions, events and separate services where each isjustified. Protect the core with documented extension contracts. TreatAPIs, metadata and plugins as versioned products rather thanimplementation details.
Sevenlake is being developed around a metadata-first, modular visionfor adaptable business software. If you want to follow or contribute tothat architectural direction, explore Sevenlake fordevelopers, view the publicroadmap or follow developmenton GitHub.
