Vanilla Banner saves money, eases upgrades
Using “vanilla” software for the OnePurdue systems was a priority even before the project had a name, and has continued to be a guiding principle with the implementation of Banner.
“Going vanilla basically means that we didn’t do anything to the software code that won’t carry forward to the next upgrade,” said Jeff Whitten, associate vice president of ITaP’s Enterprise Applications unit and OnePurdue’s chief architect. “The less we customize it, the fewer problems we’ll have down the road.”
There are two primary reasons to stay as vanilla as possible: the lifetime cost of the systems and faster upgrades.
“Purdue has invested a lot of money into OnePurdue’s SAP (financial and human resources) and Banner (student) systems,” Whitten said, “and staying vanilla helps protect that investment.
“Incorporating new code into already-complex ERP software adds time and costs to the equation. Going vanilla, however, has probably already saved Purdue hundreds of thousands of dollars.”
In addition to being more expensive, Whitten said, customizing products like Banner can pose problems when new upgrades are released.
“We experienced this firsthand with FMIS, the old (legacy) accounting system that was replaced by SAP software. Although Purdue originally purchased it, we customized it so much over the years that some people think it was homegrown.
“Unfortunately, we also customized our way out of an upgrade path. So many changes had been made that the cost of upgrading it was just too much to be cost effective.
“The bottom line is that it's not easy to anticipate the impact on tomorrow of what you do today, so we have to carefully weight the benefit of any code change against the total cost.”
Just as it did with FMIS, Whitten said, customizing Banner too much might jeopardize the University’s ability to take advantage of improved technology contained in future upgrades from the manufacturer.
“Of course, there is not just one flavor of ‘vanilla’; I have never seen a 100 percent, pure vanilla ERP implementation. A few changes are to be expected. In fact, many software vendors build a limited degree of customization into their products, and if you work within their parameters, a vendor will pull that code forward into the next upgrade.
“The customer still has to maintain its own code, though. In addition, manufacturer software upgrades can sometimes break custom code. So, again, we need to think hard before making code changes.
“Staying vanilla allowed us to have smooth upgrades when we implemented the SAP systems,” Whitten said, “so we already saw the benefits of this while we prepared to release Banner.”
Purdue has kept its source code changes to a minimum, said Rita Clifford, director of the Student Systems Competency Center.
Whitten agreed: “We’ve still been more vanilla than most universities. Some institutions made many more customizations than we have, and came to regret it.
“The advantage of going vanilla will become even more apparent when we upgrade to Banner 8 next year.”