Building Blocks and the decade it defined in edtech

Introduction

In 2002, the operational reality of an integration looked like this: a campus systems administrator downloads a ZIP file from a vendor, opens the Blackboard administrative console in a browser window, uploads the package, grants a set of entitlements, and restarts the application server during a maintenance window. Ten minutes later, a new tool appears in a course menu. Faculty click it; a roster is read; a grade column is created; scores are returned. The machine room hums on the second floor of the library, a pair of load‑balanced application nodes behind a firewall, Oracle or SQL Server handling the data, and a help desk ready in case something surprises the evening section of Chemistry 101.

That sequence—mundane, repeatable, reversible—quietly set a decade of expectations for how edtech would work. Blackboard called the packaging model Building Blocks. Institutions called it “the plugin,” “the add‑on,” or simply “the thing we install.” Vendors learned to ship to it. Campuses learned to govern it. And the rest of the market adjusted to the behaviors it taught: who controls the install, where the data flows, and what a successful integration actually does when a student clicks.

Think of it as laying the campus plumbing—valves you can shut, pipes you can trace, gauges you can read—rather than wiring that disappears into walls. Building Blocks made the integration visible enough to trust and ordinary enough to standardize. Integrations are operational contracts.

Blackboard formed in 1998 from a combination of two small companies. We spent the early years solving a direct operational problem: give faculty a place to put a syllabus, a gradebook, and a discussion board online without making the IT department rewrite campus systems. The company went public on NASDAQ in 2004 as BBBB, but the integrations that would define a decade were shaped a few years earlier by on‑prem servers, campus change windows, and practical needs at scale.

The problem set campuses faced

Walk into a registrar’s office in 2001 and you would see three core systems governing the student experience: the Student Information System (SIS) running on a mainframe or midrange server, a directory service handling identity (often LDAP or Active Directory), and the first wave of content and course platforms sitting on Windows or Solaris machines in the campus data center. The job was to stitch them together without breaking anything students or faculty depended on.

Provisioning. Courses, users, and enrollments originate in the SIS on a schedule the registrar trusts. The Learning Management System (LMS) needs that data before the first day of class. The operational question: how do we move that data reliably without giving the LMS full control of the SIS?
Authentication and authorization. Single sign‑on meant reconciling campus identity with LMS roles. The operational question: where is the source of truth for “Instructor” versus “Teaching Assistant,” and how do entitlements map?
Content and activity. Tools proliferated. Plagiarism checking, homework platforms, and clickers emerged with their own clouds or servers. The operational question: where should the user click, and how should data flow back to the gradebook?
Audit and control. Institutions needed to know what changed, when, and by whom. The operational question: how do we add capability without losing the ability to reverse it or document it?

Lesson — Solve the most predictable and recurring operational problems first.

By 2002, campuses had a name for the provisioning side: Snapshot. Blackboard’s Snapshot utilities taught a habit of exporting flat files from the SIS and consuming them on a defined schedule. This was not elegant, but it was predictable. In integration work, predictability beats elegance when semesters start on Monday. The habit of reliable, scheduled data movement became foundational.

> In integration work, predictability beats elegance when semesters start on Monday.

The LMS sat in the center of this traffic. It was the place everyone already touched daily—faculty to post, students to submit, admins to configure. If a new vendor wanted attention, the fastest route to adoption was a button in the course shell that performed a task without forcing users to jump through new accounts, strange URLs, or duplicate rosters. That UI gravity pulled integrations into the LMS runtime. The shortest path to adoption runs through the course shell.

How Building Blocks emerged

Blackboard's early software was web software written in Java, served by application containers, and backed by relational databases. Institutions deployed it on‑prem, scaled it by adding nodes, and controlled it by policy and process. In that world, the practical way to add capability was to run code inside the same runtime and surface it through the same UI.

Building Blocks formalized this extension mechanism in the early 2000s. The idea was straightforward:

