Corneil du Plessis, the chief architect at JumpCO holdings discusses the interesting topic of accelerating tech delivery in the insurance industry.
Tony: I recently spoke to Sanlam about their E-nnuity, because that’s one of the interesting projects where JumpCO was involved. Being the Chief Architect at JumpCO Holdings you must have been very involved there. What role did JumpCO play in the process?
Corneil: It was a time when companies were still figuring out outsourcing. In this case, they had built one part of the solution in house, which was the core calculator, but they needed to put a face on it. I think they deemed that it was not high risk, because the risk of the success was primarily within the calculator and since the audience would have been brokers and not people that they didn’t know, in other words, somebody they could manage; I think that helped them decide to take the chance of getting an external company involved.
We were a small, highly focused team because, if you put a lot of people on there, they step on each other’s toes. What made it happen is the fact that they had people who knew what they wanted to see, and we worked closely together to drive towards that goal. Their core group IT architecture team was involved in laying down some ground rules in terms of how some of the things should be done to ease integration with their system and to make deployment of the application the same as all the others. And so, we incorporated their guidance on that side and for the rest, we stuck with things that were relatively standard at the time.
Tony: So, once you were implemented, you’ve got JumpCO on one side and Sanlam on the other side. Both have expertise in terms of what has been implemented, so, how does that project then evolve over time and what role do you play?
Corneil: Well, the financial market isn’t stagnant, so, we knew from the start that annuities, life insurance, retirement policies, all these things are long term projects. So, we made some decisions upfront, that would make it easy to implement certain types of changes. Then when the changes came along, with the addition of new products and little improvements to things. For example, the quotation document. The annuity policy contract, the quotation document, and the policy contract must all be aligned. So, whenever there were legal requirements that came in, we had to update those, and we had to do it quickly.
When it came to big changes like a brand-new product, it took a bit longer, but invariably, we were ready in short order. Sanlam was still developing the additions to their calculator at that stage, and we had to wait for them to complete the work on their side, which is one of the things that, over time, became an obstacle. I suggested about five-six years ago that we consider rewriting the calculator for them. On the one hand, it would provide improved performance and on the other hand, the whole development cycle and experience. The people who had developed it were part of the actuarial team, they weren’t professional software developers, so they understood the math, and they implemented the math. But there were aspects of it that were a bit, we use the term clunky, it was correct, but it wasn’t optimal.
We then took a test-driven approach, which basically meant that they provided us with test data, which they had prepared, based on their reference models that described all the inputs and outputs of a calculation with a whole spread of options. We then used those to drive the process so that this new calculator would be a separate library that was included in the application. It performed very well, and it was accurate to the cent.
We also built some tools around that process to make it easy for the people on the actuarial side. The lovely thing is, now that I have a document, what they call the basis, which describes the calculation, they have their reference implementation, and we have our implementation and the two must agree. I mean, that’s how we think because then the two pieces of code implemented by two people are doing the same thing. And whenever we found a difference, we would dive in to find the reason. It was sometimes a misunderstanding of the basis, or something that needed to be clarified and big ambiguity removed. Sometimes it was a simple error, but it ended up with clarification of the core document, two implementations that matched, which is now ideal for this kind of project.
Tony: So, you’ve got two different teams working with each other over a long period of time. That collaboration is quite difficult, especially when it comes to dividing tasks and responsibilities. What do you believe were the success factors in this case?
Corneil: Well, whenever there was any change, we made sure that we understood what was needed. I had conversations around it, documented the outcome of those and then worked. We gave them very quick feedback, because we have a test environment where we can deploy within a few minutes of making a change, and it’s ready for them to test. They would then be able to see it in action, which meant that we could move and give feedback quickly, whether it was a screen change, a document change, or whatever. In fact, the document changes we could do even quicker, because we had the data, we could run the document template and generation locally and send them the result and then they could look at it and say, yes this is what we want or no this is not what we want. So, we don’t have to wait until it’s in their test or pre-production environment before we get feedback, we cut that feedback loop short.
Then the other thing is that the moment that there was an issue we would, at that time, capture these issues, prioritise them for whether they need attention now or whenever, but nothing gets lost. This way the client is the one that’s in control of the priorities, deciding what must come first.
One of the factors that contributed to easy collaboration between Sanlam and JumpCO was the choice of technologies. The E-nnuity application was deployed onto IBM WebSphere Application Server (WAS) which was the standard for Sanlam. JumpCO was pleased with this decision as we had many years of IBM WAS experience and were familiar with IBM WAS’s robustness and easy to configure processes. This made for easy collaboration with the Sanlam team as JumpCO deployed and tested the application on IBM WAS before handing over to Sanlam for testing and signoff. This made for an easy, smooth transition from JumpCO to Sanlam.
Tony: Thinking back, anything that you would have done differently?
Corneil: It is easy to make a list, but I think we made a lot of good decisions. Sanlam said they wanted us to deploy into IBM WebSphere. The choices we made early on and made for a relatively smooth deployment into WebSphere Application, because we used a framework called the Spring framework. This gives you a slightly higher layer of abstraction around some of the concepts and it protects you around some of the differences between versions of the Java Enterprise Edition spec, which is what WebSphere implements. We had a smooth path to upgrading through these versions.
I think it is always important to remember that no matter what you do, look at what the standards are before you jump in, and be ready to adapt as things change. In this case, the standards involved were Java EE which was implemented by IBM WebSphere.