Customizations are a burden for software vendors. That's a conflict of interest.

A software customization is a specific feature for a very narrow audience—sometimes a single customer.

Software vendors resist customizations and would rather have all their customers work the same way. 

Why is that? Software vendors’ business model depends on writing one piece of software and selling it many times. They have one source of costs, and many sources of revenue. The best-case scenario for them is if all customers had similar needs. 

But inevitably, customers aren’t the same. Different universities have different policies and structures and preferences. They ask the vendor during the purchasing process, “does your software support [this unique need that my university has]?”

To land the sale, the vendor has to either figure out how to support that request, or they have to convince the university that they don’t really need that specific capability.

The compromise is to make the software configurable. In other words, make it possible for the same software to behave differently, for different customers.

Customization through configuration works, especially when the customizations are a relatively minor part of the overall package. But customization through configuration comes with two costs, particularly as the level of customization grows:

First, have you ever been in charge of a piece of software that is very highly configurable? The more configurable the software is, the more complicated it is to manage. People often devote a career to learning how to configure these systems. There will be conferences. Sometimes it comes full circle where the customer (or their consultant) is using code to configure the software.

The other cost is that it’s also really complicated to write and maintain highly configurable software. Programming languages don’t make it easy to write configurable software, so that adds a burden on the company too. There’s a very real limit to how much customization and configurability a software vendor’s business model can withstand.

In order to be successful, the software vendor needs one piece of software to serve as many universities as possible. That motivates them to help the universities to conform to the software as it is, without adding customizations.

A university, on the other hand, can only be successful if it stands apart from its peers. Arguably it has even more competitive challenges. What would you rather pivot, a software company or a university? So the university has an existential need to innovate in ways that inevitably place customization demands on the software.

The conflict arises when a university needs to leverage software in order to be more competitive, i.e. to be unique. The software vendors will be motivated to keep their complexity to a minimum, i.e. to have their customers conform.

This is an inherent tension in the current way that enterprise software is bought and sold.