Prior to release 9.2, Oracle/PeopleSoft used a sequential release cycle for PeopleSoft. So what changed?
Before each new release, the desired features were identified and the development team would spin-off a copy of the existing production release and use that for developing the next release. This process led to an environment where customers were routinely spread across multiple releases of the software. The support schedule encouraged clients to move to later releases, but it was common for more than one release to be supported.
This model spreads support resources and is expensive. Support issues in one version have to be accommodated in all versions. Adoption was not โselectiveโโฆ an upgrade required clients to take the next release in full. Upgrades were highly disruptive and very expensive. Similarly, interim bug fixes were delivered in โbundlesโ and (mostly) had to be applied as a group with similar disruption and expense.
So, what changed?โฆ
Oracle decided that the easiest way to stop having to spread their resources across multiple versions was to no longer have multiple versions. Version 9.2 was determined to be the last version of PeopleSoft.
By definition, this allowed:
- All support resources be dedicated to a single version of PeopleSoft
- Bug fixes no longer have to be accommodated across versions
- New development is performed in a version that clients are using
In practice, this also allowed:
- Continuous improvement cycles for Oracle and clients
- Enhanced opportunities for automated testing
How does a โsingle versionโ world work?
Introducing the PeopleSoft Update Manager (PUM)โฆ
Oracle developers use a 9.2 version to do new functionality development and bug fixes. When these items are complete and tested, they are moved into a โGoldโ copy of PeopleSoft. Note, everything is in version 9.2.
Roughly every couple of months, a snapshot of the Gold copy of PeopleSoft is made and it becomes the current PUM instance. This PUM instance is then made available to clients.
Because the PUM instance is a full copy of the โGoldโ instance, it contains all tested bug fixes AND any new functionality that is being introduced. New functionality is no longer held for a new versionโฆ when it is done, it is available. PeopleSoft customers should download the latest PUM releases when they are made available.
A PUM compare will identify differences between the PUM instance and the local PS and allow individual changes to be applied.
This process, supported by the ability to do PUM comparisons, is the center of SELECTIVE ADOPTION.
The PUM:
- Performs comparisons between a local instance of PeopleSoft and a local PUM instance (essentially the Oracle โgoldโ copy of PeopleSoft)
- Identifies differences between those two
- Allows the user to select the changes (bug fixes and new features) to adopt
- Handles the inclusion of prerequisites
Why is SELECTIVE ADOPTION better?
Contact us to learn more.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Attending the PeopleSoft Reconnect conference this week at the Hyatt Regency O’Hare?
Make sure to attend the Highstreet conference session: Chh.. chh..chh..Changes. Selective Adoption Strategies for PeopleSoft Fluid.
Tuesday, July 17 (12:45 PM โ 1:45 PM) in the Gatwick room.