Engineering decisions in context
Explore performance investigation, release governance, and reporting architecture from a centralized multi-school ERP engagement delivered through NeoSOFT.
Investigating Performance and Reliability in an Enterprise ERP
Within the school ERP engagement, Redis memory growth, PostgreSQL CPU pressure, materialized-view refresh load, query amplification, middleware latency, and connection-pool concerns were investigated. This case separates observation, immediate stabilization, later investigation, proposed follow-up, and measured results where actually available.
Finding
Immediate stabilization actions recorded for Redis cleanup/capacity and selected PostgreSQL capacity/index work.
Defining Release Governance for Enterprise Engineering Teams
For the school ERP program, contribution focused on making SRS sign-off, walkthroughs, technical-flow ownership, architecture review, QC evidence, PR governance, environment access, release impact/rollback, production checks, and RCA expectations explicit.
Finding
Made review responsibilities and release expectations explicit.
Designing Reporting Across ERP Workflows
Operational and executive reports needed consistent business definitions, freshness choices, access hierarchy, and refresh ownership — distinguishing live, near-real-time, materialized-view, and nightly-summary paths, and separating existing portal/Metabase reporting from proposed embedded Metabase work.
Finding
Clarified reporting decisions around definitions, freshness, query cost, access, and refresh ownership.
Related
- School ERP overview
Parent project for these workstream case studies.
- ERP / Business Application Solution Blueprint
- Production Performance & Reliability Diagnostic
- Architecture Review
Working through something similar?
Tell me what you are building or where the system is struggling. We can identify whether an architecture review, ERP blueprint, performance diagnostic, or technical advisory is the right next step.