How to Build Template 9: EdTech LMS Platform

How to Build Template 9: EdTech LMS Platform

This template shows how to model an EdTech / Learning Management System (LMS) platform at the System Context level. It helps explain how the platform serves three distinct populations — learners, instructors, and institutions — while integrating with identity systems, content repositories, proctoring services, and student record systems that are often outside the platform's direct control.

EdTech is one of the most stakeholder-complex domains in software. The person who uses the product daily (the student) is rarely the person who pays for it (the institution) and often not the person who configures it (the IT administrator). The person who creates the learning experience (the instructor) operates under constraints set by the institution (approved content, mandated outcomes, grading policies) and external bodies (accreditors, government curriculum standards). This multi-stakeholder structure shapes the architecture in ways that go far beyond feature sets — it determines who owns data, who controls access, what integrations are non-negotiable, and how compliance obligations are distributed across the system.

What This Template Shows

• Three distinct user populations — students, instructors, and institution administrators — with different goals, workflows, and data access requirements
• The platform as a learning experience orchestrator that depends on external systems for identity, content, assessment, communication, and record-keeping
• External integrations that are often non-negotiable in institutional EdTech: school identity providers for SSO, Student Information Systems for roster management, proctoring services for assessment integrity, and Learning Record Stores for xAPI compliance
• The content licensing boundary that separates publisher-supplied curriculum from instructor-created materials

This is the right level when you want to explain the educational system landscape and the institutional constraints that shape the product before modeling course delivery services, assessment pipelines, or analytics infrastructure.

Embedded Diagram

Why This Context Diagram Works

The most important architectural signal in an LMS context diagram is that the platform serves multiple principals who are not always aligned. A student wants a smooth, self-paced learning experience. An instructor wants granular control over how content is presented and assessed. An institution wants compliance with accreditation requirements, data governance policies, and IT security standards. A third-party content publisher wants to protect the intellectual property of licensed curriculum materials. These are not the same goals, and they do not produce the same architectural requirements.

The diagram makes four critical structural signals visible:

The institution controls the identity boundary. In most institutional EdTech deployments, students and instructors do not create platform accounts independently — they are provisioned through the institution's Student Information System and authenticate via the institution's identity provider. The platform does not own the user. The institution does. If a student is unenrolled, their access must be revoked automatically. If an instructor leaves, their account must be deactivated through the HR system. The LMS is a Service Provider in the institution's SSO configuration, not an independent identity authority.

The Student Information System is the source of truth for enrollment. The platform does not decide which students are in which courses. The SIS does. Enrollment data flows from the SIS into the LMS through LTI (Learning Tools Interoperability) provisioning, IMS Global's OneRoster standard, or direct API integration. Course sections, instructor assignments, academic calendar dates, and student demographic data all originate in the SIS. A manual enrollment workaround that bypasses SIS synchronization creates data consistency problems that propagate to grade reporting, accreditation records, and financial aid verification.

Proctoring is a policy enforcement layer, not just a feature. Online proctoring changes the architecture because it introduces an external system that must intercept and monitor the assessment experience. The proctoring service integrates with the LMS at the assessment level — when a student begins a proctored exam, the LMS hands off to the proctoring service for identity verification, environment lockdown, and monitoring. The proctoring service returns a monitoring report that feeds into the instructor's grade review workflow. This means the proctoring service is in the critical path for high-stakes assessments, and its availability and reliability directly affect the student experience during exams.

Content licensing creates a distinct access control boundary. Licensed content from publishers (Pearson, McGraw-Hill, OpenStax, LinkedIn Learning) is governed by licensing agreements that determine which students can access which materials and for how long. Publisher content is typically delivered through LTI integrations — the student authenticates to the LMS, the LMS generates an LTI launch request with the student's enrollment context, and the student is seamlessly redirected to the publisher's content delivery system. The content never lives in the LMS itself. This architecture protects publisher IP, but it also means the LMS has limited control over publisher content reliability and access.

Core Elements To Include

People

Student The primary learner and the most frequent user of the platform. Students access course materials (readings, videos, interactive content), complete and submit assignments, take quizzes and exams, participate in discussion forums, communicate with instructors, view their grades and feedback, and track their progress toward course and program completion. In higher education contexts, students often have mixed motivations — they are managing the LMS alongside part-time work, extracurricular activities, and personal responsibilities. The platform must be accessible on mobile devices with intermittent connectivity, must provide clear progress indicators, and must send timely notifications for deadlines and grade releases. In corporate learning contexts, students are employees completing mandatory compliance training or optional professional development — their primary motivation is often completion efficiency rather than deep engagement.

