Review an ERP before scaling by tracing its most important business workflows end to end, then testing whether domain ownership, identity and authorization, integrations, reporting, operations, and releases remain explicit at every boundary. The deliverable is not a fashionable target diagram. It is an evidence-backed list of risks, options, and sequenced decisions.

Scaling increases more than traffic. It adds institutions, roles, policy variations, integrations, reporting demands, and concurrent change. An architecture that works for one operating model can become unsafe when the number of exceptions grows. The review therefore has to examine semantic scale—how many meanings and rules the system carries—as seriously as request volume.

This approach is informed by sanitized experience with education ERP systems. It does not describe a private client environment or claim that every ERP needs the same topology.

Start with context, not components

An inventory of APIs, queues, and databases is useful, but it does not explain whether the system preserves the business rules. Start with a small set of consequential workflows such as admission, enrollment, fee assessment, payment reconciliation, attendance correction, and report-card publication.

For each workflow, record:

  • the actors and the authority under which they act;
  • the states and transitions, including cancellation and correction;
  • the system of record for each fact;
  • synchronous and asynchronous dependencies;
  • institution or tenant context;
  • audit and reconciliation requirements;
  • expected failure behavior.

Then walk the actual implementation. Compare the intended flow with routes, jobs, tables, integration handlers, operational dashboards, and deployment steps. Architecture diagrams often omit scheduled jobs and manual exports, even though those paths may carry privileged data or mutate important state.

The school ERP project overview gives educational context for the kinds of workflows involved without exposing a private production design.

Investigate domain boundaries through ownership

A domain boundary is credible when a team can answer who owns a fact and who may change it. Module names alone are not evidence.

Consider the word “student.” Identity, admission, enrollment, attendance, billing responsibility, and credentials are related, but they are not interchangeable. If every module updates a shared student record, a seemingly local change can alter unrelated workflows. Conversely, splitting each noun into a separate service can create distributed coordination without clarifying ownership.

Use concrete questions:

  1. Which domain creates this fact?
  2. Which domain may correct it?
  3. Which consumers receive a copy, and how do they detect staleness?
  4. What invariant must remain true across a transition?
  5. Can a failed step be retried safely?

Look for duplicated validation, writes across module boundaries, and generic “core” services that contain unrelated rules. These are investigation leads, not automatic rewrite triggers. A modular monolith with enforceable boundaries can be easier to operate than prematurely separated services.

Follow identity and RBAC across every entry point

Identity answers who or what is acting. Authorization answers whether that actor may perform this action on this resource in this institution and state. A role label such as admin is rarely enough for an ERP.

Review interactive requests, background jobs, bulk imports, exports, support tools, and integration callbacks. For each path, determine:

  • how identity is authenticated;
  • how tenant or institution context is established;
  • where authorization is evaluated;
  • whether decisions are based on current policy;
  • what is logged without leaking sensitive data;
  • what happens when context is absent or ambiguous.

Role-based access control should be tested as a permission matrix using real actions, not only by reading role names. Check high-risk combinations: a staff member with responsibilities in two institutions, a finance operator who can view but not reverse payments, or a temporary administrator whose assignment has expired.

If PostgreSQL row security is used as a defense layer, inspect the policies and the database roles that own or bypass them. PostgreSQL documents important behavior, including default denial when row security is enabled without an applicable policy and exceptions for table owners or roles with BYPASSRLS. Database policy can strengthen isolation, but it does not replace application-level authorization or workflow rules.

Treat integrations as business protocols

Payments, identity providers, messaging gateways, learning platforms, and accounting exports are not plumbing. Their retries and partial failures affect business state.

For every integration, identify the contract owner, idempotency strategy, timeout behavior, retry policy, reconciliation path, and source of truth. Ask what happens when a provider accepts a request but the ERP times out before receiving the response. Blind retrying could duplicate an effect; never retrying could leave the systems inconsistent.

Capture versioning and deprecation assumptions as well. An undocumented CSV exchanged by operators is still an integration. It deserves ownership, validation, and a recovery procedure.

The review should distinguish immediate controls—such as idempotency keys and reconciliation views—from deeper changes such as moving integration state into a domain-owned adapter. That distinction keeps remediation proportional.

Separate operational reporting from analytical reporting

Reporting can expose unclear data ownership faster than transactional screens do. A request for “current fee status by institution” forces the architecture to define current, fee status, institution scope, and correction behavior.

Classify reports by purpose:

  • Operational: must reflect recent workflow state and support an immediate action.
  • Reconciliatory: compares two systems or accounting periods to find disagreement.
  • Analytical: supports trends and aggregation where controlled delay may be acceptable.
  • Regulatory or contractual: requires stable definitions, traceability, and controlled correction.

Do not route every report directly to transactional tables by default, but do not create a separate warehouse merely to look scalable. Review query shape, freshness needs, consistency expectations, and the cost of rebuilding derived data. Materialized views, replicas, precomputed projections, and analytical stores each move cost and complexity; none removes the need for definitions.

For a focused example of separating reporting work from transactional paths, see the ERP reporting architecture case study.

Review observability from user symptoms backward

An ERP is not observable merely because hosts emit CPU and memory charts. Begin with user-visible outcomes: admissions submitted, payments reconciled, reports generated, notifications delivered, and scheduled work completed within its business window.

Google’s SRE guidance distinguishes symptoms from causes and recommends monitoring signals such as latency, traffic, errors, and saturation. Apply that reasoning at both service and workflow levels. A healthy HTTP success rate can hide a queue whose oldest item is becoming stale, or a report job that succeeds after its useful deadline.

Inspect whether telemetry can answer:

  • Which institution and workflow are affected, without placing sensitive data in labels?
  • Is the failure at an application, dependency, or integration boundary?
  • How old is pending work?
  • Can an operator correlate an external callback with the original request?
  • Are alerts actionable, or do they report causes without user impact?

Cardinality and privacy are design constraints. Tenant identifiers in every metric label may be expensive or inappropriate; logs and traces need retention and access controls. Choose the minimum context that supports diagnosis.

Examine release design as part of architecture

The ability to change a system safely is an architectural property. Review schema migrations, backward compatibility, feature configuration, rollback limits, and the blast radius of a deployment.

Database changes deserve particular attention. A release may need old and new application versions to coexist while a migration proceeds. Destructive schema changes and large backfills should be separated from code rollout when their failure and recovery paths differ.

Canarying can reduce exposure by comparing a candidate with a control, as the SRE Workbook explains, but it is not automatically suitable for every ERP change. A workflow mutation may be difficult to split between cohorts, and a database migration may affect all instances. Where canaries are unsafe, use compatibility phases, shadow reads, targeted verification, feature controls, or institution-by-institution activation as appropriate.

Hypothetical review: fee collection

Suppose a multi-institution ERP records fee commitments, starts payment attempts through an external provider, and produces daily reconciliation reports.

The workflow trace finds that the finance module owns commitments, a generic integration module stores provider callbacks, and reporting infers payment status from both. A support tool can also mark an attempt complete, but its authorization check only tests a broad staff role. The system has request metrics, yet no measure of unreconciled attempts by age.

The evidence suggests several different risks:

  • unclear ownership of payment completion;
  • authorization that ignores finance scope and institution;
  • duplicate or late callbacks without an explicit transition policy;
  • reporting that reconstructs truth from competing records;
  • missing visibility into stale reconciliation work.

A responsible recommendation would not immediately prescribe microservices. Near-term work could define one payment state machine, centralize transition authorization, make callbacks idempotent, and expose reconciliation age. A later boundary change may be justified if the integration lifecycle remains independently complex. The sequence follows risk and learning, not architectural fashion.

Tradeoffs the review must make explicit

Strengthening boundaries can add translation code and temporarily slow feature delivery. Centralizing authorization improves consistency but can create a critical dependency if its failure mode is not designed. Database-enforced isolation provides defense in depth but adds policy complexity and requires careful role management.

Derived reporting models protect transactional paths but introduce freshness and rebuild concerns. More telemetry improves diagnosis while increasing storage, privacy, and operational costs. Progressive releases reduce blast radius only where traffic and state can be partitioned safely.

Finally, a full rewrite can remove accumulated constraints, but it also discards proven behavior and creates a long period of parallel change. Incremental extraction is slower to make visually dramatic, yet often preserves feedback and reversibility. The review should present both where credible and state what evidence would change the decision.

What to measure after the review

Choose measures tied to the identified risks, not a universal dashboard:

  • workflow completion and failure by meaningful operation;
  • age and volume of pending asynchronous work;
  • authorization denials and privileged changes, reviewed with privacy controls;
  • integration retries, duplicates, and unreconciled outcomes;
  • report freshness, runtime, and impact on transactional workloads;
  • deployment failures, rollback or forward-fix outcomes, and migration duration;
  • incident detection and recovery evidence for critical workflows;
  • architecture remediation progress and any risk consciously accepted.

Baselines should reflect the system’s calendar and workload patterns. Enrollment and finance peaks may make a quiet-week average misleading. Define decision points—for example, when a reporting workload should move off the primary path—using observed capacity and business tolerance rather than copied thresholds.

References

The primary references for operational claims are Google’s monitoring guidance and canary release guidance. PostgreSQL’s row security documentation is the source of truth for row-policy behavior and bypass conditions.

Related case study

The ERP reporting architecture case study shows how reporting design can be evaluated as part of reliability and data ownership rather than treated as an isolated query-tuning problem.

If your ERP is approaching a growth, migration, or reliability decision, the Architecture Review service turns workflow evidence into prioritized risks, options, and a practical roadmap.