Lily Craps, responsible for the Mainframe outsourcing project at SDWorx, explains how the moving of their mainframe to a shared environment at NRB, enabled ‘economies of scale’ on infrastructure costs for hardware and software. She describes the process, from starting the outsourcing study, over the RFI/RFP process, the selection of the provider, the contract negotiations and the migration project, next to the criteria for choosing NRB and an Infrastructure As A Service –cloud model.

1. Outsourcing
SDWORX Mainframe
environment
26/05/2016
Lily Craps - SDWORX

2. Agenda
2
1. About SDWORX
2. Why Outsourcing?
3. Why NRB?
4. Project goals
5. Project tracks
6. Technical track details
7. Services and procedures
8. Testing
9. Project evaluation
10. Conclusion

3. 3
1. SD Worx
A brief introduction
Antwerp (HQ) - Berlin - Breda
Brussels - Frankfurt - Luxembourg - Paris
Payroll - Tax & Legal - HR Consulting - Learning
Technology services - Outsourcing
2,700
HR professionals
60,000
Client base
2,350,000
Payslips per month
70 years
of expertise
€ 262 million
Total turnover 2014

4. 1. SD Worx
Learning
Targeted and sustainable advice on Payroll,Tax & Legal, Reward,
HR Projects and International Employment
Automation of all payroll and HR processes
Payroll solutions, offering various outsourcing levels from SaaS
(Software as a Service) to full Business Process Outsourcing
Payroll
Efficient payroll calculations
and administration
Tax & legal
Tax and social-legal support
HR
Support for all
of your HR processes
4
Purposive courses allow HR employees to shine
Technology Services
Outsourcing
Consulting

5. 5
• Moving of our mainframe LPARS to a shared mainframe environment, achieving
‘economies of scale’ on Mainframe infrastructure costs for hardware and software.
• Triggers:
• Work on Cost Program
• New required investments: DASD subsystem needed to be replaced
• Process
• 12/2013 Start study outsourcing Mainframe environment
• 01/2014-06/2014 RFI/RFP process
• 07/2014 Selection provider
• 08/2014-11/2014 Contract negotiations with NRB
• 12/2014-05/2015 Migration project
2. Why Outsourcing?

6. 6
3. Why NRB?
Evaluation criteria ( evaluation matrix – objective decision)
• Price
• Other criteria:
• Quality RFP proces - contacts
• Location ( team on one location or separated, West-Europe … )
• Quality transformation and transition during migration phase
• Flexibility concerning ITIL processes ( change requests, problem solving )
• Current infrastructure
• Flexibility SW versioning
• DRP solution
• Availability and performance
• Security base line assessment
• Network: latency
• Optional: additional savings

7. 7
4. Project goals
• Moving of our mainframe LPARS to a shared mainframe environment at NRB, achieving
‘economies of scale’ on Mainframe infrastructure costs for hardware and software
• Ability in a later stage for additional savings related to ISV (Independent Software
Vendors) : contract merge, SW replacement.
• Infrastructure As A Service (IaaS cloud model)
Only hosting hardware – all system engineering activities remains @ SD Worx
• Integration of change management, incident management and DR processes between SD
Worx and NRB for Iaas related activities.
• Ensuring the transparency for business with at least the same performance, availability
and with state of the art technology - at a lower cost.

8. 8
5. Project tracks
• Technical
• Transformation tracks
• Cut-over actions
Both for:
• Distributed servers (latency sensitive applications)
• Mainframe
• Network
• Services and procedures
• Testing

9. 9
6. Technical track : transformation
5 important technical tracks to be executed before testing & migration :
• Distributed applications: move latency sensitive applications to separated servers
• TCPIP change track : Change IP addresses of all lpars to avoid IP and network changes
during cut-over weekend(s)  Reduce risk and complexity
• GENERAL ‘MF infrastructure preparation’ track: create a ‘landing platform’ for all the
SDWORX lpars  Make sure all basic infrastructure is in place and corresponds to the
SDWORX needs
•
DISK migration track : Setting up an asynchronous replication mechanism between the
secondary SDWORX MF disk subsystem and the new primary disk infra at NRB allowing
smooth testing and ‘fast’ cut-over.
• TAPE Migration track : Convert tape data from CA-VTAPE to hardware VTS solution and
allow tape data to be migrated ‘in advance’ to NRB using VTS GRID functionality.

