A field report from a multi-campus Banner integration program built on Ethos. Where the modern API surface shines, where it stalls under load, and what we would do differently on day one.
The brief
A multi-campus higher education system asked us to modernize the integration fabric around Ellucian Banner. The estate was familiar: a decade of point-to-point interfaces, a tangle of nightly batch jobs against the underlying Oracle database, a CRM that was always one day behind, and a student-facing portal stitched together with screen scrapes and SOAP calls nobody wanted to touch.
The mandate was to move every downstream consumer — CRM, data warehouse, identity provider, financial aid partner, mobile app — onto Ellucian Ethos and the Banner REST APIs, retire the direct database reads, and stand up an event-driven integration layer that could survive the institution's planned move to Banner SaaS.
What modern APIs actually buy you
The Ethos Integration platform plus the Banner Extensibility framework genuinely change the contract with downstream systems. Consumers stop reasoning about SATURN and PAYROLL tables and start reasoning about resources: students, persons, sections, academic-credentials, employees. Schemas are versioned. Authorization is centralized. Subscriptions to change events replace the nightly cron jobs that nobody dared to reschedule.
For the CRM and the data warehouse, the payoff was immediate. The CRM moved from T+1 to near-real-time. The warehouse stopped paying the nightly extract tax and started replaying Ethos messages into the lakehouse. The identity provider stopped depending on a custom view over GOBTPAC and started subscribing to the persons resource.
More importantly, the institution stopped being the integration vendor for itself. Each new downstream system became a configuration exercise inside Ethos rather than a six-month custom build.
Where the API surface stalls — and what to do about it
Banner's REST APIs are well-modeled but they are not infinitely fast. Three patterns bit us hard enough to call out.
First, paginated reads at scale. Pulling the full students collection during initial loads is expensive. Page sizes are capped, throttling is real, and naive consumers will spend hours doing what a single bulk extract used to do in minutes. We solved this by treating the first hydration as a one-time bulk job — sourced from a controlled read replica with sign-off from the DBAs — and reserving the API for deltas thereafter.
Second, deep includes and chatty resource models. Some resources require multiple hops to assemble what a downstream system considers a single record (a student plus their academic program plus their current registration plus their financial aid status). Doing this naively at request time produces user-visible latency in the portal. We pre-projected these aggregates into a read-optimized store fed by Ethos change events, and served the portal from the projection — not from synchronous fan-out against the APIs.
Third, the long tail of resources that are not yet first-class in Ethos. For a handful of business processes — primarily around financial aid packaging and a few institution-specific Banner extensions — the resource simply was not available, or was available but missing fields the downstream consumer required. The temptation is to fall back to direct database reads. We resisted, and instead used Banner Extensibility to publish a custom resource into Ethos. It is slower to build the first time. It is dramatically cheaper to maintain, and it survives the SaaS migration intact.
Data availability through Ethos: the unglamorous truth
Ethos exposes a curated, opinionated data model. That is its great strength — and the source of most of the friction on a real program. Not every column on every Banner form has a corresponding field on the Ethos resource. Code values are normalized through the institution's GUID mapping, which has to be governed deliberately or it drifts. Historical data — anything older than the change-event retention window — is not retrievable through subscriptions and has to be backfilled out-of-band.
Three practices made this manageable. We stood up a small data governance forum, co-chaired by the registrar and IT, that owned the GUID mappings and the resource extension backlog. We treated the lakehouse as the system of record for history, and Ethos as the system of record for current state. And we built a thin, versioned semantic layer between Ethos and the downstream consumers, so that when a resource shape changed we could absorb it in one place instead of in every consumer.
Five lessons we would carry into the next program
Plan the bulk hydration before you plan the API integration. Most programs underestimate the initial load and overestimate the steady-state throughput. Get the one-time extract right and the rest of the program gets easier.
Treat Ethos change events as the primary integration mechanism and synchronous reads as the exception. Downstream consumers that pull on every page render will run out of headroom faster than you expect.
Govern the GUID mappings as a first-class artifact. They are not a technical detail; they are the institution's master data contract with itself.
Build the resource extension capability early. The first custom Ethos resource takes weeks. The fifth takes days. You will need them.
Sequence the program around the SaaS migration. Every integration that still depends on direct database access is a blocker for the move to Banner SaaS. Every integration that goes through Ethos is portable by construction.
Where to start
If your institution is running Banner today and planning a move to SaaS in the next two to three years, the integration fabric is on the critical path — not the application upgrade itself. We help institutions assess the current integration estate, prioritize the consumers to migrate first, and stand up the Ethos-led operating model that makes the SaaS move a non-event.