GRC AC Configuration Approach

[kanika]

Hello folks,I am writing this blog after my first GRC AC 12.0 implementation project for new newbies like me. 

Through this blog I have tried to explain which all approaches can be considered in implementation projects for moving changes across the landscape. This will help in making decision from the initial stage of the project .

Considering that all configurations are attached to RFC names, there needs to be a way to be able to handle changes effectively across the landscape.

Approach 1:

Create all the connections to the satellite systems (DEV,QAS,PRD) in GRC Dev and move to prod.  (Recommended approach) – Create DEV GRC as PRD GRC. Also, the Quality and Production satellite SM59 connections would be left empty to ensure nothing is provisioned from DEV GRC to QA or PRD satellite systems.

Advantages:

Firstly, changes can be tracked and will be consistent across the landscape. Satellite Connectors and configuration related to connections remains intact after system refresh from PRD. Change Management process will be followed effectively. Lastly, no Audit Concerns.

Approach 1

Approach 2:

Create the connections to the satellite systems in respective GRC systems. Modify all the connector related settings directly in PRD GRC systems whenever a new satellite connector needs to be connected to the GRC system

Advantage:

Less time consuming.

The only advantage here is that you get to use the usual RFC that can/may be useful for core team members to identify the RFCs by name.

Disadvantages:

Audit concerns for making direct changes to the client. After system refresh (from GRC prod) all connector related configuration needs to be updated. Change Management process needs to be appended/created for making changes to the GRC system

Approach 3:

Create RFC with generic name Eg: ECC_GRC.

Advantages:

Firstly, easiest to configure. Only hostname of respective satellite connector needs to be updated after system refresh. Change Management process will be followed effectively. Lastly, no audit Concerns.

Disadvantage:

1. This approach can only be applied where customer is using separate GRC systems(GRC DEV, GRC Quality, GRC Production) for connecting respective satellite systems. This approach is a failure where there is one GRC production system for connecting the complete landscape i.e (ECC Dev,  ECC quality, ECC prod) or if customer is having common GRC system for DEV and quality system for cost cutting


2. You might have a Sandbox, Master Configuration and Unit Test client on your Development box. Your connector can only connect to one of them.

CONCLUSION:

Personally, I found approach 1 as best as it generally works in all scenarios. However one needs to consider the approach depending on the GRC landscape.

I 'd like everyone to provide suggestions/feedback and add all possible approaches to this blog that can be used during implementation projects.