N+1 and Reverse Synchronization

Guidelines and Principles

By Jose A. Colon

CONFIDENTIAL DOCUMENT USE IN ACCORDANCE WITH COMPANY POLICIES 1

Agenda

• N to N+1 Synchronization
– Go over the landscape approach (the road and traffic patterns)
– Go over the process (rules and regulations)
– The ugly truth about system changes
• Reverse Synchronization

CONFIDENTIAL DOCUMENT USE IN ACCORDANCE WITH COMPANY POLICIES 2

 N to N+1 Synchronization

Frequency: Monthly Basis

Current State: only Manual Synchronization

Future State:

Retrofit – SolMan Functionality that helps to synchronize

changes across an N and N+1 landscape by performing a
controlled import into N+1 DEV system. Training will be
provided once Retrofit is about to be turned on

*Slide is a curtesy of the Process integration team

CONFIDENTIAL DOCUMENT USE IN ACCORDANCE WITH COMPANY POLICIES 3

 N to N+1 Synchronization
2
BTB02_PRJ
1 Via Normal CR
(RDG-RLG-RPG)
BTB01_SUPP
Canvas Via Admin CR
“N” D50 Q50 P50
Landscape

R50

Q60 P60

1 Admin CR – N to N+1 Manual Retrofit (BTB01_SUPP)

- One RTF Admin CR. One RFT CO per month under the same RTF CR.
2 Normal CR – Process Retrofit on N+1 (BTB02_PRJ)

*Slide is a curtesy of the Process integration team C ChaRM M Manual G Go-Live (via ChaRM)
CONFIDENTIAL DOCUMENT USE IN ACCORDANCE WITH COMPANY POLICIES 4
N to N+1 Synchronization

CONFIDENTIAL DOCUMENT USE IN ACCORDANCE WITH COMPANY POLICIES 5

N to N+1 Synchronization

Guideline one

CONFIDENTIAL DOCUMENT USE IN ACCORDANCE WITH COMPANY POLICIES 6

Guideline One
Repair to Project Development Transfer (Agreement to Replicate Changes - Monthly)

• One and only one Admin CR/CO for documentation purposes only (Document the review
and approval)
• Process Integration team publishes monthly list
• There will be 5 days operational level objective to document decision on CO.
Gatekeepers are accountable for timeline adherence.
– Project Functional teams
• Day 1 to 3 - Conduct review from the functionality perspective (is the functionality relevant beyond the next
release?).
• Day 4 to 5 - Conduct consolidation assessment (have we modified this configuration table already or RICEF
in the project)?
– Project Development team
• Day 1 to 3 - Conduct object level comparison and publish potential object collisions (early watch advise)
• Day 4 to 5 - Perform OSS note version compatibility check

CONFIDENTIAL DOCUMENT USE IN ACCORDANCE WITH COMPANY POLICIES 7

N to N+1 Synchronization

Guideline Two

CONFIDENTIAL DOCUMENT USE IN ACCORDANCE WITH COMPANY POLICIES 8

 Guideline Two
Incorporation Into Project Release (How to Carry forward the changes - Monthly)

