%20(1).png)
For years, universities have made technology decisions by asking what system they need, what functionality it offers, how much it costs to implement, and what benefits it can deliver. The shift of SIS platforms from on-premise models to SaaS has added important arguments: continuous updates, greater standardization, security, resilience, less reliance on local infrastructure, and faster access to new functionality. Artificial intelligence now adds a different variable. The question is no longer only where the SIS lives or how it gets updated. The major technology ecosystems are starting to build data, analytics, automation, AI, and agents around their transactional systems. The traditional System of Record is beginning to aspire to become a System of Intelligence as well. And that deserves a strategic conversation.
A university may reasonably decide to move its SIS to SaaS. Later, it may adopt the same vendor’s data platform. Then its analytics solution. Then its AI capabilities. And finally, its agents. Each decision, evaluated on its own, can make sense. Integration reduces complexity, simplifies security, and lowers the effort required to add new capabilities. But the cumulative result is worth a closer look. Did the institution explicitly decide to concentrate its system of record, its data, its processes, its analytics, and a significant part of its intelligence in a single ecosystem? Or did it get there through a sequence of individual decisions, each one reasonable? The difference matters.
We have traditionally associated vendor lock-in with contracts, proprietary technologies, or high migration costs. AI may introduce a far subtler form of dependency: ease. Imagine a university needs to develop an agent to support student retention. One option is already connected to its data, integrated with its systems, approved by security, and part of its existing technology ecosystem. The other requires selecting a vendor, contracting with it, enabling APIs, resolving integrations, completing a cybersecurity review, testing, and training users. The first option will likely have an enormous advantage, not necessarily because it is better, but because it has less friction. The vendor doesn’t need to prevent the university from using other solutions. It may be enough to make staying within its ecosystem extraordinarily easy.
SaaS represents a real technological evolution and offers significant advantages for many institutions. Nor is there any reason to assume that building AI capabilities in-house will always be the better path. In many cases, using the intelligence built in by major vendors will be more efficient, more secure, and more financially reasonable. The real discussion is a different one. What capabilities does a university want to delegate, and which ones does it need to keep under its own control? Data. Integrations. Processes. Institutional rules. Intelligence models. Agents. The ability to adopt future solutions. There is no universal answer. But there should be a conscious decision.
This conversation is especially relevant for institutions that have recently made major investments in their current platforms. A university that has been using its SIS for many years may see a new platform as the natural evolution of an asset whose initial investment has already paid off. For one that finished an implementation two or three years ago, the same proposal can mean something entirely different. It isn’t facing just a technology decision. It has to justify a new investment, protect the value of the previous one, manage internal expectations, rebuild credibility with those who took part in the original decision, and, at the same time, make decisions about an artificial intelligence whose future development still carries significant uncertainty. Both universities may run the same SIS today, but they are not facing the same decision.
For a long time, we have asked: What is the best technology for our university? Perhaps we should add a second question: What decisions do we want to still be able to make five years from now? This introduces a particularly relevant concept: option value. A good technology architecture shouldn’t be judged only by the functionality it provides today. It should also be judged by how many alternatives it preserves for tomorrow. Will we be able to use our data independently? Integrate new solutions? Bring in our own or third-party models and agents? Replace one component without rebuilding the entire ecosystem? Take advantage of an innovation that doesn’t exist yet? In a relatively stable technology environment, these questions might have seemed secondary. At the current pace of artificial intelligence, they are becoming strategic.
At Doctums, we believe the next technology conversation in higher education shouldn’t be limited to choosing between on-premise and SaaS, between one vendor and another, or between building and buying artificial intelligence. It should help us understand what institutional architecture we are building as a result of those decisions. Because adopting a technology doesn’t only mean acquiring the capabilities it offers today. It can also expand, or narrow, the options we will have tomorrow. That is why one of the most important responsibilities for those of us who support universities through their technology transformation may be helping preserve something that rarely appears in an RFP: their future ability to choose. Today’s best technology decision shouldn’t necessarily be the one that promises to solve everything. It should also be the one that allows us to keep making good decisions when the future turns out different from what we imagine today.
Written by Rodolfo González Gatica
