Academic ERP
Re-architecting a long-running academic ERP into a modular, well-bounded platform that institutional teams can extend without regression.
- Stack
- 7 technologies
The problem
What needed solving
Years of incremental additions had produced overlapping data ownership, implicit coupling between modules, and a schema where integrity was enforced by convention rather than by constraints — making every change high risk.
My role
Responsibilities
Architecture and technical direction: domain and data modelling, module boundary definition, migration sequencing, API contract design, caching strategy, and review of the delivery work against those decisions.
The solution
Architecture summary
A modular Spring Boot backend over a normalised PostgreSQL schema, with Redis-backed caching for reference data, Flyway-managed forward-only migrations, and an Angular front end consuming versioned REST contracts.
Case study
In detail
Context
Academic ERP systems accumulate scope. Admissions, registration, curriculum, examinations, results, fees and reporting arrive as separate mandates over many years, and each one is usually bolted onto whatever structure existed at the time. The result is a platform where a change to one module produces defects in three others.
This engagement was a structured modernization of such a system: keeping the institutional knowledge encoded in it while replacing the parts that made it unsafe to change.
Approach
The work started with the data, not the UI. Every module was mapped back to the entities it actually owned, duplicated columns were consolidated, and referential integrity was restored with real foreign keys and check constraints instead of application-level convention.
With the model corrected, the application was reorganised into explicit bounded modules — each owning its tables, exposing a versioned API, and depending on its neighbours only through those contracts. Cross-module reads that previously reached directly into another module's tables were replaced with published interfaces.
Architecture
- Spring Boot service layer with module-scoped packages and no cross-module repository access
- Normalised PostgreSQL schema with Flyway migrations applied in a strictly forward-only sequence
- Redis caching for reference data and read-heavy academic lookups, with explicit eviction on write
- Angular front end consuming versioned REST contracts, with role-scoped routing
Notes on disclosure
Institution-specific configuration, operational addresses, enrolment data and internal process detail are deliberately excluded from this write-up.
Outcomes
What changed
- Module boundaries made explicit, so a change in one academic area no longer requires regression testing every other area
- Referential integrity moved from application convention into database constraints
- Read-heavy academic lookups served from cache with deterministic eviction on write
- Migration path defined so the platform could be modernised in stages rather than through a single high-risk cutover