Centralized Multi-School ERP: Architecture and Engineering Leadership

Overview

A centralized multi-school ERP shared by schools and head-office functions — not presented here as a true SaaS multitenant product. Module boundaries covered student lifecycle, admissions, academics, finance-related operations, transport, access control, notifications, configuration, integrations, and reporting. Architecture notes separate implemented platform patterns from recommendations that were not yet validated in production. Capacity discussions used an expected concurrency context around 15,000 concurrent users; that figure is a design expectation, not measured production concurrency.

Problem

Multi-school operations needed consistent information and controlled workflows across schools, head-office functions, and parent/staff applications — without collapsing every school into a one-size-fits-all process or leaving cross-module ownership ambiguous.

Constraints

• • Client confidentiality — public naming stays anonymized as a centralized multi-school ERP
• • Ongoing institutional operations during delivery
• • Process variation across schools
• • Mixed maturity across modules and workstreams
• • Some investigations produced recommendations that remain unverified
• • 15,000 concurrency is design expectation only; school-count and total-user figures are not published pending owner confirmation

Solution

Framed the platform around institutional actors and reusable workflow modules, with explicit attention to domain boundaries, integration edges, production investigation, reporting classification, and release governance. Personal contribution centers on solution architecture, technical review, requirements clarification, production analysis, team coordination, and delivery leadership — distinct from implementation completed by the wider team.

Results

• • Clarified cross-module architecture and workflow ownership for a centralized multi-school ERP.
• • Supported production investigation and remediation planning, distinguishing observation, immediate stabilization, later investigation, and proposed follow-up.
• • Defined release and review responsibilities that make technical decisions and handoffs more explicit.
• • Documented reporting decisions around definitions, freshness, access, and refresh ownership.
• • Created focused case studies on performance, reporting, and governance from the same engagement.

Lessons learned

In education ERP work, actors, permissions, calendars, and module boundaries are product decisions first. If those stay vague, every later integration and report becomes expensive. Separate what was defined, what was implemented, and what was validated. Do not equate a centralized multi-school platform with SaaS multitenancy unless the tenancy model is explicitly designed and evidenced.