apidays LIVE Helsinki & North - Bye bye to the insurance monolith - case Euler Hermes by Sophie Rutard, Euler Hermes
•Download as PPT, PDF•
0 likes•1,305 views
This document discusses an insurance company's transition from a monolithic IT architecture to a microservices architecture using APIs. Some of the key challenges in the transition include ensuring consistent API design, implementing cloud infrastructure securely, complying with regulations, maintaining quality and resilience across many independent services, and aligning planning between multiple API-based products and teams. The goals of the transition are to enable greater agility, simplify global collaboration, and move away from the limitations of the monolithic "culture."
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to apidays LIVE Helsinki & North - Bye bye to the insurance monolith - case Euler Hermes by Sophie Rutard, Euler Hermes
Similar to apidays LIVE Helsinki & North - Bye bye to the insurance monolith - case Euler Hermes by Sophie Rutard, Euler Hermes (20)
More from apidays
More from apidays (20)
Recently uploaded
Recently uploaded (20)
apidays LIVE Helsinki & North - Bye bye to the insurance monolith - case Euler Hermes by Sophie Rutard, Euler Hermes
- 1. Strictly Confidential Sophie Rutard API days Helsinki Mar 16th, 2021 BYE BYE INSURANCE MONOLITH CASE EULER HERMES 1
- 2. 2 CREDIT INSURANCE IS AN ENABLER FOR GLOBAL TRADE
- 3. LEADING THE WORLD OF TRADE CREDIT INSURANCE and part of Allianz today >100 years
- 4. 1920S
- 5. 1960S
- 6. 1970 - 1980 - BIRTH OF THE MONOLITH!
- 7. 1990S - GLOBAL MERGERS CREATE THE MULTI MONOLITH
- 8. 2000S TRYING TO MANAGE WITH SOA AND ESB
- 9. BUT THE ISSUES KEPT GROWING Aging technology! Poor Time to market!
- 10. THEN WHAT? RENEW THE MONOLITH?
- 11. WE HAVE TO SLICE DOWN THE COMPLEXITY INSTEAD
- 12. PIECE BY PIECE WE’RE RENEWING OUR IT
- 13. BUT THEN YOU CAN’T MANAGE IT ALL TOP DOWN ANYMORE PO PO PO PO
- 14. 14 SO THANK YOU, SPOTIFY! API Product owner API Tech lead Scrum master, BA; devOps API Product owner API Tech lead Scrum master, BA; devOps API Product owner API Tech lead Scrum master, BA; devOps • Product vision • Business Strategy • Target user groups • Quality of service • Technical design • Performance • Sustainability • Deployment IT + Business working as one team!
- 15. 15 CHALLENGE #1 - CONSISTENT DESIGN API Product owner API Tech lead Scrum master, BA; devOps API Product owner API Tech lead Scrum master, BA; devOps API Product owner API Tech lead Scrum master, BA; devOps
- 16. 16 CHALLENGE #1 - CONSISTENT DESIGN API Product owner API Tech lead Scrum master, BA; devOps API Product owner API Tech lead Scrum master, BA; devOps API Product owner API Tech lead Scrum master, BA; devOps API and Data governance teams ensure consistent Design • Maintain EH API design guide and API catalogue • Maintain EH Data model • Coaching squad’s POs • Contribute in design sprints • Validate Swagger / merge requests in Gitlab before dev • Maintain documentation and testing (Postman) guidelines
- 17. 17 CHALLENGE #2 - CLOUD-RELATED ASPECTS • API Security • CI/CD Pipeline • AWS Expertise and FinOPS • Monitoring tools API Product owner API Tech lead Scrum master, BA; devOps API Product owner API Tech lead Scrum master, BA; devOps API Product owner API Tech lead Scrum master, BA; devOps Cloud Foundation and IT security teams ensure consistent implementation ‣ IDP (OAuth2) ‣ Ressource Manager ‣ API Gateway ‣ Cloudfront & AWS WAF
- 18. 18 CHALLENGE #3 - REGULATION AND AUDIT • Mandatory process documentation • IT change mgmt • GDPR et al • Tracing of process with transaction ID • Testing needs to include those requirements API Product owner API Tech lead API Product owner API Tech lead API Product owner API Tech lead Common rulesets for the teams need to be defined and their implementation must be controlled.
- 19. 19 CHALLENGE #4 - RESILIENCE AND QUALITY • Automated testing • Issue handling and post mortem procedures • Continuous improvement • Code quality and performance • Versioning guidelines API Product owner API Tech lead API Product owner API Tech lead API Product owner API Tech lead Poor quality cannot be accepted where system dependencies are multiplied by the number of microservices
- 20. 20 CHALLENGE #5 - PLANNING AND ALIGNMENTS Customer Portal API-based products Internal applications Partner applications API Product owner API Tech lead Scrum master, BA; devOps API Product owner API Tech lead Scrum master, BA; devOps API Product owner API Tech lead Scrum master, BA; devOps API Product owner API Tech lead Scrum master, BA; devOps API Product owner API Tech lead Scrum master, BA; devOps API Product owner API Tech lead Scrum master, BA; devOps API Product owner API Tech lead Scrum master, BA; devOps
- 21. 5 Floors CHANGE TAKEN SERIOUS: BYE BYE, MONOLITH CULTURE! 22 Floors
- 22. ENABLING AGILITY AND DIRECT COLLABORATION
- 23. REMOTE WORKPLACE AND CULTURE SIMPLIFIES GLOBAL COLLABORATION ç
- 24. SO WHAT MAKES THE SUCCESS OF OUR TRANSFORMATION PROGRAM FINALLY? ç
- 25. THANK YOU! By the way we’re hiring! :-)
Editor's Notes
- Intro / role I’ll be demonstrating how we tackle API security in EH Our IT architecture is fully cloud oriented, mostly AWS.
- -Important element in worldwide trade -especially important in current situation with strong uncertainty and many who had to close business for a while -We support with coverage but also with insights (Grade and economic research)
- -world leading credit insurance company -part of Allianz -2nd largest insurer in the world.
- inspired from the Spotify model of various small squads, progressing autonomously from each other. It’s very beneficial because it brings together the different skillsets from both IT and Business. Very motivating for the teams to work like this because it breaks down organisational silos and politics. 2 key roles PO (business) and Tech lead(IT) It has however some challenges…
- Squad’s independency comes at the „price“of different development and design styles by the teams API and Data Governance is needed to align them on a consistent result = consistent Dx for API consumers (- All our APIs are designed so they can be used by an external audience.) In some cases, API Governance is knowledgeable about business and can contribute to the design; In others they can challenge like an external who would not understand what’s meant. In any case we try to make the design as intuitive as possible and to avoid any technical overhead Formal validation from governance team is required, no API can go live without it
- OAuth 2 for Authorizations Prometheus and Grafana for Monitoring WAF = Web application Filtering
- Introduce the Front end platforms! APIs serve to them! Requirements and prioritizations are issued to the API squads from various front end projects at a time It is difficult to come to a global planning when all teams are autonomous. But we need to do it because otherwise planning becomes too artificial like in any other huge project