Package code, configuration, and metadata in a single distributable archive.
Declare where the extension wanted to appear in the system—admin tools, course tools, content handlers, or gradebook augmentations.
Request specific entitlements—named permissions the admin could grant or withhold.
Provide a lifecycle—install, enable, disable, upgrade, remove—under the admin’s control through the console.

The result was a repeatable ritual. Vendors shipped a ZIP; admins uploaded it; a new capability appeared in predictable places. The model carried two quiet commitments that mattered:

Campus sovereignty. Institutions retained installation control. No vendor changed the campus system without a person accepting the change.
Vendor certainty. Developers wrote to a defined set of services and UI patterns. If they adhered, their tool would feel “native,” and support calls would go down.

We did not have the vocabulary at the time for “platform economics” in education, and we did not need it. We had a backlog of campus asks and a growing set of third parties who wanted to meet them. An SDK, a permission model, and a UI placement map were enough to build momentum. Make the extension predictable and people will use it.

What the API actually did

Outside marketing language, a Building Block did five operational things well enough to become habits:

1) Tool placement and UI extension. A vendor could register a placement—show up as a course tool, an admin panel, a content type in the “Add Content” menu, or a column action in the gradebook. The placement decision shaped user behavior. Put a plagiarism checker where assignments live, and usage follows the assignment workflow.

2) Data access consistent with entitlements. Once installed and enabled, the integration could read rosters, course metadata, user roles, and gradebooks within the constraints the admin allowed. The entitlement list served as both governance and documentation for security reviews.

3) Content and grade creation. The most powerful behavior was the ability to create durable records in the LMS: a content item, a deep link, a gradebook column with defined semantics, and a score posted back to the right student against the right column. Creating a column and faithfully returning a value is the heart of assessment integrations.

4) Event observation. The system emitted events—course copy, content create, assignment submit—and integrations could observe or react. This allowed background work that felt like part of the system rather than an external batch process.

5) Configuration and call‑outs. Vendors needed to speak to their own services. Building Blocks provided a place for secure credentials, per‑tenant configuration, and traceable outbound calls.

Lesson — A stable API makes its core jobs—placement, permissions, and data return—feel native.

The packaging model mattered as much as the services. Installing a Building Block meant uploading one file, reviewing a manifest of capabilities, and granting entitlements. Upgrading and removing followed a similar visible process, leaving an audit trail. This visibility gave risk officers and CIOs a governance object they could manage. Institutions could pilot a new tool and either expand or remove it without downtime.

The integration economy it created

Once the extension model stabilized, categories formed quickly.

Assessment integrity. Turnitin and SafeAssign (which Blackboard later acquired) integrated where assignments lived. Faculty clicked “Enable plagiarism checking” in an assignment workflow; reports returned as part of grading.
Lecture capture. Echo360, Panopto, and others placed tools in course menus and content areas. Recordings were linked with course context.
Publisher homework. Pearson MyLab, McGraw‑Hill Connect, and Cengage platforms mapped assignments and scores to gradebooks, with grade return as the central function.
Clickers and response systems. i>clicker and similar tools lived alongside attendance and assessment workflows, requiring roster matching and grade export.
Video and media. Kaltura and others attached to content creation flows and permissioned media libraries on a course‑by‑course basis.

Each category adopted the same verbs: place a tool, configure it, match a roster, create a grade column, and return scores. Procurement followed. Institutions learned to ask vendors practical questions—Where does it appear? What permissions does it need? How does it grade?—because the Building Blocks model turned those into a standard checklist.

> A predictable ritual creates a market.

Support and services adjusted, too. Implementations became shorter not because they were simple, but because they were routinized. A known admin path (install → configure → pilot → expand) replaced custom projects. The norms were not just technical; they were institutional. The plugin ritual sat in the middle, holding the process together because it was visible and reversible.

How standards responded and absorbed

Standards rarely lead in operational domains; they codify working patterns once enough practice exists to make convergence useful. The Building Blocks era supplied that practice.

