Change Moratorium

By Subraya Mallya - June 2007 | Topics - Change Management, Compliance

In one of my recent conversations with a past customers of mine, amongst other IT challenges we ended discussing the moratorium on changes or locking down the application from any changes.

When would you want a change moratorium?

Typically a change moratorium is put in place during some critical business events like Compliance Audits, Book Close etc.

The easiest way to enforce this, if you had a well defined change management policy, is to define a time based rule to block all the approvals. You can either stop the change lifecycle to stop at the Pending Approval state or include an authority in the company who dictates the moratorium period to be the final approver in the approval chain. For eg. A VP IT or CIO might be added to all approvals that way nothing gets past that single point of approval.

Why don’t I just block the creation of Change Requests?

I think the RFC(Request For Change) creation is an involved process and requires extensive upfront analysis and definition of downstream activities like Test cycle, Rollout strategy, Backout strategy, Performance Testing etc. Those activities can still be conducted and the necessary documentation around the change can captured without effecting the change. Also queuing up the changes can also help in release planning. So I would not recommend block creation of Change Requests.

For Oracle E-Business Suite, (while not precluding the need for a change process) the changes done can be classified into three categories

  1. Installed Patches
  2. Setup/Metadata Changes
  3. Manual Administrative Changes

As part of Application Management, Oracle does not provide a way to lock all the changes but there are a few things that can be done to stop the changes.

Here is a checklist for someone looking for enforcing a moratorium.

Installed Patches
This is the probably the easiest of them to control. All Application Patches are applied using ADPATCH and this tool needs the apps schema password. So ensuring that apps password is not made available to anyone. This may or may not be possible given the myriad of integrations/tools where the apps password might be configured (including a configuration file that Oracle E-Business Suite needs password in).

If restricting the knowledge of apps password is not possible for some reason and since changing the apps password temporarily to something else is an elaborate process, I also thought of exploring few other other options of achieving the same effect (potentially with some DBA work)

  • Oracle EBS as part of every patch creates a table called AD_INSTALLED_PATCHES to capture transient information about the patches and cleans up once patching is successfully completed. Having two SQL/DB profiles one which allows creation of tables and one that does not. During moratorium period, change the default profile for apps user to “DONT_ALLOW_TB_CREATION” profile.

Setup/Metadata Changes
This is a tough one. Depending on the implementation anywhere from 5-50% of the users in the Oracle E-Business Suite user base might be able to change things that could be considered metadata that influences the functioning of the app. Most of the companies, driven by the need to have traceability of changes, would have auditing implemented in Oracle E-Business Suite but most of auditing is done after the changes are done. There is no way to prevent the changes from happening. An effective Segregation of Duties implementation combined with account freeze should allow you to  prevent most of the changes from happening.

Manual Administrative Changes
Most of the administrative activities like changing Concurrent Manager Schedules, Provisioning responsibilities, adding new users are done using System Administrator or some variant/derivative responsibility. If the company has complied with SOX – SoD requirements then the System Administrator roles would have been given to a isolated set of individuals. So freezing those accounts would effectively rule out any chances of configuration/administrative changes done to the applications. While all my thoughts are an effort to come up with an approach, they are not by any means comprehensive. Would really love to hear from others if any others methods have been used to implement a change moratorium

Back to Top
%d bloggers like this: