PeopleSoft on the Record: Patching is a Team Sport

Patching Is a Team Sport: Planning, Testing, Automation, and Communication Before Showtime

Now Playing: “With a Little Help from My Friends” — The Beatles

As a lifelong Beatles fan, I probably should have known this song would eventually find its way into PeopleSoft on the Record.

“With a Little Help from My Friends” appeared on Sgt. Pepper’s Lonely Hearts Club Band in 1967, written by John Lennon and Paul McCartney and sung by Ringo Starr.  More than five decades later, the title seems like a pretty good description of successful PeopleSoft patching.

When we hear a song or watch a live performance, it is easy to focus on the person at the microphone, but a lot more happens behind the scenes. There is rehearsal.  There is soundcheck.  Equipment has to work.  Levels have to be right.  Everyone needs to know their part before the performance begins.

PeopleSoft patching works much the same way.

Even after all these years, I still get a little nervous before a major PeopleTools upgrade or Production patching weekend.  Maybe anxious is the better word.

I know the plan.  I have already worked through it in Non-Production.  I am ready to get started. Still, there is that feeling just before the curtain goes up.  I want every step to be right and the performance to go exactly as planned. One PeopleSoft Administrator may ultimately run the commands, but getting a security patch safely into Production is rarely a solo performance.

The hardest part of patching often isn’t applying the patch.  It’s getting the entire team through the patching cycle together.

Patching Isn’t a Solo Act

PeopleSoft Administrators touch a lot of technology.

Depending on the environment, that may include PeopleTools, WebLogic, Java, Tuxedo, operating systems, databases, Integration Broker, Process Scheduler, OpenSearch, and certificates, just to name a few. But that does not mean the PeopleSoft Administrator owns every part of the process.

Security teams evaluate vulnerabilities and determine risk.  Operating system and database teams may have their own patching responsibilities.  Functional teams understand the business processes that need testing.  Business owners have schedules to consider.  Change control needs to understand what is changing, why it is changing, and what the rollback plan looks like.

Someone may have their hands on the keyboard applying the patch. The entire team gets it into Production.

That distinction is becoming even more important now that Oracle releases have effectively moved PeopleSoft teams from a quarterly rhythm to a monthly one.

Rehearsal Before Showtime

I have always thought of Non-Production patching as the rehearsal.

Development or Test is where you work through the update for the first time.  You find out what applies, capture the steps, confirm prerequisites, and see whether anything behaves differently than expected. You also want to understand how to get back to where you started.

With WebLogic patching, in particular, I prefer maintaining a clean rollback point and working through the layers in a controlled sequence.  If something fails afterward, it is much easier to determine which change caused the problem when several unrelated updates have not been stacked together.

Then comes the soundcheck.

For my initial smoke testing, I am not trying to reproduce an entire day of business activity.  I want to know that the fundamentals are there.

• Can I sign in?
• Are the App Server and Process Scheduler domains healthy?
• Can I run Process Scheduler jobs and reports?
• Is Integration Broker working?
• Does the environment look and behave the way it did before the maintenance?

Once the technical smoke tests are clean, functional and business teams can perform the deeper validation that only they can really provide.

That rehearsal matters.

You would much rather hit a bad note during soundcheck than after the audience is already in the seats.

Applying the Patch Is Only Part of the Work

One theme that kept coming up in the discussion after my last article was that applying the patch itself may not be the most expensive part of the process.

The regression window can be.

Under the old quarterly schedule, an organization might plan four larger security patching cycles each year.  Now those same functional teams could be asked to participate in testing almost every month.

• The PeopleSoft Administrator may be able to apply a patch more quickly through automation.
• The functional owner still has to test the business process.
• The security team still needs evidence that the vulnerability was addressed.
• Someone still needs to coordinate the maintenance window.
• Someone still needs to communicate what changed.

And those people already have other responsibilities.

This gets back to one of the central points from my previous article: The speed at which a customer can safely absorb change has become part of the security discussion itself.

A vendor can release a security fix immediately. That does not automatically mean an organization can safely put it into Production immediately.

The distance between those two events is where teamwork matters.

Everyone Sees a Different Part of the Environment

I was reminded of this recently during a discussion among PeopleSoft Administrators about vulnerability scanning.

A cybersecurity scanner may identify an older Java runtime somewhere under an Oracle or middleware installation, even though the PeopleSoft Administrator knows the primary PeopleTools environment runs a much newer Java release.

Both perspectives can be correct.

The scanner sees a vulnerable executable sitting on the server.

The PeopleSoft Administrator sees which Java runtime the PeopleSoft application is actually using.

The next question becomes: what owns that older runtime?  Does another Oracle component still require it?  If so, what is the supported way to patch it?

That is not simply a cybersecurity question or simply a PeopleSoft question. It requires both groups to understand what the other is seeing.

