Meet our client: Zurich Treasury Services

Zurich is a leading multi-line insurer that serves customers in global and local markets. They provide a wide range of property and casualty and life insurance products and services in more than 215 countries and territories. Zurich Treasury Services (ZTS) is a highly regulated and geographically diverse organisation within the wider Zurich business.

The challenge: A reporting solution required

Business intelligence and reporting was proving to be a challenge for ZTS, and was impacting the effectiveness of the business. There was no treasury data consolidation and reporting solution in place and as a consequence reporting requirements became high cost, complex and had a long lead time.

The high-level business requirements were: 

  • Increase cost-effectiveness: Implement a cost-effective solution using the data already existing in several core systems, which lack consolidation.
  • Increase agility: Increase agility and reduce time to market of reporting solutions.
  • Reduce complexity: Leverage other Azure services to take advantage of integration points with other services. This would reduce complexity of future reporting services.

Zurich Group Functions and Shared Utilities (ZGFSU) undertook a proof of concept to simplify the reporting set-up for ZTS, and consolidate all treasury data in a centralised repository to provide reporting capabilities.

The proof of concept was conducted in AWS and Microsoft Azure platforms to assess the feasibility of the solution and compare both vendors. Out of the two, Microsoft Azure was chosen for the reporting solution and an Architecture Specification Document was produced.

QA delivered training to ZGFSU so they would be in a strong position to deliver the reporting solution for ZTS. Following this, QA was approached to help ZGFSU to implement the reporting solution for ZTS. We worked with our strategic partner, IJYI – a bespoke software delivery company – on this project for ZTS.

The project:

Discovery phase:

QA delivered a discovery exercise with ZGFSU to determine the design, implementation and training requirements to build the reporting solution based on the Architecture Specification Document (ASD). The deliverable was a design viability summary to review the requirements and design within the ASD to assess if the requirements could be met by the design, and also to detail the next level of functional and non-functional requirements.

It also produced an implementation plan for the solution. The scope included:

  • The underlying Azure capability – networking, AD, IaaS and PaaS
  • Data ingestion – data factory connectors
  • Data storage solutions – storage blob and data lake
  • Data transformation (ETL) in Azure – data factory

The ASD provided a solid blueprint for implementing the treasury reporting solution, but some changes were recommended, including:

  • Adopting an Extract Load Transform (ELT) approach rather than Extract Transform Load (ETL).
  • Maintaining security mapping hierarchy (Reporting Units) within a separate data source (not Azure AD).
  • Loading data into Azure Data Lake v2 Store rather than blob storage to allow greater flexibility in the future.
  • Hosting the Azure Data Factory v2 Integration Runtime (IR) with the Zurich on-premise network (or an attached VNet in Azure).
  • Curating and maintaining meta-data within Azure Data Catalogue to provide self-discovery of data sets.

PHASE 0:

A Phase 0 validation assessment was requested to de-risk the delivery of Phase 1 of the reporting project. Areas investigated included:

  • Azure subscription/configuration readiness
  • Express Route and internal firewall readiness
  • Identity and Access Management configuration and suitability for the project ahead
  • Current Power BI environment and permissions health check

No blocking issues were identified during the assessment. Several issues were identified and resolved/mitigated, which enabled a continuation of effort into Phase 1.

PHASE 1:

In Phase 1 the solution was implemented for the agreed ‘Priority 1’ reports identified in the discovery phase. The delivery was broken down into three activity areas:

1. Infrastructure Design, Build and Test

Setup of the environments and the CI/CD process to enable continuous delivery of a reporting solution. Including the scripting of the platform inf rastructure and testing/validation of the CI/ CD process.

2. Report Generation and Knowledge Transfer

Enabled the first few reports to be delivered whilst Zurich shadowed the SA and PM roles so that these roles can be undertaken by Zurich.

3. Phase 1 Report Delivery

Enabled the completion of the Phase 1 reports whilst also establishing the BAU structure and processes for ongoing delivery of the reporting function.

Future support

1. Report delivery

Maintaining momentum from the first phase 1 deliverables will be key to gaining further traction within ZGFSU for the new reporting solution. We recommended continuing straight from Phase 1 reports into ongoing delivery of the new DataMarts/Reporting capability. This would enable the team to be made up of the same individuals from the final Phase 1 stage to maintain knowledge, culture and momentum. The team is now much more of an “implementation engine” completing the existing report sets, working under the direction of the Zurich capability owner and solution architect.

2. Support and report generation

We have proposed options for the ongoing support of the reporting solution (IaaS, PaaS, etc) plus an option for a further report generation team that can service future report requests and changes from the business.

Want us to help you too?

Click below to fill out a contact form, or email info@qa.com. You could also call 0345 074 7825. 

Let’s talk Learn more about our Talent Services

Related Articles

Comments

Be the first to comment!

Add a comment