Q&A: CIO Mark Clark on Balancing Legacy and New Technology at Jackson National Life

Jackson National Life recently surpassed the mark of $100 billion in assets largely because of a prudent approach to pricing annuities prior to and in the wake of the 2008 financial crisis. The company's sales have grown from $5 billion to $20 billion over the last 8 years, and it now ranks among the top three annuity providers, along with Prudential and MetLife. Jackson CIO Mark Clark joined the company in 1996 from Cooperative Technologies, a firm he co-founded. He has more than 25 years of experience in the financial services and information technology industries. Clark recently spoke with Insurance & Technology's Executive Editor, Anthony O'Donnell.

Anthony O'Donnell: Jackson has enjoyed tremendous growth at a time when other annuity companies have been struggling. How did the company's strategy foster that outcome?

Mark Clark: We came through the latest crisis due primarily to the quality of our risk management. We have very sound risk management. That was reflected in our investment management, and our product pricing was very rational compared to some of our competitors. We call our prudent approach to business "long-term smart." We understand that the business has cycles, and we resist doing irrational things when things are good, so that when things go bad, we're ready for it. As a result of that management philosophy we've really come through the latest crisis in very good shape, doubling our assets and ranking among the top three producers.

Mark Clark

AO: How is the "long-term smart" philosophy reflected in your technology investment decisions? Has Jackson's IT organization avoided the temptation to act irrationally?

MC: It's a matter of mitigating risks, minimizing the complexity of your IT environment and leveraging existing technology assets. Many technology guys want to jump on the newest technology, saying, "Isn't this cool! I could cut my development time in half with this tool." But if you've been in the business long enough, you know that new technology surfaces every other day in this business. If you jump on every new technology you'll find yourself supporting an increasing complex environment. You have to be careful about which tools you pick, so that over the long haul you're not supporting hundreds of different technologies and libraries. We try to choose the technologies that really give us a benefit while continuing to leverage the stuff we have in place that has been proven to work.

AO: How do you balance this kind of prudence with the threat of competitors developing technology-driven capabilities that might leave you behind?

MC: You have to find ways to make use of the new technologies without throwing out the baby with the bathwater, if you will - without risking the stable platforms you already have. It's always a challenge to strike the right balance.

AO: How have you struck that balance in some of your major platform decisions?

MC: We are working on improving our capabilities in a lot of different areas in, and one of those is our movement toward a single policy administration platform. We have made a lot of inroads there, and by the end of this year, all of our products will be issued on CSC's [Falls Church, Va.] Cyberlife platform. We had some business on an EDS [now HP Enterprise Services; Palo Alto, Calif.] platform called Equity+, and another set of business on our CSC Vantage platform, and we're moving all of that to Cyberlife. We plan to complete that work by the end of 2013, at which point we will have one of the largest Cyberlife implementations in the industry, in terms of policy count.

It's a large project. Many times when you're doing conversions like this, they're on closed blocks of business that can be done pretty quickly. But we're launching a new product basically every three months here, and so you have to keep up, making mods on both systems while you're converting the new business.

AO: How do you manage to keep up that pace of new product launch?

MC: We have a speed-to-market new business process called Sprint led by our chief actuary, and including everybody involved in product development, including IT, legal and compliance. It's a major focus of our company, so Sprint projects typically have priority over everything else that's going on.

We have a new product committee, which consists of our CEO, COO and all the other C-level officers, as well as some key individuals in the product pricing and marketing areas. That group meets monthly to evaluate new product projects and either approve or disapprove them. Once an initiative is approved, the Sprint process kicks in, and the chief actuary put the project through its paces. She runs a very tight ship, ensuring that that the right expertise is engaged and that everybody has aggressive deadlines.

AO: Returning to your single policy administration platform strategy, what are some of the benefits Jackson expects from it?

MC: Among the most important gains are reduced maintenance costs simply from having a single platform because of things like regulatory changes that you only have to do once instead of multiple times. But also, as you look at wrapping automation throughout the company having a single platform is a huge advantage. So when we start driving processes with business rules, putting things out on the web, and considering developing mobile applications - all the things you want to do in the modern world - having to interface with a single system significantly drives down the costs of those initiatives, and in fact makes those things possible from a financial perspective. So it's a hugely important strategy to us, and if we were to bring in additional business through acquisitions or something like that, we would continue that strategy going forward.

AO: Cyberlife is not what you would call one of the most modern systems, when one talks about embedded rules and configurability. Any comment about the choice of that platform in that light?