SCORM 1.2 (2001) and SCORM 2004 (2004) already defined content packaging and run‑time data exchange, but this was about content portability, not deep tool integration.
IMS Enterprise and early provisioning specs informed roster sharing, but campuses kept using Snapshot flat files because they were dependable and fit institutional control.
In 2010, IMS ratified LTI 1.0. Its verbs looked familiar: launch a tool from the LMS with context, identify the user with roles, and provide a channel for outcomes (grades) to return. LTI moved these behaviors across the network instead of inside the application server.
LTI 1.1 (2012) stabilized outcomes; LTI Advantage (2018 onwards) consolidated Names and Roles Provisioning (NRPS), Assignments and Grades, and Deep Linking. The similarities to the earlier plugin model were not accidental.

Lesson — Standards emerge by codifying habits already formed in daily operations.

LTI did for the web what Building Blocks did for the JVM: it named the verbs and made them dependable for vendors and campuses. The a standard cut across LMS products—Blackboard Learn, Canvas, Moodle, D2L Brightspace—so vendors could write once and reach many. Yet institutions kept the governance pattern: admin‑level control to enable, course‑level placement, and clear grade semantics. The proprietary model let practice form quickly, while the standard absorbed the stable parts for the wider market. Where Building Blocks taught “install inside,” LTI taught “launch outside, but behave the same.”

Governance, security, and the admin switch

The most important feature of Building Blocks was not a method or a class; it was the admin’s switch. The right to install, enable for some or all courses, set entitlements, and reverse the decision became an institutional expectation. Risk and security teams built their own rituals around that switch: review the manifest, confirm data flows, check logs, and test the uninstall process.

> The admin switch is the real API.

Security in the 2000s took a different shape. On‑prem deployment meant institutions controlled network boundaries. A Building Block’s “phone home” behavior had to pass through outbound firewall rules. Credentials sat in campus‑controlled stores, and logs lived on campus disks. The plugin model was reassuring: the extension lived where the rest of the LMS lived, subject to the same guardrails.

Lesson — The most important feature is an administrator's ability to grant, and revoke, control.

This centralized control offered fast adoption and a clear audit trail. That reassurance had costs. Version drift could break extensions when the LMS was upgraded. Poorly written extensions could slow the system for everyone. But the core benefits gained more than what was lost. When multi‑tenant SaaS arrived, institutions asked for the same experience—authorization scopes, per‑tenant configuration, and on/off switches—even if the runtime and network topology changed.

What persisted into the cloud era

When LMSs moved from campus‑hosted nodes to vendor‑hosted clouds, three Building Blocks behaviors held their shape.

Verbs, not endpoints. Integrations speak in actions users understand: launch a tool, read a roster, create a grade column, return scores, and copy course content with links intact. Whether a Java call or an HTTP call, those verbs anchor expectations.
Entitlements at install time. Admins expect to see explicit permission requests—roster read, grade write—and to decide whether to grant them. In OAuth terms, this became scopes and consent.
Per‑tenant configuration and reversibility. Institutions want to connect their LMS tenant to a vendor tenant with secrets they control and a switch they can flip. They expect logs and the ability to remove an integration without breaking courses.

> Verbs that users feel beat APIs that engineers admire.

LTI Advantage aligned with these principles. Deep Linking mirrored “content handlers,” Names and Roles mirrored roster reads, and Assignments and Grades mirrored gradebook column creation. A fourth persistence is subtler: grade semantics as product design. Returning a score is never just a number; it carries meaning that both LMS and tool must respect. The Building Blocks era trained vendors to treat grading as a contract.

Finally, procurement and support stayed anchored to the same questions. Security questionnaires still start with: What appears where? What permissions are required? How does grade return behave? Institutions still score integrations on operational clarity.

The technical debt and the tradeoffs

History earns perspective when you admit what did not work as well as what did. Building Blocks carried tradeoffs that the field learned to manage.