The same thing happens throughout an environment. A DBA may notice something the PeopleSoft Administrator does not.  An operating system administrator may see a dependency that is invisible from the application layer.  A functional analyst may find a regression that every technical health check missed.

Nobody sees the entire environment from exactly the same angle. That is why collaboration and communication aren’t just nice-to-haves in a patching cycle.  They are part of the process.

Automation Helps, But It Doesn’t Replace the Team

Automation has become increasingly important as the patch cadence has accelerated. Scripts that were once a convenience during quarterly maintenance can become essential when the same sequence may be performed every month.

If I can consistently back out superseded middleware patches, apply the new ones, verify versions, and repeat the process across environments without manually rediscovering every command, I save time and reduce the opportunity for human error.

But automation only solves part of the problem.

A script can apply WebLogic patches. It cannot decide whether Accounts Payable worked correctly after the change.

It can verify that an Integration Broker endpoint responds. It cannot necessarily determine whether a business transaction produced the correct downstream result.

It can speed up the technical work. It cannot replace communication.

Oracle’s recently announced change from the Infrastructure DPK to the new Middleware DPK is a good example of how automation and the patching process continue to evolve.

Beginning with the October 2026 CPU cycle, Oracle plans to use the Middleware DPK for supported PeopleTools releases.  PeopleTools 8.61 and 8.62 will require a prerequisite patch, while PeopleTools 8.63 already includes support.

The new Middleware DPK Builder will also let customers build the current middleware package themselves, rather than waiting several days for Oracle to publish its prebuilt package.  The builder supports Java, WebLogic, Tuxedo, Oracle Database Client, and OPatch.

Read Oracle’s announcement about the new Middleware DPK.

That is a significant improvement for customers who need the patches quickly.

But there is an interesting flip side.

Faster access to the patches only helps if the organization is ready to use them.

If you can create the Middleware DPK on Day 1 but your testing process, approvals, documentation, and people are not ready until Day 10, the technology was never the only constraint.

Again, it comes back to the team.

Sharing the Lesson Without Sharing the Client

Another topic has been on my mind recently. A recent edition of The PeopleSoft Insider asked why there is so little practitioner writing in the ERP community from people talking in their own voice about what they actually tried, what broke, and what they learned.

Read “I searched four ERP ecosystems.  Nothing.” in The PeopleSoft Insider.

The article pointed to several understandable reasons: client exposure, fear of giving away expertise, lack of encouragement from employers, and even experienced professionals wondering whether what they know is worth sharing publicly.

That discussion struck a chord with me.

There are obviously lines that should not be crossed. I don’t need to name a customer, expose its architecture, publish proprietary scripts, or describe an unresolved security issue to share something useful.

But I can share the lesson.

• What surprised me?
• What worked?
• What would I check first next time?
• What made the maintenance easier?
• What caused a problem?
• What did another administrator notice that I missed?

There is a big difference between sharing a client’s information and sharing the experience you gained while doing the work.

In a product like PeopleSoft, where decades of practical knowledge live inside the heads of administrators, developers, DBAs, and functional experts, those lessons have tremendous value.

When One Person Learns, the Team Learns

This is also one of the reasons I like having different environments available to work with.

Within a Managed Services team, PeopleSoft Administrators may support different customers, operating systems, databases, and PeopleTools releases.

Internally, I maintain PeopleSoft environments that give me another place to patch and test. I also keep my own virtual environments running different combinations of Windows, Linux, Oracle, and SQL Server.

Some people might call that overkill. I call it a playground. It lets me see differences before I encounter them somewhere that matters a lot more. More importantly, the value increases when those experiences are shared.

One administrator may discover something unusual while patching Linux. Another may encounter a WebLogic issue on Windows. Someone finds a cleaner rollback sequence. Someone else realizes that a validation step should be added to the checklist.

The next person should not have to discover the same lesson from scratch.

The value of a patching team isn’t simply having more people available.  It is making sure what one person learns becomes knowledge the whole team can use.

Documentation helps.

Automation helps.

Runbooks help.

Conversations help.

Sometimes a quick message saying, “Watch for this when you get to the next environment,” may save somebody an hour later that night.

That is teamwork too.

Showtime

A great performance can look effortless from the audience.

What the audience does not see are the rehearsals, soundchecks, equipment checks, mistakes, corrections, and conversations that happened before the first note was played.

A successful Production patching weekend can look much the same.

The environment comes back online.

Users can sign in.

Processes run.

Interfaces work.

The business opens Monday morning and, ideally, most people never realize how much happened behind the scenes.

That may actually be the best outcome.

The PeopleSoft Administrator may have run the commands, but getting there required security teams, technical teams, functional testers, business owners, and everyone else who helped make sure the environment was ready for showtime.

Patching may be technical work.

Successful patching is a team sport.

 

And sometimes, you really do get by with a little help from your friends.

 

 

We invite you to connect with Mike Engel via email or LinkedIn.