Enterprise data architecture at the Pru

John Ewan’s talk at IRM-UK outlines how data management is done in financial services.

The Prudential’s business (and hence its data model) is essentially unchanged since its agents began selling policies to clients 160 years ago. In 2003 the Prudential Data Architecture team was created to define a data architecture and a ‘canonical’ information model. Before ‘data silos’ were built for projects. The Pru’s enterprise data architecture (EDA) comprises an overarching ‘business concepts’ model that maps into a corporate data model. Next comes a logical data model, fully attributed with detailed definitions and finally the physical layer. The Pru has only one logical model, implemented and optimized in different ways.

Conceptual modeling is performed with stakeholders using whiteboards and PostIt notes rather than Case tools. Ewan likes to play the ‘dumb’ architect and involve people further up the food chain. It is important not to explain data modeling—rather to get users to write down entity names themselves. Ewan prefers Richard Barker’s ERD over ErWin for capturing the business.

The Pru has been using master data since before the term was coined. Master data is at the core of the architecture and can be accessed direct from a data store of reference or copied if needed for analytics. There can be tension with users who may prefer data in SalesForce.com over the master data repository. Tying third part applications in to the data infrastructure can be hard.

Left to their own devices, ‘stove pipe’ business areas lead to conflicting requirements and quality levels. Data ownership concepts blur over time. Prudential has well attended data governance forums around its key businesses. Business users bring issues to the table.

The Pru is now working on data quality profiling. Even without the funding to fix all issues, it can be useful to report declining quality to key stakeholders on a monthly basis. The company is also developing a ‘canonical’ information model for a services-oriented architecture. While SOA mandates a common agreement on semantics, it is ‘virtually impossible’ to have the same canonical model for all requirements. The idea is to create ‘semantically consistent’ multi-tiered models that can generate XSD and then build compound business types from the core definitions. All of the Pru’s work is platform independent with development in Java. Ewan likes to focus on solving business problems with senior stakeholder involvement—adding value, sometimes even without a data model.

Click here to comment on this article

Click here to view this article in context on a desktop

© Oil IT Journal - all rights reserved.