Instructor Responsible for designing the learning experience and facilitating the course. Instructors create or assemble course content (uploading files, creating assignments, embedding publisher content via LTI, recording or embedding video lectures), configure the gradebook and grading rubrics, review and grade student submissions, facilitate discussion forums, communicate with students via announcements and direct messages, manage the course calendar, and report grades to the institution. In a university context, instructors may be tenured faculty with full course design authority, or adjunct instructors working from a centrally mandated course template with limited customization rights. In a corporate context, instructors are often instructional designers creating courses for a learner audience they never interact with directly.

Institution Administrator The institutional owner of the platform deployment. Institution administrators manage the LMS at the organizational level: configuring the SSO integration with the school's identity provider, managing the SIS data sync, setting institution-wide policies (what external tools are approved for LTI integration, what proctoring provider is contracted, what data retention policies apply), managing instructor and administrator accounts, and accessing institution-level reporting for accreditation and compliance purposes. For large universities, the institution administrator role may be distributed across a central IT team (infrastructure and integrations) and a teaching and learning center (pedagogical configuration and instructor support). The institution administrator's access to student data is governed by FERPA (Family Educational Rights and Privacy Act in the US) and equivalent national regulations.

Main System

Learning Management Platform The central system that delivers the learning experience. It manages course structure and content, orchestrates the assignment and assessment lifecycle from creation through grading and grade reporting, maintains the gradebook as a source of truth for assessment results, facilitates communication between students and instructors, tracks learner progress and engagement, and provides reporting for students (progress dashboards), instructors (course analytics), and administrators (institution-wide outcomes reporting). The LMS also manages the integration surface — LTI integrations with publisher content and external tools, xAPI statement forwarding to the Learning Record Store, and grade passback to the SIS when final grades are submitted.

External Systems

School Identity Provider (Shibboleth / Azure AD / Google Workspace Education) The institution's identity and directory system is the source of truth for user identity. In higher education, Shibboleth (via the InCommon Federation) is the dominant SAML identity provider — it allows university students to authenticate to the LMS using their university email and password without creating a separate account. In K-12 contexts, Google Workspace for Education and Microsoft 365 for Education (with Azure AD) are the standard identity providers. The LMS must be configured as a SAML Service Provider or OIDC Relying Party for the institution's IdP. When an institution switches identity providers, the LMS integration must be re-configured. For direct-to-consumer EdTech products (Coursera, Udemy), institutional SSO is replaced by social login or email-based authentication, significantly simplifying the identity model.

Video Conferencing Platform (Zoom / Microsoft Teams / Google Meet) Synchronous instruction and virtual office hours are core to blended and online learning programs. The LMS must integrate with the institution's contracted video conferencing platform so instructors can schedule and launch virtual class sessions from within the LMS course context, students can join from the course page without managing separate meeting links, and attendance data can flow back to the LMS gradebook. Zoom LTI Pro, Teams for Education, and Google Classroom integrations are all standard in the higher education market. The video conferencing platform is also where recorded lectures originate — recordings must be made available in the LMS course page, either directly or through a video management platform like Kaltura or Panopto.

Online Proctoring Service (Honorlock / Proctorio / Respondus) Online proctoring introduces an external system into the assessment flow. For proctored exams, the LMS integrates with the proctoring service via LTI: when a student begins the exam, the LMS launches the proctoring tool in a new browser tab, the proctoring service verifies the student's identity (typically through webcam photo comparison to a government ID), locks down the browser (preventing access to other tabs, applications, or websites unless permitted by the exam configuration), and monitors the session for suspicious behavior (unusual eye movements, unexpected sounds, multiple people detected by the camera). The monitoring data is processed by the proctoring service (either live human monitoring, AI-based automated flagging, or a combination) and a monitoring report is delivered to the instructor after the exam, who reviews any flagged incidents before releasing grades. Proctoring is controversial — student privacy advocates raise concerns about the surveillance nature of webcam and audio monitoring, which is an ongoing policy debate with architectural implications.

Content Licensing Repository (Pearson / McGraw-Hill / OpenStax / LinkedIn Learning) Publisher-supplied curriculum is delivered through LTI integrations. An instructor adds a publisher's chapter or module to their course by configuring an LTI link; when a student clicks it, the LMS generates an LTI launch that authenticates the student to the publisher's platform and redirects them to the licensed content. The publisher's platform enforces access control based on the institution's licensing agreement — students with valid enrollment context can access the content; others cannot. Grade data from publisher assessments can be returned to the LMS gradebook via LTI Advantage Deep Linking and Assignments and Grades services. OpenStax provides free, openly licensed textbooks through a similar LTI mechanism. LinkedIn Learning provides professional development content accessible to institutions through a site license.

