G’day Trinetra
Interesting Question and hope others jump here. Here’s my
thoughts (I’m not part of product team to see if they have a specific
recommendation).
I would not remove the connector from configuration whilst there
is master data, transactional and historical data associated with the connector.
You may find it difficult to report and retrieve the data from the front end
(e.g. how can search for the connector if it doesn’t exist in drop down).
I would see 2 phases for removal: (1) Logical Removal and
(2) Physical Removal. What you’ve proposed is more of what I’d look at for step
2.
Phase 1 – Logical Removal – keep the data and
reporting capabilities but remove updates (to the user it's either doesn't exist on the front end or it's limited read only use)
a.
Do not remove the actual connectors
b.
Consider updated configuration parameters to
remove any default or higher sort preferences
c.
Consider updating data source configuration to
remove it from here
d.
Possible change default connectors depending on
your logical group setup but if you are decommissioning SRM then I assume all
connectors in the group should be removed (but do recognised it might be
staged)
e.
Do not touch integration framework and other
mapping areas (would do this for physical removal)
- 2.
Update user authorisations remove access to
connectors and/or limit to display only for key teams
a.
There are some system connectors or logical
systems
b.
Consider template requests if they are system
specific, etc
c.
Goal is to prevent the connector appearing in
access request, etc. You
- 3.
Copy/Extract/Archive any data that is no longer
required
- 4.
Suspend periodic jobs and other housekeeping
jobs for that connector such as (there are others)
a.
Email reminders
b.
Batch risk analysis
c.
Object repository sync jobs
d.
Auth sync jobs
- 5.
Dummy SM59 RFC Connection to make is
inaccessible (keep the entry for config but remove user credentials and change
the host name if it’s only used for GRC connections)
- 6.
Access Risk Analysis
a.
Optional to delete generated rules if risk
analysis reporting is no longer needed (reduces table size)
b.
Optional to set all access risk or functions for
the logical system to inactive so no risk analysis can occur.
c.
Cancel any batch risks analysis jobs
d.
Option to delete violation data, if no longer
required
- 7.
Access Request Management
a.
Update and remove any default rules relating to
configuration or BRF+ rules
b.
Update MSMP workflows if they contain the old system.
Can always add a new routing rule just in case
c.
Update and remove any Request Templates from the
System
- 8.
Business Roles Management
a.
Configure a Role type of Decommissioned and make
it not productive (cannot be chosen in an access request)
b.
Mass all technical roles for the connector to
have role status as not productive – this will stop them appearing in an Access
Request
c.
Remove technical roles form business roles
(again stops system trying to provision them)
d.
Change or remove Role Owner
e.
Activate the configuration parameter to include
comments so you can reference the RFC/Change number to recognise this is
historical data.
- 9.
Emergency Access Management/Firefighter
a.
Remove all FF Ids, FF Users, and FF Controllers,
and FF Owner assignments to the related FF Ids for the system.
b.
Note – later version of audit/change documents record
this action so removing users still retain the audit log
a.
As mentioned – review configuration to see if
you need to remove or add any specific rules relating to this system
b.
Cancel any in flight workflows that may have
been orphaned
a.
Have mentioned it throughout
b.
What you delete here needs to consider business
requirements for data retention policy rules in conjunction with SAP
recommendations (i.e. deleting technical role data that is in a business role
may cause issues).
c.
As part of this you can identify the data minimisation
opportunities as well – what is the mandatory data you need to retain.
- 12. Other Integration - confirm not other upstream or downstream systems use the data (e.g. SAP IdM, SailPoint, etc). If so, work with those teams to remove the references
Phase 2 – Physical Removal – system is no longer needed and
all data is retried / unlikely you need to search or report on it. Might take a while to get to this stage
Note: change document/logs, SLG1, etc won’t be touched here
- 1.
Confirm data no longer required (as per data
retention policy)
- 2.
Run deletion jobs (SAP notes provide the steps)
to delete the rest of the data again the connector
- 3.
Remove Connector from IMG Configuration
Anyway, quick brain dump of my approach. I’m sure there are
gaps so would love to see others jump in on this thread
Cheers
Colleen
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.