• 10 days operational level objective to handle code replication and consolidation activities. Gate keepers are
accountable for timeline adherence.
– Day 1 and 2 (Driven by project DRI)
• Create project CR for replication of untouched configuration elements (One per process team) or untouched WRICEF (one
CR per WRICEF). (Subsequent changes for the same object can be handled as a scope change to existing CR).
• Create consolidation addendum for any configuration or RICEF that has already been touched by the project.
– Day 3, 4 and 5
• Perform RICEF-related replication activities (Development DRI to coordinate with base business development team to
handle any manual activities if required for any untouched items)
• Perform functional configuration replication (Process DRI to coordinate with base business process teams any manual
activity associated with any untouched items)
• Perform RICEF-related consolidation activities (Project development team)
• Perform functional configuration consolidation activities (Project process teams)
– Day 6 to 10
• Perform Technical Acceptance Test (TAT) for consolidated items (Project process team)
• Submit for compliance acceptance (Project process team )
• The following guidelines apply not only to production repairs but also project repairs and scope changes
– There must be one and only one CR per RICEF object across parallel releases. By definition this is a common object
– Freeze period - A new CR for a common object can only be opened after end of ST / Beginning of UAT
– There must not be any cross-release transfers (once something is released to QA it will go to production in the
relevant release)
– There must be one CR per process team per release for language translations.
*Target OLO applicable to subsequent syncs. Does not apply to first sync given the current size (no sync has taken place since 7/24)
CONFIDENTIAL DOCUMENT USE IN ACCORDANCE WITH COMPANY POLICIES 9
 One and Only one CR per WRICEF Guideline
Why do we need this control
(1) First (2) Second
Go Live Go live CR-1

Own Current Version 1 Version 2

Changes CO-1 1k Canvas Lines (1) 1k Canvas Lines (1)
Canada 200 Canada Edited
100 Canada Added
Wants a new LER
Change CO-2 CR-2 CR-1 Scope Change

Version 3 Version 4
1k Canvas Lines (1) 1k Canvas Lines (1)
100 LER Edited (3) 300 Canada + 100 LER
50 LER Added (3) Edited
(2 and 3 consolidated)
100 Canada + 50 LER
Added
(2 and 3 consolidated)
1 2 3 4 1 3
Development Quality • Canvas created version 1 (Original Version)
Release 1+2+3+N Release 1 (LER)
• Under CR-1 Canada created version 2
1 2 3 4 • Under CR-2 LER requested Version 3
1
• Development Team Reverses Development to version 1
Quality • Development Team Creates version 3 (Excludes Canada Changes)
Release 1+2
(LER + Canada) • Canada must get the LER Repairs
• Canada Requests CR-1 scope change to Consolidate LER Repairs
and Canada modifications
Risk: • Development Team Creates Version 4
• Complex Process to manage • Canada gets version 4
• Good opportunities for error
• There is always subsequent addendums in either
release

CONFIDENTIAL DOCUMENT USE IN ACCORDANCE WITH COMPANY POLICIES 10

 Reversed Synchronization
N+1 to N

Reverse Production
Sync
Small Development Quality Canvas
Project Repair Repair 1+2+3

Normal
Sync
Normal
Development Quality North America
Project Release 1+2+3+N Release 1 1+2+3
Release
Quality
Release 1+2
ASPAC
1+2+3
Quality
Release 1+2+3

Attention: Reverse synchronization is intended for small projects being

executed in the repair environment and are scheduled to go live prior to
the large release (dual project execution touching the same project –
parallel common object)
*Simplified system landscape presented based on current system landscape model

CONFIDENTIAL DOCUMENT USE IN ACCORDANCE WITH COMPANY POLICIES 11

Guidelines for Parallel Common Objects

• Each WRICEF must have it own CR per environment (One in Repair environment and
one in the main project environment)
• Repair break fixes must be consolidated as additional scope of the existing repair CR
(there must be one and only one CR per RICEF in the repair environment)
• Both CRs (The one in the repair environment and the one in the project environment)
must be properly linked and each additional scope request must be reviewed as one unit
(Parallel Common Object Change control)
• Back to back replication of code must be done upon QAS approval of each addendum
• Each developer must work as one integrated team for this object (clear communication
channel between both developers)
• There must be one and only one design owner for each Parallel Common Object.
• Object is frozen for changes at the end of ST / beginning of UAT. At this point a
subsequent CR can be opened (will handle subsequent repairs or enhancements).

CONFIDENTIAL DOCUMENT USE IN ACCORDANCE WITH COMPANY POLICIES 12

Q&A

CONFIDENTIAL DOCUMENT USE IN ACCORDANCE WITH COMPANY POLICIES 13