Prior to implementing the Integrated System, the University heard about patching. All those organizations who went before us in deploying similar integrated administrative information systems told us that patching would be a constant effort. Now, after being in “support mode” for 3 1/2 years on Finance and a little over 2 years on HR/Payroll, we have a first-hand understanding of what it means to be “patch-current.”

Patching – Looking Back and Forward at the Same Time
In today’s world, no software application is without flaws, especially when it is rolled out to market as quickly as possible to meet customer demands. Testing for each customer’s unique environment is very difficult, so problems can go undetected. Software vendors want to fix problems as soon as they are identified, and they also want to continue to enhance their software’s functionality. They do both with “patches,” new code regularly made available to customers to incorporate into their system.

Sounds easy, right? Just apply the patches and move along. Wrong. Deciding which patches to apply is only the beginning of a long process.

“‘Software vendors provide thousands of patches,” says Virginia Evans, Assistant Vice President for ISDS. “The first step is deciding which ones U.Va. must apply to resolve current issues or to add useful functionality.”

While that cuts down the number significantly, ISDS still applies patches at a rate of about 7 per week. These may be single issue patches to resolve an immediate problem, or larger patches called “family packs” that fix known issues and upgrade functionality.

“Once we decide to apply a patch, it has to be installed and tested in five different instances (copies) of the system to be sure it fixes the problem and doesn’t negatively impact customizations or other system functionality,” says Teresa Wimmer, ISDS Technical Director. “The bigger the patch, the more customizations it can impact, so we have to go in and adjust or obsolete U.Va. code in all affected customizations to allow them to work with the new code and functionality.”

“Patches also can impact other applications, since the system is integrated,” says Shy Hicks, ISDS Director of Financial Applications. “ISDS functional staff spends on average one week testing smaller patches and between one and two months testing family packs to be sure other applications and system integration are not negatively impacted. Sometimes a patch doesn’t fix the problem, and we have to start over with a new patch.”

Multiply that by 271 patches applied since the 11i upgrade in May 2004.

Do We Have to Patch?
In short, yes. If something is broken, a patch is often required to fix it. In addition, a deciding argument for implementing an ERP system was that, once up on the platform, the University would not have to worry about the system becoming obsolete. Oracle Corp. would make available regular upgrades to ensure the system represented current best business practices.

“In order to deploy those upgrades, we must stay ‘patch-current,’” explains Evans. “ERP software vendors support their most current products. If we fall too far behind on patches, we are not in a position to implement the next upgrade, and Oracle Corp. support is unable to help us when we run into problems.”

Enhancements: the Fun Part
As much time as patching takes, and as essential as it is to maintaining and upgrading the system, ISDS staff finds the greatest satisfaction in providing enhancements to the system that improve usability or add new functionality.

“We make a concerted effort to add enhancements (including functional upgrades) to the work list as soon as the system stabilizes following major upgrades,” says Evans. “Despite the focus on fixes and maintenance, and the additional responsibility of meeting new requirements of the University, Commonwealth, and Federal government, we have been able to implement over 75 enhancements since May 2004. We have been particularly successful with changes to reports, largely because we have the additional support of the Integrated System Task Force members in analyzing and testing the changes. The Self Service On-Line Payslip was a major functional upgrade, and we expect to implement more self service functionality in the next few months and over the next year.” (See “Self Service Gets First Full Scale Rollout.”)

“While we will always be juggling between keeping the system operational and current, meeting compliance requirements, and offering new functionality,” concludes Evans, “we continually review and reassess with the goal of implementing as many enhancements as we possibly can. And, the upside to patches is that we often get new functionality just by staying patch-current.”