Student Information System (Ellucian Banner / PeopleSoft / PowerSchool) The SIS is the authoritative record of institutional academic data: student enrollment and registration, course sections and instructor assignments, academic calendar, degree program requirements, and official grade records. Data flows from the SIS to the LMS via OneRoster API, SIS-specific integration connectors, or IMS LTI Advantage provisioning. When a student registers for a course in the SIS, they are automatically provisioned in the LMS course section. When the academic term ends and grades are submitted in the LMS gradebook, the final grades are passed back to the SIS for the official academic record. The SIS integration is often the most technically complex part of an institutional LMS deployment because legacy SIS platforms (Banner, PeopleSoft) have complex data models and limited API support, requiring custom integration work.

Learning Analytics / LRS (xAPI / SCORM Cloud / Learning Locker) The Learning Record Store (LRS) is the standardized repository for xAPI (Experience API, formerly Tin Can API) statements — a standardized format for recording learning activity data. xAPI statements follow a subject-verb-object structure: "Student Jane completed Lesson 3 with a score of 85%," "Student John watched 75% of the lecture video," "Student Maria opened the textbook chapter on Tuesday at 9 PM." The LRS collects these statements from the LMS, from LTI-integrated content, and from external learning experiences (mobile apps, simulations, standalone tools). The aggregated xAPI data enables learning analytics that cross tool and experience boundaries — something that SCORM (the older e-learning standard) could not do because SCORM data was siloed within a single LMS. SCORM Cloud supports both SCORM and xAPI content delivery; Learning Locker is an open-source LRS for institutions that want to own their learning data.

FERPA and Student Data Privacy

FERPA (Family Educational Rights and Privacy Act) is the US federal law governing student education records. It grants students the right to access their own records, the right to request corrections, and the right to control disclosure to third parties. For LMS platforms deployed in US institutions, FERPA has direct architectural implications:

• Third-party tools integrated via LTI must operate under the institution's FERPA authority — the institution takes responsibility for ensuring the tool handles student data appropriately. This makes the process of approving new LTI integrations a compliance function, not just an IT function.
• Student data cannot be used for commercial purposes by the LMS vendor without explicit consent — student behavioral data collected by the LMS cannot be used to train commercial advertising models or sold to third parties.
• Parents of minor students (in K-12 contexts) have FERPA rights until the student turns 18 — this changes the access control model for the institution administrator and the student portal.
• Data export and deletion requests must be supported — if a student requests their data or requests deletion, the platform must be able to fulfill those requests across the full data model.

How To Adapt It

You can adapt this template for different EdTech contexts:

• Higher education LMS: Keep the full shape as described. SIS integration, institutional SSO, and accreditation reporting are all essential.
• Corporate learning platform: Remove institutional SSO (replace with corporate SAML/OIDC SSO via Okta or Azure AD), remove the SIS (replace with HRIS integration for employee provisioning), and replace accreditation reporting with compliance completion tracking.
• Certification and assessment products: Expand the proctoring and assessment integrity workflows. Add a credential issuance system (digital badges via Credly, digital certificates) as an additional external system.
• Direct-to-consumer EdTech (Coursera, Udemy): Remove the institutional SSO and SIS integrations entirely. Replace institutional billing with consumer subscription billing. Add creator monetization and royalty management tools.

If your product is exam-heavy, expand the proctoring and assessment integrity workflows and add a question bank management system as an additional external system. If your platform is live instruction-focused, expand the video conferencing integration into a dedicated virtual classroom platform.

When To Use This Template

Use this template when you need to explain:

• who the platform serves beyond students, and why instructor and institution administrator are structurally different actors with different authority and different data access requirements
• how institutional systems — SIS for enrollment, IdP for identity — constrain the platform's data model and integration architecture
• why content licensing and proctoring belong in the architecture as external system dependencies with their own SLAs, contracts, and failure modes
• where roster data, identity, grade passback, and accreditation reporting boundaries live — and why all of them trace back to the institution rather than the platform
• how FERPA and equivalent student data privacy regulations shape what the platform can and cannot do with student data
• why LTI and xAPI are not just integration standards but architectural boundaries that define where data lives and who controls it