N – 1. Should a CIO’s patching strategy be renamed ‘Y (why) - 1?’

12 December 2018

Tim Nightingale

Tim Nightingale

Principal Consultant

IT’s approach to patching has remained typically consistent with the N-1 strategy and for some justifiable reasons. As we consider cloud-based alternatives, should their strategy evolve to adapt? Tim Nightingale, Principal BI Consultant, contemplates.


I have worked with many organisations with regards to updates, upgrades or migrations, and often there is a question of which version they should move to.

This is normally answered by the customer’s patching strategy, often being referred to as N-1 (N minus 1). This indicates that the preferred version should be the second most recent version that has been released, with N being the most recent.

This then can be varied based on Support Pack or Patch levels and is dependent on how long the product’s lifecycle is. This IT strategy is historically in place for all applications regardless of type or vendor. I have even seen it in place for Operating System updates.

Now we can all understand why this strategy exists. It suggests that there is less risk involved in moving to a N-1 release as it will avoid any undiscovered bugs that exist in the N release. So, we need to understand the way software developers handle bugs. When a bug is discovered in the current release N, and because fixes can take time to understand, develop and test, then the fix will be released in future releases N+1, N+2 or even further on.
 
In the following diagram, we will focus on the current release N. We can see that as part of this release there have been some bug fixes delivered (green arrows) and after it has been released some bugs will be discovered (red arrows).

This would have been the same for previous releases (N-1, N-2) and will also be the same for future releases (N+1, N+2).

This next diagram shows the bugs fixes being released, and bugs being discovered, over the previous and future releases. As mentioned earlier, releasing the bug fixes could take some time and, as such, could be in any future release.
 















 


Looking at the combined diagram, we can see that having a strategy based on avoiding undiscovered bugs has the same level of risk regardless of which release is used.

Additionally, what we must consider, with regards to the N-1 strategy, is how different applications currently interact with each other. Since an organisation may have applications from multiple vendors, we need to ensure that the whole landscape is performing to its potential. That of course can only really be achieved if all applications have the latest updates installed.
 

The N strategy

Cloud – there you go, I said the word, it’s out there. Now we need to consider the impact cloud deployments can have on your patching strategy.

If your using any cloud-based applications which are managed for you, then there will also be a strategy for those too. That strategy may even be determined for you.

For example, with SAP Analytics Cloud, the application is updated about every two weeks. In a similar manner S/4HANA Public Cloud is updated by SAP on a quarterly basis.

So, we can see that Software as a Service (SaaS) applications already follow the strategy of N and not N-1.

Now, I am not saying that you should update every time a new patch that is released, but possibly have a time-based strategy that means that every X months/years the applications will be updated to the latest (N) release, subject to testing of course.

Being on the latest release not only bring bug fixes and code improvements, but also new and updated features, particularly useful when your users start comparing applications you have already invested in with other products.

In summary, there is nearly always going to be undiscovered bugs in any application, which are going to be fixed in future releases. You can’t of course wait for every bug to be found and fixed before updating, so you should accept the release that best delivers the fixes you need and enables you to provide a stable environment. This is why you have testing before rolling out updates to production applications.
 

The leapfrog manoeuvre

Since we know that Cloud (SaaS) applications already follow a strategy of N, and someone else is looking after those updates, then the more applications you move to the cloud the less it costs you to patch your existing applications. Why wait 5 years to move to the cloud when you can get a competitive advantage by adopting the N strategy now?

Find out how you can accelerate your move to SAP's flagship cloud ERP - SAP S/4HANA Cloud in our latest eBook.

About the author

Tim Nightingale

Principal Consultant

Bluefin and SAP S/4HANA - welcome to the one horse race

We use cookies to provide you with the best browsing experience. By continuing to use this site you agree to our use of cookies.