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
- Installed Patches
- Setup/Metadata Changes
- 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
About Subraya Mallya
Subraya Mallya is a technology executive, entrepreneur involved in conceiving, building software businesses. In this blog, he focusses on business and technology strategies around Business Model, Product Development and Marketing. Connect with me on Twitter - @subrayamallya
September 19th, 2007 at 2:44 AM
No one except change management team (can be part of the DBA team) can migrate the code. No one has acess to APPS password except the DBA and CM teams. This migration is strictly based on the service request and approvals based on testing in several instance testing. Ofcourse we cannot stop a code migration that needs to be migrated (if there is an order worth a million is stuck and not getting invoiced for some reason). So dependent on the manager who is approving this.
Patches:
For one of the clients we created a simple JSP which will be used by the support team to request for the patch migration to a patch instance. One blast mail goes all the necessary team members who should be aware of this patch functionality in some detail. This contains the Oracle’s SR number and patch number and some details what is the fix. ANd to some extent patch analysis of affected schemas. Workflow behind captures all approvals and stamps the same in the so called this Patch Migration Form. Once this reaches the place to migrate to production, final approval is required to apply to production. Profile option changes also follow the same route as they can have cross functional effect.
I am a little concerned with your approach of profile options because ultimately some one has to remember to change and in emergencies where we have to apply a patch we **have** to enabled it.
Individual application Setups: The big issue here is identifying which one should be allowed and which should not. For example, we cannot stop creating subinventories, employees, items and customers so on. But we do not need to change system parameters and profiles every day..even at the user level. Hence the it is very crucial to identify which is transaction setup and which is core and remove access to core setups. Changes to these setups should be based on a service request which are thoroughly tested like the way we do for the code and pacthes and them execute the change to the setups by either a specialist or change management team.
Administrative Setups: These changes are also SR based but can be changed only by the CM team based on the need. No one should have access to system admin but CM team.
Though there is opportunity for a product here, I feel that human intervention is inevitable.
Infact we need to inculcate this culture from the day one in new projects. I have seen a lot of resistance before, but once it takes root in the culture, people get used to it. This is a budding profession and has a long way to go.
Here I would like to introduce a new position of Security Specialist.It is time to accept this position in Oracle Apps implemention where he not only understands the just Sysadmin, but importance of entire architecture in terms of Multi-org, role of flexfields, profiles, alerts and so on. We should not confuse this with CM, albiet he can be part of that team.
In the era of self service economy this position is inevitable!