Version coupling. Extensions compiled against a specific LMS version could break on upgrade. The antidote was discipline: clear deprecation paths and campus staging environments.
Visibility across systems. Inside‑the‑LMS code hid network‑level issues but surfaced runtime ones. In the cloud, the reverse is often true.
Performance surface. Poorly written extensions could degrade the user experience for everyone on the node. Vendors learned to offload heavy tasks.
Data ownership expectations. Because the plugin lived inside the LMS, some assumed data never left, but license checks and content retrieval always sent data across the wire. Clear documentation and contracts reduced surprises.

Notably, many of these pain points became design inputs for LTI and for cloud‑era LMS architectures. Stronger versioning, signed launches, and granular scopes all reflect lessons learned in the earlier model. Yesterday’s pain becomes tomorrow’s spec.

The human pattern beneath the code

Underneath every technical architecture is a governance pattern. Building Blocks worked because it respected roles people already had and gave them objects they could manage.

The campus admin. Installation, entitlements, and reversibility preserved institutional control. The admin’s calendar became the real deploy pipeline.
The instructor. Tool placements aligned with mental models: content lives here, assignments live there, grades live in the gradebook. An integration that matched those models won adoption.
The vendor product team. A defined runtime, a list of entitlements, and UI contracts reduced guesswork, lowering the cost of supporting many institutions.
The CIO and risk officer. A manifest and an audit trail made new capabilities governable. The admin switch made risk reversible.

This is why the model traveled beyond Blackboard. When WebCT merged with Blackboard in 2006, its PowerLinks extension framework found similar rhythms. When Canvas and D2L grew, they leaned into LTI and then added their own augmentation points. The operational pattern had already trained the market. Integration patterns last because people learn them.

What I’d insist on now

If I were building an integration or a platform capability today, I would take the Building Blocks lessons as axioms and tune them for the cloud:

Treat LTI Advantage as your public face. Make Deep Linking the way content enters courses; rely on NRPS for rosters; send grades through the Assignments and Grades service. Focus on user‑visible verbs.
Keep a console‑grade admin experience. Present scopes and entitlements in plain language. Let admins pilot at department or course levels. Keep an obvious uninstall and data retention story.
Make grade semantics explicit. Name the scale, the maximum, and late policy handling. Document how retakes and extra credit behave.
Design for per‑tenant secrets and keys. Treat key rotation as a feature. Surface status and logs so admins can diagnose without opening a vendor ticket.
Build for course copy and lifecycle. Ensure links survive copy and that assignments carry context.
Price in the governance. Assume security review and accessibility testing. Your fastest sales motion is a frictionless audit.

From a platform owner’s perspective: keep the admin switch front and center, keep the verbs legible, and invest in documentation that turns operations into checklists. The more reversible you make change, the more change institutions will accept.

The bet I’d make today

The integration market is still, at its core, about pipes and valves—flow that must be traceable, controllable, and accountable. Building Blocks taught higher education how to run those pipes inside the LMS. LTI taught us how to run them across clouds. The work now is to keep the verbs stable while we improve the edges: better analytics, richer states, and safer credentials.

If you run a campus stack, keep your procurement and governance tied to the operational questions that mattered in 2002 and still matter now: What appears where? Who can do what? What flows to whom? How do we reverse it? Those questions are not conservative; they are enabling. They let you add capability without losing control.

If you build tools, assume institutions will live with patterns they trust for a long time. Adopt LTI deeply, treat administrative control as a feature, and make grade semantics boringly reliable. Ship with a clear uninstall story. You will go faster because you have reduced fear.

The metaphor holds for a reason. Good plumbing disappears during the day and proves itself at night when the system is under load. In the early 2000s, we sweated valves, gauges, and service loops because that is what made campuses willing to add new lines. Do the same at web scale and the field gets the same benefit: faster adoption with fewer surprises.

Building Blocks: the API that quietly defined a decade of edtech