Perpetual Patch Cycles Define Todays Digital Revolution for Saas Applications

Perpetual Patch Cycles Define Todays Digital Revolution for Saas Applications

in Blog Article by Jeff Hare

A digital revolution is upon us! We are witnessing the greatest digital transformation since Y2K thanks to perpetual patch cycles within SaaS Applications. Organizations are ridding themselves of building and managing data centers by moving their legacy applications to hosted data centers. And thus moving many of their legacy applications to modern SaaS applications.

Some of this is chalked up to necessity with the work from home requirements derived from the COVID pandemic. During those challenging times, IT staff had to shift from on-site access to remote access for enterprise applications. Meaning, they had to enable users to work from home securely and efficiently.

This transformation appears to have picked up steam driven by a Return on Investment calculated by C-Suite executives.

There are two types of transformations. The first is the movement of legacy on-premise applications to hosted “Cloud” infrastructure. Terms such as PaaS, IaaS, and SaaS have become a part of IT lexicon. Some of these ‘lift and shift’ projects have also involved outsourcing support and maintenance of these applications.

The second type of transformation is a re-implementation of legacy applications to Software as a Service (SaaS) applications which are browser based. The provider hosts SaaS applications and updates them regularly, often following a pre-defined, published schedule.

There are many differences between these two types of transformation projects. However, I want to highlight one significant difference in their approaches.

The Big Difference

For legacy ‘on-premise’ ERP applications, the client can defer application patches for years at a time.  For SaaS ERP applications, the software provider enforces patches on a periodic basis. In the early days of the SaaS application, there were times when the software provider wasn’t 100% transparent about when they patched and what was changing. Management sufficiently chastised software providers in these early days on this issue. And for the most part, the transparency we see today with the timing of patches is no longer an issue.

What hasn’t changed is the “Perpetual Patch Cycle.” The Perpetual Patch Cycle is the notion that patches (often referred to as Releases) will be applied on a regular basis and ARE mandatory.  Most software providers allow organizations to delay some patches here and there. This can be especially helpful to organizations who are in the implementation process. Also, organizations can often negotiate what ‘cycle’ they get the patch / release in.

Now, organizations can be an early adopter or be in a subsequent cycle, but they cannot defer the patches for years like they used to. Hence, the reason we, ERP Risk Advisors, coined this as the ‘Perpetual Patch Cycle.’

While management is mostly excited to have outsourced the process of scheduling and applying patches, they have NOT outsourced the identification and management of the changes being introduced by the SaaS software providers.

Keeping Dangers Due to Patch Cycles at Bay!

I fear that auditors and management haven’t fully awakened to the reality that every patch / release is a mini upgrade. The ignorance of management is partly due to the ‘hype’ being created by SaaS providers and the large system integrators (SI’s)… Who all stand to gain from these digital transformation projects. The large SI’s rarely see the impact of the perpetual patch cycle because they often roll a project within a month or two of the project’s go-live. More often than not, the SI’s intentionally fail to mention the perpetual patch cycle in their proposal responses even when they may be present for subsequent implementation phases.

Management would be wise to understand the impacts of the quarterly or semi-annual patch / release process. Most organizations implementing SaaS applications understand the “upgrade cycle” from managing their on-premises legacy applications. Thus, they have a good understanding of what the execution of a software upgrade project takes. These upgrade projects are often six to twelve months or more in duration.

To prevent being caught flat footed after go-live, organizations need an additional budget of 10% to 30% of the project costs. Management often discovers the contingency budget was spent on go-live or, worse, wasn’t funded at all.

What’s Next?

At ERP Risk Advisors, we help management rebuild and enhance their security and controls program. This often involves customizing roles, training staff, and implementing processes to monitor security improvements and bug fixes.

We interact with other firms who have built businesses around the gaps left behind by these large system integrators and ERP software companies. We often see ‘rescue projects’ being executed by other system integrators and a growing number of managed service providers.

Addressing the Challenges

The following are a few of the many challenges faced by management:

  • Roles were not adequately customized based on the principle of least privilege. The project team identified these gaps due to the lack of negative regression testing—a process that asks, “Can users do things they should not be able to do?”
  • Cyber security risks have not been considered. There is much more to cyber security than what is outsourced to the software provider. Cyber security risks for SaaS applications go well beyond protecting the perimeter and administrative access. In fact, there is no longer a perimeter with internet facing SaaS applications.
  • The security program is not mature. SaaS applications need to be secured and monitored to protect from compliance, fraud, cyber security, data security, and operational risks. Such risks exist because system integrators aren’t experts in risk management and IT security. Using large SIs’ risk advisory practices to oversee their own System Integrator work is like asking a fox to guard hens.
  • Internal teams managing applications lack system integrator training on handling patch/release processes. Oracle ERP/HCM Cloud offers a two-week window between development and production deployment. These two weeks take the place of what would have taken six to twelve months in their on-premise ERP system.
  • Training…  administrators, support team, provisioning team, and most users are still adjusting to the new system.

Upcoming Events / Contact Us

In this next month we will be exploring the top tips and tricks we have learned from industry experts in our three-part webinar series called, “Why Implementations Fail: An Independent View”. Register for the webinar on Dec. 2nd Here.

If we can be of assistance to you and your organization as you face the challenges of today’s ever-changing digital revolution, feel free to reach out to us at Support@erpra.net. We can help you navigate the waters before they get too murky. 

Share this post:
ERPRA Become Our Partner

Please select your preferred datasheet and download it: