Enterprise Business Management System Architecture

Small and mid-market businesses (10-500 employees) operate on a fragmented software stack where CRM, accounting, inventory, HR, and project management run on separate platforms from different vendors with no native integration. A typical SMB uses Salesforce for CRM, QuickBooks for accounting, ShipStation or Cin7 for inventory, Gusto or ADP for payroll, and Monday.com or Asana for project management—five separate systems with five separate logins, five separate data models, and no unified view of business performance. Synchronizing data between these systems requires point-to-point integrations (often through Zapier or custom scripts) that are brittle, delay-prone, and create reconciliation headaches when data diverges.

The business impact of this fragmentation is severe. A sales manager cannot see whether a customer's invoices are current without leaving the CRM and logging into the accounting system. An operations manager cannot correlate project profitability with the associated HR labor costs without manually compiling data from project management and payroll. An executive cannot generate a dashboard showing revenue pipeline, cash position, inventory levels, and headcount on a single screen because the data lives in systems that were never designed to share information. The result is that critical business decisions are made with incomplete data, and the administrative burden of managing multiple systems consumes 15-25 hours per week of management time that should be spent on strategy and execution.

Multi-tenancy architecture for business management software presents significant engineering challenges. Each tenant's data must be strictly isolated for security and compliance, yet the infrastructure must be shared for economic viability. Tenants have different configuration requirements: a professional services firm needs time tracking and project-based billing, while a wholesale distributor needs inventory management and purchase order workflows. The platform must support these divergent workflows through configuration—not customization—to maintain a single codebase that can be deployed, updated, and scaled uniformly. Additionally, the platform must handle the wide variance in tenant size: a 10-person consultancy and a 500-person manufacturer must receive the same reliability and performance from the same infrastructure.

The platform is built on a Next.js application tier with a PostgreSQL database layer implementing row-level security (RLS) for tenant isolation. Every table in the database includes a tenant_id column, and PostgreSQL RLS policies enforce that any query—regardless of application-level bugs—can only access rows belonging to the authenticated tenant. The application sets the tenant context via SET app.current_tenant at the beginning of each database session, derived from the JWT token's tenant claim, and RLS policies filter all SELECT, INSERT, UPDATE, and DELETE operations to the current tenant's rows. This approach provides defense-in-depth: even if an application bug constructs a query without a tenant filter, the database will not return cross-tenant data.

The modular architecture organizes functionality into capability modules: CRM (contacts, companies, opportunities, pipeline management), Inventory (products, stock levels, warehouses, purchase orders, receiving), Invoicing (quotes, invoices, payments, AR aging, revenue recognition), HR (employee records, time tracking, leave management, payroll integration), Projects (tasks, milestones, time allocation, profitability tracking), and Reporting (cross-module dashboards, scheduled reports, data export). Each module is independently activatable per tenant—a tenant that does not need inventory management never sees inventory UI or pays for inventory features. Modules communicate through internal event bus (Kafka) that publishes domain events (e.g., 'invoice paid' from Invoicing triggers 'AR balance update' in Reporting and 'payment received' notification in CRM). This event-driven integration provides the cross-module data flow that makes a unified platform valuable while maintaining clean module boundaries.

The vertical market layer provides industry-specific configuration presets and workflow templates that make the platform immediately useful for specific business types. When a professional services firm signs up, they receive pre-configured project templates, hourly billing workflows, utilization tracking dashboards, and report layouts that mirror the metrics their industry uses. When a wholesale distributor signs up, they receive purchase order workflows, inventory reorder point automation, lot tracking capabilities, and margin analysis reports. These vertical layers are implemented as configuration sets—not separate codebases—using a feature flag and template system that enables the product team to create and refine vertical experiences without engineering deployment. The platform currently supports 14 verticals including professional services, wholesale distribution, manufacturing, retail, construction, healthcare practices, and nonprofit organizations.

The multi-tenancy implementation uses PostgreSQL's Row-Level Security with a shared-schema, shared-database model. Each table has a tenant_id column with a NOT NULL constraint and a foreign key to the tenants table. RLS policies are defined as: CREATE POLICY tenant_isolation ON [table] USING (tenant_id = current_setting('app.current_tenant')::uuid). The application's database connection middleware sets this session variable from the authenticated JWT's tenant claim before executing any query. Prisma ORM is configured with a custom middleware that injects tenant_id into every write operation and validates that the tenant context is set before any database interaction. Performance impact of RLS is mitigated by ensuring that the tenant_id column is the leading column in every composite index, allowing the query planner to use the tenant filter as an index prefix scan. Connection pooling uses PgBouncer in transaction mode, with the tenant context set at transaction begin rather than connection begin, enabling safe connection reuse across tenants.

The event-driven integration backbone uses Apache Kafka with a topic-per-event-type partitioning strategy. Domain events (InvoiceCreated, PaymentReceived, OrderShipped, EmployeeOnboarded) are published by the originating module and consumed by any module that needs to react. Event schemas are defined in Avro with a schema registry enforcing backward compatibility, ensuring that module updates do not break event consumers. Each module's event consumers are implemented as Kafka consumer groups with exactly-once processing semantics (Kafka transactions + idempotent consumers). The Reporting module is the primary cross-module consumer: it maintains materialized views that join data from multiple modules (e.g., project profitability = project revenue from Invoicing minus labor cost from HR time tracking minus material cost from Inventory) and refreshes these views incrementally as events arrive, providing near-real-time dashboard updates without expensive cross-module queries. Event sourcing is used selectively for financial modules (Invoicing, Payments) where a complete audit trail of state changes is required, with the event log serving as the authoritative data source and the relational tables as materialized projections.

The vertical market template system uses a configuration-as-data approach where each vertical is defined as a JSON configuration document that specifies: activated modules, custom field definitions per module (e.g., 'Lot Number' field on inventory items for wholesale distribution, 'Billable' checkbox on time entries for professional services), workflow templates (sequences of stages for opportunities, projects, or orders), dashboard layouts with widget configurations, report definitions with pre-set filters and groupings, and notification rules. When a tenant selects a vertical during onboarding, the template is applied to their tenant configuration, creating the custom fields, workflows, and dashboards non-destructively. Tenants can subsequently modify any aspect of the template to match their specific needs. The template system supports inheritance: a 'Wholesale Distribution' template can extend a 'General Commerce' base template, adding only the wholesale-specific customizations. Template versioning enables the product team to evolve vertical configurations over time, with tenants optionally opting in to template updates while preserving their custom modifications through a three-way merge algorithm.