10. 10
6. Technical track : MF hardware
CPU (existing zEC12-505 CPU – 347 MSU)
• Target : zEC12-614 (4 Shared CP’s + 2 ‘Dedicated’ zIIPs)
• ‘absolute capping’ to limit peak CPU behavior
DISK (existing DS8830)
• Target : DS8870 with flash storage modules and EASY TIER (production environments)
( I/O RT improvement )
TAPE (existing CA VTAPE software virtual tape solution)
• Target : IBM TS7720 virtual tape solution - ONLY on disk.
( tape access time improvement)
CONNECTIVITY
• LAN (4x 1 GbE ports available - 2 ‘isolated’ for preprod & 2 for other partitions –
active/passive)
(to-be equal to as-is situation)

11. 11
7. Services and procedures
• Integration of change and incident/problem management procedures SD  NRB
• Operational Guide
• SLA’s :
• Availability
• Incidents
• Change requests (CPU , Disk , Tape capacity ) – emergency
• IT Continuity
• Performance
• Netwerk latency
• Disk PPRC
• CEC capacity (SYSP and SYSG lpars can peak at least 20% above their
defined capacity , the other lpars can peak at least 15% above their
defined capacities)
• Dummy applications (I/O, CPU)

12. 12
8. Testing: formal process
• Testcoördinator
• Formal acceptance criteria ( part of contract)
• Detailed testscenario’s
• Governance:
BusinessBusiness DevelopmentDevelopment Dev support MFDev support MF
Central systems MF &
Servers team
Central systems MF &
Servers team
Test responsible
Tanja Michielsen
Test responsible
Tanja Michielsen
Project leader
Lily Craps
Project leader
Lily Craps
Technical contactTechnical contact
NRBNRB
Test preparation request
Green light to start execution
Test preparation ready
Test execution results
Reported issues
Issue dispatching and follow up
Reporting results & issues
Escalation
Test teams

13. 8.
Central System + Dev support (MF)
Development (Dev + Test)
Business
SYSP
SYSW
+
distr.*
Pre-phase
maart-april
Phase 1
9-16/3
Phase 2
25/4
Phase 3b
14/5
Growing team involvement and growing scope per phase ensures the main MF switch
activities are repeated multiple times which leads to higher confidence
Focus on quality attributes:
• Connectivity
• Accessibility
• Functionality
• Performance (limited)
• Migration
NRB (Infrastructure)
Central Systems (MF) SYSA/B SYSI **
SYSD ** +
distr.*
* distr. = distributed/decentral system(s) ** including DRP testing at NRB
Server services team
Phase 3a
8/5
SYSG
8. Testing
“Phased approach”

14. 14
9. Project evaluation
+
• Cooperation with NRB very professional and positive - both PM and technical staff
• Planning was respected during whole project.
• Staged migration whereby lessons learned were included in subsequent phases with an
error free migration of the production Lpars
• All IT departments the same focus/prio to this project: has led to internal smooth
cooperation between the various units and teams
-
• ISV contracts: some outsourcing fees to be payed

15. 15
10. Conclusion
Moving of our mainframe LPARS to a shared mainframe environment at NRB,
achieving ‘economies of scale’ on Mainframe infrastructure costs for hardware
and software
Ability in a later stage for additional savings related to ISV (Independent Software
Vendors) : contract merge, SW replacement.
Infrastructure As A Service (IaaS cloud model)
Only hosting hardware – all system engineering activities remains @ SD Worx
Integration of change management, incident management and DR processes
between SD Worx and NRB for Iaas related activities.
Ensuring the transparency for business with at least the same performance,
availability and with state of the art technology - at a lower cost.
Project goals

16. Thank you
Any questions?