Continuous Delivery Model

By Glenn Van Agten posted 06-19-2012 06:44 PM


In 2009, Oracle announced its Continuous Delivery Model for Campus Solutions; no more major upgrades. The intent being that institutions can now deploy the new functionality when they want: when business needs dictate.  New functionality would be released in the form of Feature Packs, and would be rolled on only months apart instead of years apart.  Functionality delivered sooner and less complicated to implement, win-win right? Ultimately, new functionality does take time and resources to implement; the difference is that when it can be implemented is now a variable.


So how does an organization determine when the time is right?  Upgrades were synonymous with re-evaluation business processes in light of new functionality.  Maintenance packs, an existing form of continuous delivery, focus only on testing present functionality. What process will now trigger an evaluation of business needs and the suitability of new functionality? Status Quo is a seductive route but ultimately disadvantaged route.


CS support teams may be aware of new functionality but may not be empowered with the time needed to implement it. Business units (OUR), while potentially benefitting from new functionality, may not be aware of its existence.  IT Directors, while aware continuous delivery, may not have the clear business case they need to commit time and resources.


Take for example, Oracle’s new Post Enrollment Requisite Checking. (PERC), which offers the ability to manage students that enroll in class on the assumption they will successfully meet the pre-requisites but then fail to. In contrast to applying a bundle, implementing this feature requires coordination between the campus and IT, changes to security, training, and change management. It may require a business case in which the effort is scoped and the advantages documented. But if an institution were to continue status quo (“It’s just another bundle”), there may not even be time allocated to adequately assess the value and scope the work.


Similarities could be drawn between continuous delivery and many of the mini-projects that institutions have likely taken on in the past. Every institution has a wish list of enhancements and a change control process to management them. Requests are scoped for effort, the business benefits are analyzed, and they are ultimately approved when the value is evident. Feature packs can leverage that existing change process, with the benefit that the associated development is already complete.


Campus Solutions support teams are at the forefront, they have the opportunity to lead. New feature packs have generated tremendous, positive, activity on the HEUG. They are aware of what the new features can do. The key is to go outside ERP and initiate discussion with business units about their processes to determine the value (e.g. PERC with the Registrar’s office). These teams should be empowered to discuss new features with the intended beneficiary. IT directors will find value in budgeting effort for an initial evaluation of benefits of new features to the institution.


Continuous delivery requires a shift in strategy. To reap the benefits, institutions need to be pro-active in determining whether or not to implement new functionality. The conclusive push to assess and implement new features no longer comes from Oracle, it must come from within.


Glenn Van Agten
Senior Consultant | Consulting


1 view