Case Study: Pepper Group / Ignition

About Pepper Group

Enterprise Data Warehouses (EDWs) offer a highly governed and structured approach, but this structure makes them ‘personnel heavy’ and slows both data ingestion and ad hoc business reporting. The larger the business, and the older the warehouse, the greater the complexity. Faced with today’s big data challenges, many traditional EDW’s are struggling to keep up with the constantly changing demands of the businesses they serve.

Today even relatively modest sized businesses are struggling to house, understand, and leverage the data they are working with. And data-intensive organisations such as Pepper are only too aware of the real-world challenges that managing this data can create.

Pepper Group Ltd are a top 500 listed company on the Australian Securities Exchange (ASX:PEP). They are located across Australia, Asia and Europe with global investments in China and the US.

Being a diversified global financial services organisation with Lending, Advisory and Asset Servicing across the residential and commercial property sectors - as well as in consumer, auto and equipment finance means that Pepper have a unique set of data management challenges.

The Challenge

Charged with looking after the financial investments for tens of thousands of customers, across numerous products sets, and in multiple countries, data integrity, governance and compliance are at the forefront of Pepper strategic priorities. Faced with increasing complexity, Pepper wanted to break down their data silos. Their existing structure included several systems based silos, such as reporting marts built for a single system and line of business silos across finance, mortgages and their personal loans businesses. Pepper needed an infrastructure capable of leveraging these separate systems providing the flexibility and scalability to support the strategic ambitions of their business.

Pepper had traditionally adopted the Kimball DW approach. Operating multiple Data Warehouses, however the data load processes were labour intensive and costly. As they brought new data in, the associated business rules would have to be hard-coded to co-exist with the existing data. This meant that they were doing a lot of manual integration which was both time consuming and prone to human error - and was resulting in brittle Data Warehouses.

The Solution

Pepper’s key strategic priority was to reduce the operational burden of managing multiple Enterprise Data Warehouses, and consolidate its infrastructure to be more agile and responsive to the business. The Data Vault 2.0 methodology is the ideal solution to replace aging Data Warehouses that have become bogged down, overly complex and unmaintainable. In addition, the unique traceability that DV 2.0 provides makes it especially suited to merging or rationalising multiple data warehouses from disparate business units or organisations. By adopting the Data Vault 2.0 methodology Pepper is now focused on rationalising three Data Warehouses into a single Data Vault.

Data Vault 2.0 delivers full auditability by protecting the integrity and origin of the data. Whilst traditional methods only present a “single version of the truth,” cleansing or removing what does not fit with predefined business rules; a Data Vault can offer all the data, all the time within its scope. This provides improved accuracy and data integrity, allowing an auditor to trace values back to the source. This is exceptionally beneficial when merging multiple EDWs.

At its core, what Data Vault 2.0 offered Pepper is an infinitely scalable architecture that, is not only quicker to implement, load data and create reports but, also ensures that the data is trustworthy, correct and supports business processes. Once they had centralised their data Pepper wanted to unlock its value and gain a holistic or single view of their customers, allowing for effective market segmentation.

“Pepper had a lot of customer duplication, more than was initially realised. We had previously worked with the CMO to undertake a one-off customer segmentation exercise which required us to de-dupe and master the customer base before applying a lifestyle segmentation. We decided to operationalise this process through the Data Vault early in the project. This produced a massive uplift in analytic capabilities whilst proving that the Data Vault could make significant contributions to our customer strategy,” remarked Mellare.

Another key driver for Pepper was the knowledge that their new ‘enterprise’ and ‘digital channel’ strategies were going to introduce a lot of additional change, so they needed a solution that would minimise these pending disruptions. Anyone who has dealt with an Enterprise Data Warehouse understands the pain of working and interacting with them. Loading, validating, and managing data in an ever-changing business environment is an ongoing, yet specialised and complex, task. This means that it is usually costly, frustrating, and laborious for both the Business and IT.

“One of the first challenges that we faced was the introduction of a new Mortgages product. In the past, this would have been extremely problematic, requiring us to go back and update multiple data marts manually. This was extremely labour intensive and time consuming.” Said Mellare.

The Outcome

Because of the simplified model, automated code generation, and abstracted business rules, loading new data into a Data Vault 2.0 is significantly less labour intensive. Pepper utilised the Analytix DS Code Automation Templates (CATs) to automate and standardise the ETL implementation process. The resulting ETL code automation system dramatically reduced ETL deployment times, enabling Pepper to quickly and easily generate quality code. measured in minutes – not days, weeks and months! The ETL automation significantly simplified and accelerated the delivery cycle. The system is further supported by the IBM InfoSphere Information Governance Catalogue. This defines all the key terms, providing context and accuracy.

“The good thing about the glossary is that business people can use different names for the same concept,” explains Mellare. “For us, there are two main use cases. Firstly, business users can search terms to find Cognos reports and their owners (stewards) that relate to that search term, providing a strong level of self service. Secondly we are also using the glossary to highlight any reported data quality issues.”

The IBM InfoSphere Information Governance Catalogue (or Glossary) allows consistency of language and interpretation by the business. Not only does this enhance accuracy, it simplifies the process, allowing it to be pushed closer to the areas of business that need the data. Lineage enhances this functionality further, allowing an operator to see exactly where the data has come from, and to quickly understand the ramifications to changes in the datasets, reducing the need for remediating downstream impacts and regression.

“We want to drive agility. Ultimately, where we want to be, is in a situation where a data warehouse resource can sit with a business consumer, revise or create a data mapping, collect the rules and push the changes through into the data factory. Our aim is for the implementation to be as quick as the change management process governing the change implementation cycles,” remarked Mellare.

“Ignition played a strong role in helping to manage the risk associated with a new software vendor (Analytix DS) whilst providing DV2.0 expertise and coaching” clarified Mellare.