Why federation matters here
Research institutions hold data with real consequences. Patron borrowing history, researcher grant submissions, unpublished manuscripts, deposit metadata for embargoed outputs — some of this is personal, some of it is commercially sensitive, all of it lives under institutional governance that does not always trust a foreign-jurisdiction cloud tenant.
The pragmatic answer is not “we will store it wherever you want and worry about consequences later”. It is a deliberate split. Some services run best Accadema-hosted because the operational burden of self-hosting them is high and the data is low-sensitivity. Some services run best client-hosted because the institution has clear data-residency or sovereignty requirements. Some run either way depending on the institution.
The federation is not a deployment option. It is the model. Trying to retrofit it onto a monolith is what other vendors are still doing.
From the architecture review, October 2024What stays Accadema-hosted, always
A short list of services that benefit from operating centrally:
- Identity and access management — one auth surface for the whole ecosystem, federated to each tenant’s identity provider but operationally central.
- Monitoring and alerting — running these centrally is the only way the operations team can act on a regional incident before the institution notices.
- Cross-tenant analytics — anonymised, aggregated, never per-institution-visible to other institutions.
What can be client-hosted
The library system, the repository, the research information system, the publishing engine and the kiosk console are all packaged so an institutional IT team can run them on their own infrastructure if they choose. They get the same release cadence as Accadema-hosted instances, the same monitoring agents, the same upgrade paths.
The trade-off is honest: a client-hosted deployment puts more operational responsibility on the institution’s IT team. We do not pretend otherwise. We do publish the runbooks, the monitoring dashboards and the support escalation paths so the responsibility is bounded and predictable.
How upgrades flow either way
Releases are produced from a single line. Accadema-hosted instances are upgraded by us, on a published cadence, with feature flags to ramp risky changes gradually. Client-hosted instances pull the same release artefact when their change-management window allows. The version skew between Accadema-hosted and client-hosted deployments is bounded: no instance lags more than two release cycles before it shows up as a non-compliance event in the operations dashboard.
Why two cycles and not infinite? Because federation only works if the ecosystem can assume a known surface area across all participants. Cross-module integrations would fracture otherwise — the analytics module cannot interpret data from a CRIS that is three releases behind.
The boundary that holds it all together
The thing that makes federated SaaS feel like one product is not technology. It is a contract: every module exposes the same shape of API regardless of where it runs. The client of an integration does not know — and does not need to know — whether the module on the other end is hosted by Accadema, by the institution, or by a partner.
That contract is enforced by the test suite, the upgrade discipline, and the architectural boundary the team has held since the project started. It would have been faster, in the short term, to write a monolith. It would also have been the wrong product to ship.
