I spent years thinking about curriculum as content — topics to cover, videos to produce, exercises to write.
Then I started building software systems at Armstrong Education, and something clicked: a curriculum is an architecture problem, not a content problem.
Both have:
Most curricula are built like a monolith — everything is coupled. Change one topic and you have to rewrite three lessons. Add a new module and the learning path breaks.
Software has solved this with microservices. We applied the same idea: every lesson is self-contained. It has defined inputs (what the learner must know before), defined outputs (what they can do after), and no hidden dependencies.
Now we can swap, update, or reorder lessons without touching anything else.
Software engineers write tests. Instructional designers... review? Hope?
We introduced learning outcome validation at the unit level — every lesson has an exit assessment that maps directly to its stated outcome. If learners fail the assessment, the lesson failed, not the learner.
This is just unit testing for education.
In a big curriculum, nobody knows who's responsible for which part. Bugs (bad content, outdated info) go unfixed for months.
We use a CODEOWNERS-style assignment. Every module has an owner. Changes require review from the owner. Same as a pull request.
Our curriculum now has:
We went from ad-hoc content production to a system that can onboard a new SME in two days and have them producing spec-compliant content by day three.
The curriculum is no longer a document. It's a system. And systems can be improved systematically.
Instructional design is the systematic process of creating educational experiences that reliably produce specific learning outcomes. It treats education as an engineering problem: defining the gap between current and desired learner ability, then designing content that closes that gap efficiently and measurably.
Modular curriculum design organizes a course into self-contained units with clearly defined inputs (prerequisites) and outputs (outcomes). Each module can be updated, replaced, or reordered independently. This mirrors software architecture: loosely coupled components with well-defined interfaces that don't break each other when one changes.
A learning dependency graph maps which concepts or skills must be mastered before others can be taught. It makes implicit prerequisites explicit, prevents sequencing errors, and enables personalized paths. It's equivalent to a package dependency tree — you can't load a module whose dependencies haven't resolved.
The core translation: lessons are functions (one input, one output), modules are services (independent, replaceable), and the curriculum is an architecture (a dependency graph). Just as software teams own components, curriculum teams own modules — enabling parallel development and systematic maintenance at scale.
Curriculum versioning treats each significant update as a new release (v2.3, not "updated course"). Changes are documented, owners are notified, and dependent modules are checked for compatibility. This creates an audit trail, enables rollback, and prevents the common problem of silent content drift over time.