MC: People are very concerned about the fact that some of these legacy systems are written in COBOL, and they might exist on the mainframe. So you read articles about companies that are moving toward newer technologies such as Java. The problem with that is that a lot of these systems have been in place since the 1960s and they've seen lots and lots of transformations from Assembler to COBOL, for example, but over the years the amount of business logic built into these applications is very difficult to replicate in another environment. Over my career I've seen many failed attempts to move to newer technologies just for the sake of technology and finding that those projects go into massive overruns. So rather than worry about the core engine - which is written in COBOL - what CSC does, and what we applaud and do ourselves, is to wrap that legacy application with modern technology. So what you see on the front end of CSC is Java middleware that allows you to access the business processes and functions within the mainframe applications through web services. We further wrap that infrastructure with some business rules technology. So you can use the modern technology and still have the benefit of the years of business logic that exists within that legacy application.

AO: Don't you still have concerns that the core engine is written in legacy technology?

MC: I think many people are very concerned with their COBOL and mainframe applications because colleges are not teaching COBOL anymore. I'd love to talk to some computer science departments about that, because there's still a large, large infrastructure of COBOL that exists in the world that needs to be supported going forward and Baby Boomers are retiring. We find ourselves doing a lot of internal training to keep up with the number of people required to support those applications.

AO: So that's a tradeoff you make in order to leverage your large existing technology investment?

MC: Yes, that's the proposition. You need to be able to maintain that platform; there's no real business reason to convert off it as long as you continue to train people to support it. Whereas many have outsourced that to people like CSC, we have chosen to keep it in house because we're able to respond to market conditions. And quite frankly, we want to keep Sprint projects and that type of thing internal at Jackson. So we train people.

AO: But long as you can do that and wrap the underlying technology, you're able to pursue modern capabilities. Could you give us some examples?

MC: One of the more interesting things we're doing at Jackson is what we call our JPOD [Jackson Process on Demand] initiative that uses business rules to drive processing. We're trying to take away many of the mundane tasks in order to free up people to do the more interesting work.

We're also looking at the way we test. We've enjoyed phenomenal growth at this company, but the way we tested when we had 50 programmers doesn't work anymore now that we have 300. So we are ramping up our testing environment, using virtual machine technology to allow us to create testing environments on the fly for various projects, and then dismantle that testing environment when the project is finished. With virtual machines you can do that sort of a thing, whereas in the past, going out and buying a new server for every project seemed insane. Even reusing servers is problematic sometimes, but with virtual machines it's much easier to configure a test environment, run the project from the ground up with it, and then just dismantle it when you're done. It's a new concept that we're working on employing over the next 18 months.

We also have an initiative going with CSC to modify the way we process tables. We have over 5,000 different reference tables that we use at Jackson to configure new products, etc. Maintaining those tables is becoming quite people intensive, and there's a lot of mundane work there, so we're looking at automating that.

We're looking at our cycle processing itself, our night-time cycle processing, and given the phenomenal growth we have, our cycle window is something we need to look at. So we're looking at splitting that cycle processing into parallel processors to get that done more efficiently.

AO: Perhaps you could give us some concluding observations on you you've dealt with the strain rapid growth has put on your infrastructure.

MC: It brings a lot of interesting problems, but they're all good problems to have. Our systems have proven very scalable. If we have a spike in volume on the new business systems, for example, we have successfully added servers. The challenge, of course, is to make sure that your forecast and all the metrics you have in place foresee the need to increase those servers and the capacity before the event actually occurs. That has actually worked quite well here, too.

For example, last November we saw CICS transaction counts on our mainframe system climbing at a fairly steady rate. Forecasting to the end of the year, we saw that around April we would have a serious problem, so we launched a project to split Cyberlife into two different CICS regions to handle the capacity. We got the project done in March, and in April we started seeing the cracks and were able to switch over to those two regions, and everything worked well. One of the things we're putting in place is Cyberlife's newest technology.

There's a strategic program which allows you to run Cyberlife in as many regions as you want and make the system fully scalable. In the same way the modern technologies are fully scalable by adding servers, with the Cyberlife mainframe we'll be able to easily add CICS regions going forward.

Anthony O'Donnell has covered technology in the insurance industry since 2000, when he joined the editorial staff of Insurance & Technology. As an editor and reporter for I&T and the InformationWeek Financial Services of TechWeb he has written on all areas of information ... View Full Bio