Nick Jones, Senior Consultant, Citisoft PLC.
This section looks ahead to see if there are lessons from the age of digital cartography to provide insights into how data management and navigation might develop in the next few years.
The Digital Divide
Financial services organisations and their suppliers are still struggling to produce the data equivalent of a paper map, the Ordnance Survey (OS) is now a digitally based organisation. It does produce printed maps but digitized mapping underlies a wide range of geospatial-aware applications. But the features of the physical landscape and their spatial relationships had to be described and carefully documented before there was value in providing them digitally.
Towards the ‘Dat Nav’ Future
We now take location-aware applications for granted. Layers can be added over the basic landscape: route calculation, satellite imagery, traffic flows, local amenities … the list is almost endless. With data the same should be true. Imagine you could navigate your data as if you were planning a car journey: using a ‘Dat Nav’ you could state your start point and destination, and set off, confident of finding and retrieving what you were looking for. It might also let you drill down to details, or detour to check unusual values, or warn of data traffic congestion, or any host of other data related services. So what are the steps needed to make it a reality?
Crossing the Divide
The first is to build a solid foundation of the standard data features and relationships in the data landscape. Creating this for financial services need not be an immensely complex task. (There are already common business item definitions in FpML, ISO 20022, and FIXML that can be built on.) We are constructing a map, not a detailed scale model. It needs to cover what each place (data type) is and the business relationships between data types. A data dictionary for the name and description is too often where the data cartography ends. The logical business model relationships put data in a context where users can understand it quickly.
The business model and the dictionary define the industry data landscape, but at least two more things are needed before the map can be used effectively. We need to know where the data is located, like having its longitude and latitude, and to know which routes exist to navigate through it. These link the abstract data map with data storage and retrieval realities in an organisation.
The Dat Nav Roadmap
In the financial services industry we all inhabit the same data landscape. Asset purchase and sale deals are done between parties, and involve financial instruments of some form. Deal results are calculated and recorded in positions. Position and transaction data sets are grouped to reflect ownership, or investment management responsibility, or risk aggregation, or performance, or any variety of other classifications.
There is no government-sponsored monopoly (like the OS) to do our data surveying work; but government compulsion and regulation is a key driver and director. LEI and FATCA both require specific sets of entity data. Solvency II and others require well-defined sets of other data. These items are represented variously in internal systems, but regulation defines a de-facto set of meanings associated with them.
Starting with these fixed data sets required by regulation, a logical business model can be built to address multiple regulatory requirements and produce a core logical business model – minimising overall effort, and extensible as it proves its value. This approach follows existing ETL and ESB concepts and best practice.
The Data Destination
But the potential is greater. Data developments become less costly and more reliable as this consistent state is approached. And there are further advantages if a common logical business model is widely adopted.
Now, when moving and navigating data we carry it so far, reach the end of our map, then hand it over for unpacking, re-packing, and re-loading by another operator who can take it to the edge of their own map – where the whole process may be repeated! An ESB can eliminate large portions of the packing, unpacking, and re-loading, but a common business view of data would permit standard data interchanges between and within organisations. A Dat Nav would be able to point out the most appropriate bus route.
Building a Dat Nav
The un-mapped ‘current state’ approach to data management is inefficient, costly, and unsustainable. It must be a prime candidate for attention in an industry where pressure on margins is fierce, because getting this right not only cuts costs and removes risks, it also opens the door to multiple added-value layers.
How close are you to the Dat Nav solution?
Subscribe to our newsletter
