Ask an institution what is in its academic technology stack and you will get a confident answer for the first few things, the LMS, the video platform, web conferencing, lecture capture, and then a much longer list that takes real effort to assemble: the tool one college licensed on its own, the one a department adopted for a specific need, the one an enthusiastic faculty member brought in and quietly taught their colleagues to use.
Every one of those was a reasonable decision in isolation. A department genuinely needed a discipline-specific tool the central platform did not offer. A faculty member genuinely found something that helped their teaching. The stack grows because a healthy institution keeps adopting useful things. The real question is whether it grows as a system someone is looking after, or as a pile of separate decisions that never get considered together.
A stack is systems plus the connections between them
The connections are the part that is easy to underweight. Every product has to answer the same handful of questions. Where do its user accounts come from. Where does its roster data come from. Where do its results go. Who can see its data, under what agreement. When a tool gets added on its own, those questions get answered with whatever is quickest at the time. A manual export, a separate login, a class list emailed to a supplier. Each answer is small on its own, and each becomes a standing task someone now owns forever.
The sector’s interoperability standards. The account and roster provisioning specs, the tool-launch and results-return specs 1EdTech maintains. Exist precisely so adding a tool does not mean building new plumbing every single time. A product that supports them tends to join a stack cleanly. “It integrates” is a claim worth checking against the real standards, not taking on faith.
When a unit adopts a tool outside the central process
This happens constantly, and it is usually because the central process was slower than the actual need. It is a signal worth reading, not a problem worth policing. It points directly at where the process could be faster and more visible. What works is making the central process quick enough that going through it becomes the easy choice. Including a genuine fast lane for low-cost tools that touch no protected data and serve a single course.
The light structure that keeps it coherent
Not a freeze, and not a heavier approval chain. Just a few standing habits.
A standing review with the right people in the room: instructional technology, IT security, the library, disability services, a faculty representative, procurement. A group that looks at proposed additions together on a predictable cadence. The value is simple. Someone in that room will recognize an overlap with an existing license, a conflict with a data agreement, or an accessibility gap that matters a lot more now that there is a federal deadline attached to it.
Interoperability as a stated, explicit expectation. New tools are expected to support the sector’s account, roster, and results standards, or arrive with a funded, credible plan for how they will connect.
An annual look at the whole stack. Once a year: what is redundant, what is barely used, what is out of support, what costs more than it returns. Application rationalization is routine practice in enterprise IT and far less common in academic technology. The output is a short list of things to retire, planned like any other change, with real notice, migration help, and respect for the faculty who built practice around a given tool.
A genuine fast lane for small, low-risk additions, so units are not stuck choosing between waiting out a full review cycle or going around the process entirely.
What a stack audit produces
A campus-wide technology investment audit usually produces a map, not a shopping list. What is running, what connects to what, where a capability is licensed more than once, where student data moves through an agreement nobody is read recently, and where accessibility and security attention needs to go. Once that map exists, the retirements often cover a good chunk of whatever the institution needs to add next, and the standing habits keep the map from needing a full rebuild every few years.
Shuji Toyama is a learning management system administration specialist at Wrightmann Education Technologists. Part of the Technology Procurement series.
References
- 1EdTech Consortium. Learning Tools Interoperability (LTI) and OneRoster. https://www.1edtech.org/standards
- Brown, M., Dehoney, J., & Millichap, N. (2015). The Next Generation Digital Learning Environment: A Report on Research. EDUCAUSE Learning Initiative. https://library.educause.edu/resources/2015/4/the-next-generation-digital-learning-environment-a-report-on-research