2. Session Agenda
• Introductions.
• Project Overview.
• Challenge at hand.
• Why Visual COBOL.
• Challenges along the way.
• Looking Ahead.
• Q&A.
2
3. Sammons Financial Group
• Mike Schweizer – AVP
• Paul Schiltz – Applications Architect
• Jon Stahl – Applications Architect
3
4. Who Are We
Life
Insurance
Corporate
Services Annuities
Sammons
Shared Financial Corporate
Services Markets
Group
Sammons Sammons
Retirement Securities
Solutions Company
4
5. What We Do
• Annuities • Variable Annuities
• Fixed Index Annuities (Top • Mutual Funds
Seller)
• Fixed Annuities, Immediate • Corporate Markets
Annuities, Multi-Year
• Bank Owned Universal Life
Guarantee
Insurance
• Life Insurance • Credit Union Owned Universal
Life Insurance
• Index Universal Life (Top Seller)
• Universal Life, Term, Variable
Universal Life
5
6. Our Locations
Chicago Sioux Falls Des Moines Fargo
137 Employees 591 Employees 458 Employees 69 Employees
• Life Insurance Shared Services SFG Executive Corporate Markets
Executive Office Executive Offices Offices Executive Offices
Operations Center Annuity Executive Operations Center
for Life Business Offices for Corporate
Operations Center Markets
for Annuity Business
Sammons
1255 Total Retirement
Solutions Offices
Employees
6
7. How Are We Unique and
What Have We Accomplished
• Privately Owned ESOP Companies
• Variety of Distribution Channels
• Strategic Focus on Creating Long-Term Value and Keeping
Promises to Our Policyholders
• Midland National & North American Consistently Rank Within
the Top Ten Annuity Carriers in the US (AnnuitySpecs.com)
• Record Production in 2010 and 2011
7
8. Project Overview
• PolicyLink – Policy Administration System.
• Processes the core functions of the annuity business.
• Base system with user enhancements added over the years.
• Code consisted of native COBOL, COBOL .Net, C# and
Webforms.
• Various interfaces to external applications and data primarily
via SQL.
8
9. Project Overview
• 2200+ COBOL Modules.
• Tightly integrated – Many modules are re-used throughout
the system.
• Stand-alone modules and stand-alone modules that share
modules with the admin system.
• All modules need to be compiled with the same compiler
options to maintain integrity of the system.
9
10. Need to Modernize
• Aging system – independent study.
• Needed a better way to interface with external applications
including SQL.
• Design options were limited under native COBOL.
• Development savings were not able to be realized.
• Wanted an infrastructure that would allow access from a
screen, a web service or both.
10
12. Challenge – What we wanted to accomplish
• Modernize the admin system as fast as possible.
• Minimize the business impact.
• Keep the cost as low as possible.
• Minimize the testing effort.
• Leverage our developer knowledge base.
• Minimize the training effort.
12
13. Why Visual COBOL?
• Any non-COBOL language would require a re-write of the
admin system.
• Existing system was written with Micro Focus COBOL.
• Positive experiences with Micro Focus in the past.
• Visual COBOL allows for the flexibility of coding in .Net and
Java environments.
• Our annuity applications are coded on the .Net platform.
• Our sister companies are coded on the Java platform.
13
14. Why Visual COBOL?
• Our developers were already familiar with Visual Studio so the
training effort was minimal.
• Visual COBOL is backward compatible and forward thinking.
• Visual COBOL Integrates seamlessly with other managed
languages.
• We were able to lift our existing code base and shift to the
managed environment with minimal code modifications.
14
15. Preparation
• Identified major tasks and allocated resources: programming,
management and reached out to Micro Focus for subject
matter expertise.
• Utilized the Micro Focus training course and in-house
instruction.
• Created an environment as close to our production
environment as possible.
• Performed unit testing, parallel testing and UAT testing.
15
16. Challenges
• Visual Studio Project Organization Options:
– One project with all modules.
– Group modules into logical projects.
– One project for each module.
– No project: Command line compile code.
16
17. Challenges
• One project with all modules :
– Visual Studio IDE could not handle a project with 2200+ modules.
– IntelliSense would eventually crash the IDE.
– Result: A one project solution for our admin system was not possible.
• Group modules into logical projects:
– Micro Focus performed a detailed analysis of our admin system.
– Breaking our system down into functional groups would have required
a great deal of analysis and recoding.
– Result: This option would have taken too much time and too many
resources – more than what we were willing to give.
17
18. Challenges
• One project for each module :
– Maintaining the code base for 2200+ modules would be a nightmare.
– Compiling 2200+ project modules would be a nightmare.
– Result: One project for each module is not feasible.
• No project: Command line compile code.
– By changing our build method the functional breakdown became
unnecessary.
– Switching from the inherent Solution/Project build process of Visual
Studio to a command line build process saved the day – Thank you
Micro Focus!
– Result: Command line compile was exactly what we needed.
18
19. Coding Challenges
• Recode SQL API calls.
• Configuration files necessary for every stand-alone
executable.
• Character based screen calls.
– Not supported under managed Visual COBOL.
– Removed code references and changed to use command line
parameters.
• Minor code tweaks.
• In general data types are stricter under managed code.
19
21. Solution Design
• All modules are dynamically linked at runtime.
• References to other modules included in a project are loaded
by the first call to the called module.
21
23. Automated the build process
Created an automated build process that uses the directives file.
23
24. Directives File
• Gives uniformity to the build process when using a command
line build process.
• Unique to COBOL.
24
25. Special Handling
• Those references that are specific to a module are declared at
the top of the module rather than in the directives file.
25
26. Configuration Files (.exe.config)
• One needed for each executable module. (.exe)
• SQL connection strings are defined inside.
– These connections will be defined here even though they may not be
used until later by a module farther down the line.
• Application settings are defined inside.
• Environment variables can be set here.
• Runtime settings are set here.
26
28. Challenges - Summary
• Micro Focus helped us in setting up our project organization
within Visual Studio.
• Micro Focus helped us with the new development IDE and
languages extensions by providing training online and in-
house.
• Micro Focus helped us setup our automated compiles so that
we could maintain the same consistency in compile options
that our current environment maintained.
• The entire code base was re-compiled under managed code
with very little modification.
28
29. Lessons Learned
• Have a project manager from the very start of the project.
• Install license software earlier in the project so that there is
more time to work out the bugs and handle special cases.
• Get help from Micro Focus in the areas where expertise is
needed.
• Spread the testing effort over more developers so that they
can get up-to-speed faster.
• Allow enough time for re-writing and testing modules that
you know are incompatible with the managed environment.
29
30. Future Plans
• Convert or re-write the existing screens into managed format.
• Break-out modules into functional groups.
• Continue to update older styles of coding to a more object
oriented style.
30
31. @microfocus or hashtag #devcon2013
Follow us on LinkedIn or join the group
Connect with your peers on the Community