Post Syndicated from Oleg Polianski original https://aws.amazon.com/blogs/architecture/how-uts-established-a-modern-curriculum-data-services-foundation-on-aws/
Students and staff experience the University of Technology Sydney (UTS) as a single institution, not as the collection of curriculum and student systems behind it. They expect the information underpinning teaching, learning, course design and institutional decision-making to be accurate, timely and coherent, irrespective of its source.
Behind that experience, UTS had reached a natural inflection point in its integration landscape. Critical teaching and learning capabilities relied upon established vendor platforms with disparate data models, interfaces, stability profiles and scaling characteristics. Although those platforms continued to perform essential operational functions, integrating and operating the surrounding estate had become progressively more intricate and costly.
UTS’s purpose remained constant: excellence in teaching, learning and the student experience. Technology exists to advance that purpose, not to supplant it. UTS Information Technology Unit (ITU) therefore sought to remove impediments between authoritative data and the people, processes and digital services that depend upon it.
UTS made that transition practical with AWS. With managed, elastic and serverless capabilities, UTS reduced undifferentiated operational effort and improved fault tolerance. This established a sustainable model for governed data services. Curriculum became the first bounded business domain in which UTS applied that model.
The challenge
UTS ITU required an architecture that could:
- Make authoritative curriculum information available through reusable services without displacing the Curriculum Management System, a third-party software as a service (SaaS) application, as the system of record.
- Replace tightly coupled, consumer-specific interfaces with governed contracts that insulate consumers from source schemas and implementation detail.
- Accommodate routine change and transient high-volume activity, including complete domain reloads, without permanently provisioned capacity.
- Support graph traversal across deeply nested and inverse curriculum relationships, exact and full-text retrieval, and semantic discovery from the same authoritative source.
- Operate reliably and economically within finite engineering capacity whilst establishing a repeatable pattern for subsequent data domains.
Domain boundaries were non-negotiable. Curriculum describes what the university teaches and remains the responsibility of the Curriculum Management System. Preserving that bounded context prevents ownership, validation and governance from migrating into non-authoritative services.
A domain-oriented approach
UTS ITU organised the capability according to domain-driven design. Rather than aligning data services with the applications that produce or consume data, they aligned them with:
- the business domains defined in CAUDIT’s Higher Education Reference Model (HERM).
- the information for which those domains are accountable.
Each data product has explicit ownership, consumers, quality expectations, interface contracts and lifecycle management. Institutional data is therefore treated as a governed asset designed for reuse, not an incidental application by-product.
Declarative architecture as code provides the executable realisation of the design and a reproducible source of truth. Configuration is separated from implementation where practicable, delivery is automated and managed AWS services are preferred to bespoke infrastructure software. The discipline is “just enough code”: engineering effort focuses on building differentiated domain logic (the business rules and data services unique to higher education) rather than undifferentiated infrastructure.
Stateless execution, asynchronous communication, purpose-built persistence and independently recoverable components avoid a tightly coupled failure domain. Consumption-based services align expenditure with workload demand instead of maintaining an estate permanently sized for intermittent peaks.
Solution overview
The architecture comprises five layers: edge, ingestion, persistence, application and business logic, and interface. Each layer has discrete responsibilities, as shown in Figure 1.
Identity, encryption, network controls, observability and operational governance apply across the stack. Curriculum data services capture complete changes from the Curriculum Management System as events, preserve them in a durable event log, materialise purpose-built representations and expose governed synchronous and asynchronous services.
Figure 1: UTS curriculum data services layered architecture
The next five sections examine each layer of the realised architecture in turn.
Edge layer
The edge layer is the controlled ingress boundary between the SaaS Curriculum Management System and the curriculum domain. Its remit is deliberately narrow: receive a complete curriculum change, establish the internal event contract and submit it to the ingestion layer with minimal processing.
The source system sends change events to an Amazon API Gateway HTTP API, which invokes an AWS Lambda function acting as a technical adapter because no suitable managed connector satisfies the source system’s proprietary API contract and payload format (for example, vendor-specific REST endpoints, authentication schemes, and data structures). The adapter encapsulates the complete vendor event in a CloudEvent envelope, appends UTS operational metadata and publishes it to the appropriate Amazon Managed Streaming for Apache Kafka (Amazon MSK) Serverless topic.
The edge neither reinterprets curriculum nor performs validation or consumer-specific transformation. Validation remains within the system of record. This preserves source fidelity, prevents downstream concerns from contaminating the ingress boundary and allows the stateless edge to scale automatically during complete domain reloads.
Ingestion layer
Amazon MSK Serverless forms the durable, append-only event backbone. Curriculum changes are segregated into domain-aligned topics by academic item type, retaining the complete source event whilst allowing independent consumers to progress, retry and recover without obstructing one another.
MSK Serverless scales on demand. Routine changes consume little capacity. A domain reload fans out across the event backbone and parallel processors, then contracts after completion. Model or schema changes can be accommodated through idempotent reprocessing or a complete reload, without introducing a second curriculum authority.
Persistence layer
The persistence layer uses purpose-built data services selected according to the access patterns and business questions each representation must support. Amazon Neptune Serverless stores curriculum structures and inverse relationships as a property graph, whilst Amazon OpenSearch Service stores complete source documents and indices for exact, full-text and vector retrieval.
In Neptune, programmes of learning, areas of learning and units of learning are connected academic items. Consumers can traverse from a programme to its constituent structures or begin with a unit and identify every programme and area through which it is taught. These inverse enquiries are native graph traversals rather than application-specific joins repeatedly reconstructed by consumers.
Figure 2: Curriculum structures relationships in Amazon Neptune
OpenSearch provides exact lookup, filtering and document retrieval alongside k-nearest-neighbour vector search. Selected data processors implemented as AWS Lambda functions invoke an embedding model through Amazon Bedrock and append vector representations of relevant curriculum text before persistence. Curriculum can consequently be discovered by semantic proximity rather than lexical coincidence. UTS also validated multilingual retrieval against English-language curriculum content.
Neptune and OpenSearch are independently and eventually consistent. Failure of one materialisation doesn’t block another, and neither store is exposed directly to consumers. Both are disposable projections rather than competing systems of record and can be reconstructed from the Curriculum Management System through a complete reload. Data is encrypted with a dedicated domain AWS Key Management Service (AWS KMS) key whose use is restricted to authorised domain services.
Applications layer
The applications layer converts those materialisations into reusable domain capabilities. Dozens of narrowly scoped Lambda-backed services query Neptune or OpenSearch, whilst persistence remains private and is exposed solely through governed contracts.
Amazon EventBridge Pipes acts as a set of transport adapters between MSK Serverless and the Lambda functions acting as processors and services consuming the event stream. Pipes provide routing and delivery, not curriculum validation, enrichment or business transformation, keeping processing responsibilities explicit, independently deployable and observable.
Stateless Lambda function execution allows services to scale with demand and recover independently through retries and re-invocation. Signature Version 4 (SigV4) authentication and fine-grained AWS Identity and Access Management (IAM) roles provide least-privilege access to Amazon Neptune and Amazon OpenSearch Service without distributing or managing database credentials. The services provide authoritative retrieval, graph traversal and semantic discovery without transferring responsibility for curriculum validity into the data domain.
Interface layer
The interface layer provides pull-based access through REST and GraphQL and push-based delivery of domain events, whilst keeping persistence and implementation private. Amazon API Gateway supplies the REST boundary. AWS AppSync provides GraphQL access to frequently consumed capabilities with attribute-based access control at schema level. Both interfaces invoke the same governed service contracts.
Approved consumers might also receive curriculum events in the internal CloudEvent envelope. Amazon EventBridge Pipes manages last-mile delivery without bespoke routing middleware, and consumers determine which academic item events are relevant rather than UTS maintaining a filtered stream for each consumer.
Amazon Cognito authenticates approved external consumers through OAuth 2.0 and OpenID Connect, whilst AWS native workloads use IAM. AWS Key Management Service, AWS Secrets Manager, AWS WAF, and AWS Certificate Manager provide encryption, secrets management, perimeter protection and certificate lifecycle management. Amazon Route 53 supplies naming for a single shared vanity domain, and Amazon CloudWatch and Amazon Simple Notification Service (Amazon SNS) provide observability, telemetry and targeted alerting across the architecture.
Full solution architecture
The following diagram shows the complete solution architecture, including the identity, encryption, network, observability and governance controls that apply across all five layers.
Figure 3: End-to-end architecture of the curriculum data services solution
Results and measurable outcomes
The outcome isn’t a replacement for the Curriculum Management System as the system of record. It’s a governed data foundation that leaves the system of record authoritative whilst making curriculum information reusable through APIs, graph traversal, semantic search and event delivery. Since the production launch in November 2024, the domain has recorded zero production incidents.
- Latency – Changes become available to downstream consumers in an average of 1.6 seconds from crossing the edge layer, through synchronous and asynchronous interfaces.
- Curriculum graph – The domain models 43,794 relationships across approximately 800 programs of learning, 3,500 units of learning and 2,500 areas of learning.
- Consumer adoption – 11 institutional consumers have adopted the services, replacing bespoke point-to-point integrations with reusable, governed contracts.
- Operational footprint – One engineer operates the domain. Managed, serverless and self-healing components make routine intervention negligible and remove the need for dedicated Level 3 support.
- Cost efficiency – UTS achieved a material reduction in the total cost of ownership of curriculum data integration and delivery, consolidating capabilities previously spread across commercial products, bespoke integrations, databases and multiple support teams.
- Availability and resilience – The platform operates continuously and has maintained downstream access to trusted curriculum information when the upstream system of record was unavailable.
Collectively, these outcomes show how a small engineering contingent can operate an institutional-scale data domain using managed AWS services, whilst increasing capability, reducing operational complexity and aligning expenditure with demand.
What’s next
The curriculum domain validated the production architecture and operating model. The student data domain followed, providing a single governed point of access for student profiles, admissions, offers, enrolments and related information. UTS is now preparing the learning activities domain, a substantially larger capability built around a lifelong learner graph using Amazon Neptune and Amazon Neptune Analytics, extending the same domain-driven pattern across the teaching and learning landscape.
Each bounded context can select the AWS services appropriate to its business questions whilst retaining common controls for identity, security, observability, delivery and operational sustainability.
Conclusion
UTS’s integration landscape had reached the point at which cumulative complexity and operational overhead constrained institutional change. The response was not technology for its own sake. UTS ITU used AWS to remove the impediments between authoritative institutional data and the teaching, learning and administrative capabilities that depend upon it.
The significance of AWS extended beyond technology selection, but the outcome was principally an architectural and operating-model achievement by UTS. Curriculum data services became UTS’s first production data domain. UTS combined domain-driven design, asynchronous processing, purpose-built persistence and governed interfaces with managed AWS capabilities that made those patterns practicable at institutional scale.
The resulting service foundation supports event streaming, graph traversal, document and semantic retrieval, compute, identity, security and governed data exposure. UTS operates it without a conventional infrastructure estate. This allowed UTS ITU to convert an ambitious architectural design into a sustainable production capability whilst keeping engineering effort concentrated on domain services rather than undifferentiated infrastructure.
Curriculum data services embody the resulting transition: from a burdensome integration model to a domain-aligned data foundation that’s reusable, resilient and operationally sustainable. UTS now possesses a repeatable model through which institutional data can be treated as a strategic asset rather than a by-product of individual systems. The university will continue to operate many systems. Students and staff should never experience the boundaries between them.
For more information or support, contact the AWS Public Sector team.