The German insurance company Talanx embarked on a remarkable culture shift in a conservative industry when it tasked its Digital Lab to start deploying and running applications on Amazon Web Services (AWS) public cloud infrastructure. More recently, it underscored its success by adopting Cloud Foundry as its platform.
Talanx is based in Hannover and is one of the top 20 insurance companies in Europe. It underwrites more than 33 billion euro in premiums annually and has more than 22,000 employees. To its management, software development looks like a great waterfall, according to the lab’s Senior Software Engineer Daniel Basten: “The traditional waterfall software development approach worked quite well for us and for the insurance industry as a whole.”
“With the waterfall approach, we could make decisions about well-known effects and plan our software development lifecycle and architecture management for years into the future.”
Modern Times
But along the way, Talanx discovered 21st century technology, and realized it needed to be able to develop apps and services more quickly and with more agility if it were to meet its customer demands. So the Digital Lab was brought in “to do all the agile stuff” and bring new methodologies to the enterprise.
The lab team re-imagined the development and deployment process as a conceptual series of feedback loops, with a focus on minimum viable products (MVPs) – “bring some small pieces to market and see if they’re accepted,” as Daniel says.
The team also created a Build-Measure-Learn methodology. This process sits on a three-legged stool of agile methodology, a new software stack, and a flexible infrastructure. In the latter area, Talanx quickly adopted AWS, then learned how it could take the next step by automating and managing the infrastructure with Cloud Foundry.
Scrum and Planning Poker
Agile, as practiced by Talanx, involves the use of a scrum methodology that started with bi-weekly iterations (later compressed to weekly), dedicated product owners, story points, and the use of “planning poker.” This latter tactic involves team members placing cards face down while making individual estimates of team goals, rather than setting precedents (good and bad) by basing estimates on the opinion of the first person to speak out loud.
Daniel says it was not easy to convince everyone in a large enterprise such as Talanx to make the journey from waterfall to scrum, but the advantage of being able to think in terms of a few weeks rather than years gradually swung people around.
Many Pieces in This Puzzle
Talanx’s legacy architecture is comprised mostly of J2EE and Websphere apps. To migrate to the more agile approach required a new software stack that features several popular cloud native technologies:
- The Angular web platform for the front end, which Daniel says gives the dev team everything they need to build apps
- The Swagger framework, to generate source code for the Angular bindings
- The Spring Boot framework, to enable the rapid development essential to the overall migration
- The Spock Java testing framework, to enable the team to write texts in a more declarative way and create data tables. Spock provides the additional advantage of delivering test results to the business side so they can check results
- GitLab, which pipelines every request and enables immediate feedback to developers
- Jenkins CI, which lets the team put all pipeline declarations into their code
- The MariaDB fork of MySQL and Flyway database migration tool
Talanx also employs the CRQS/ES (Client-Ready-Quote-System/Event Sourcing) system that’s popular across the financial services spectrum, to enable the company’s decision-making capabilities. Its initial reach to the public cloud involved AWS for ECS (Elastic Container Service) and RDS (Relational Database Service) to enable a persistent back end for its high volume of transactions.
Team members found they got a quick start and awesome performance. “We could access what felt like unlimited resources from Amazon simply by using a credit card.”
But the technical complexity found within this alphabet soup led to a re-assessment by the Talanx team, and they brought in Cloud Foundry to address some time-wasting issues. They found themselves spending a lot of time curating Docker images, for example, patching EC2 instances, and integrating new services.
They’re now able to add microservices, thus obviating the need to remove Docker images, and they’ve removed the need for manual network engineering and other operational processes.
Remember the Customer!
“With Cloud Foundry we’re moving to a completely self-automated environment. For example, we use cf-push instead of doing a manual cloud formation stack update. It’s also much easier to deploy new apps and services.”
“The shift from AWS IaaS to Cloud Foundry PaaS was a major achievement.”
Despite Talanx’s ability to realize technical success, Daniel offers some cautionary advice from the organizational point of view. He says that companies migrating to a large cloud environment must be aware of the changes it can bring to the organization, must have continued top-level management buy-in, find passionate people to set up and run Cloud Foundry – and remember, that developers are customers!
“You have to establish Cloud Foundry as a product, and handle your own Cloud Foundry installation as your own product.”
