Rebuilding an integration estate on Ethos when throughput was the constraint
The architecture was agreed in a week. The hard part took months: making Ethos carry a nightly volume the original design assumed it could handle, and proving the data matched.
- Institution type
- Multi-campus higher-education system
- Enrollment
- 30,000+ students across campuses
- Estate
- Ellucian Banner and Ellucian Student, CRM, LMS, ERP-adjacent finance, BI platform, IdP
- Engagement shape
- Principal plus an integration pod, working with institutional developers
- Duration
- Multi-phase program over roughly a year
Anonymized engagement profile. The work described was led by our principals; the institution is not named and figures are stated as ranges so nothing identifying is disclosed.
The situation
Nobody could produce a list of the interfaces touching the student record. The inventory exercise found several dozen: Ethos calls, hand-rolled REST services, SOAP endpoints, overnight file drops, and a long tail of jobs reading Banner tables directly — including two reports that a downstream office considered mission-critical and the IT group had never heard of.
The program had a fixed reason to exist: a SaaS migration was on the roadmap, and direct database access would not survive it. But the first Ethos-based replacement built by the institution's own team failed on volume. A full nightly person and enrollment sync did not finish inside the window, and one required field was not exposed in the Ethos data model at all.
That combination — throughput ceilings and data availability gaps — is the pattern we have hit repeatedly, and it is the reason integration estimates built from an architecture diagram alone are unreliable.
What we did
Inventory every interface and rate it for SaaS risk
Each interface was catalogued with its consumer, data direction, volume, schedule and mechanism, then risk-rated. Direct-database consumers and undocumented jobs went to the top of the queue.
Measure Ethos before designing against it
A throughput proof of concept ran real resources at real volumes to establish page sizes, concurrency limits, error rates and the actual duration of a full sync. Every subsequent estimate was built on those measurements rather than an assumption.
Design for incremental change, not full loads
Full syncs were replaced with change-driven patterns: event subscriptions where available, timestamp and checksum-based change detection where not, plus batching, backoff and a scheduled full reconciliation instead of a nightly one.
Close the data-availability gaps explicitly
Fields absent from the Ethos model were handled by decision, not by workaround sprawl: extend where extension was supported, source from the owning system where one existed, or change the downstream process where the field was not genuinely required. Each gap was documented with its chosen route.
Make failures visible and replayable
A shared integration layer with correlation IDs, dead-letter handling, idempotent replay, reconciliation counts and alerting on drift — so integration problems surfaced in monitoring instead of at a service desk.
Retire the legacy interfaces in waves
Each replacement ran in parallel with its predecessor until record counts and field-level comparisons matched over a defined period, then the legacy interface was decommissioned and the register updated.
Outcomes
The nightly sync finished inside the window
Moving from full loads to change-driven syncs with measured batching brought the critical person and enrollment flows comfortably inside the overnight window, with headroom for growth.
Direct database reads against the SIS were retired
Every catalogued direct-database consumer was migrated to a governed interface or retired, which removed the program's stated SaaS blocker.
Integration failures became detectable
Correlation IDs, dead-letter queues and reconciliation counts replaced end-user reports as the primary way failures were discovered.
Upgrades stopped breaking downstream systems
With integration logic abstracted from the SIS and a documented interface register, patch and upgrade cycles no longer produced surprise downstream outages.
The institution's team owns the pattern
Standards, templates and the harder integrations were delivered by the pod; institutional developers built and now support the remainder.
What we would tell you before you start
- Measure Ethos throughput on real resources before committing to a design or a date. Assumed throughput is the most common source of blown integration estimates.
- Prefer change detection over full loads. Most window problems are a data-volume design choice, not a platform limit.
- Treat data-availability gaps as decisions with owners, not defects to be worked around quietly.
- Parallel-run with field-level reconciliation is the only credible basis for decommissioning a legacy interface.
- An interface register that nobody maintains is how a mission-critical report becomes invisible. Give it an owner.
Related reading
All insightsIntegrating Ellucian Banner and Ellucian Student with modern APIs: lessons from an Ethos-led program
The field report behind this engagement — where Ethos shines and where throughput stalls.
A strategy for migrating Ellucian Banner and Ellucian Student to SaaS
How integration readiness fits into a phased SaaS migration.
Talk with a principal about your integration estate
If Ethos throughput, a missing field or a wall of point-to-point interfaces is holding up a migration, we can tell you what it takes.