Wall Street & Technology is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Data Management

07:00 AM
Jonas Olsson
Jonas Olsson
Commentary
50%
50%

Single Source, Many Truths

If the data quality is not at fault, why then might departments reject the data? The answer is that there are two aspects to data quality: factual correctness and contextual correctness.

To stay competitive, financial services organizations must develop three core competences: identifying new business opportunities, understanding exposure, and streamlining compliance processes to minimize cost and risk.

As such, financial services organizations must equip their sales, risk, and compliance teams with the deep, timely insight they need to operate effectively. Because each department has its own context-specific definition of core concepts -- such as market value, customer, security, product, and price -- departments often meet their operational requirements using complex spreadsheets.

However, because spreadsheets create the significant risk of human error, many organizations decide instead to build centralized data repositories.

Data quality vs. data context
Building data repositories can be very difficult, and to reduce the complexity of the design process, a business often enforces a single set of static definitions for its data, despite the fact that each department depends on particular data definitions for operational reporting. However, without a way to tolerate contextual variations in financial definitions, businesses risk investing time and capital in an inflexible data warehouse that will most likely fail to meet its users’ operational needs.

This failure often manifests itself in complaints from users in different departments about the perceived quality of the data. In fact, the quality of data -- that is, the factual correctness of information on transactions, securities, accounts, and client names -- is often perfect.

If the data quality is not at fault, why then might departments reject the data? The answer is that there are two aspects to data quality: factual correctness and contextual correctness. For example, a rigid data warehouse that was only designed to support the bid price for a given source, security, and date will store factually correct bid prices day after day, despite the fact that many departments may require the close price for their operational requirements.

Although the bid price and the close price may occasionally be identical by pure chance, on most days the prices will differ. Faced with prices that are contextually correct on some days and incorrect on others, departments logically assume that there is a problem with data quality. In fact, the real issue is more likely that the data repository is unable to deliver reports in the specific context that each department requires.

To meet their business goals, organizations must therefore stop forcing static data definitions and instead deploy a solution that enables the underlying raw data to support multiple contexts.

Narrow scope, limited insight
One way to reduce the risk of end-users rejecting a data warehouse altogether is to narrow the scope of the project. Rather than building a single, strategic data warehouse solution, organizations can extract subsets of their raw data from source systems into a number of departmental datamarts, each of which is designed to address a very limited number of specific departmental use cases.

Datamarts enable businesses to bypass the challenge of supporting each department’s competing requirements for data definitions in a single system, but this benefit comes at a price. Although the time, effort, and resources required to create a single datamart are significantly less than building a data warehouse, datamarts scale poorly.

For example, whenever any department has a new reporting requirement, the IT team will face the time-consuming task of locating the relevant raw data from multiple source systems, then extracting and integrating it into the datamart. When changes are required -- and they certainly will be -- this time- and cost-intensive process must be repeated. Multiplied over many departments and numerous reports, the datamart approach rapidly becomes costly, complex, and time-consuming.

Moreover, datamarts only meet department-specific reporting requirements, at the expense of the bigger picture. They are effectively silos of analytics data, which makes reconciling datamart reports from all departments virtually impossible. With the regulatory landscape shifting towards deeper reporting in more frequent cycles, financial services organizations that rely on datamarts may find they lack the enterprise-wide overview required to meet their compliance requirements -- a serious threat to their ability to compete effectively.

Choosing a strategic solution
To offer their sales, risk, and compliance departments the reports they need without generating unacceptable costs and complexity, businesses need to move away from the spreadsheets and datamarts by establishing a central repository of all relevant financial data, one that addresses the need for context.

The answer is to create a flexible data warehouse that can deliver a comprehensive range of context-specific operational reports without incurring the cost of continually re-extracting and re-integrating the raw source data whenever new reporting requirements arise.

This kind of data warehouse would reveal the full lineage of each definition, tracking it back to the underlying raw data in each report in order to help dispel perceptions of poor data quality and to encourage end-user acceptance. Furthermore, it would make it possible to instantly roll up reports from each department into a company-wide overview, without the need to enforce single definitions for context-specific concepts.

By supporting multiple data sources and definitions, a properly designed -- and more flexible -- data warehouse would erase the common misconception of poor data quality, as each department will see its own specific definition of the same underlying source data.

Beyond the context/quality benefit, a single data warehouse for all data scales far more cost-effectively than datamart solutions. And although the complexity of uniting multiple source systems, stakeholders, and use cases into a single data warehouse may be a daunting prospect for most organizations, the ready availability of packaged data warehouse solutions makes it unnecessary to develop a whole solution from the ground up. 

Jonas Olsson is the CEO and founder of Graz , a provider of data warehouse and business intelligence software built specifically for the needs of investment managers, insurers and banks worldwide.  Olsson founded Graz in 2000 as an IT services firm, and transitioned it ... View Full Bio
More Commentary
A Wild Ride Comes to an End
Covering the financial services technology space for the past 15 years has been a thrilling ride with many ups as downs.
The End of an Era: Farewell to an Icon
After more than two decades of writing for Wall Street & Technology, I am leaving the media brand. It's time to reflect on our mutual history and the road ahead.
Beyond Bitcoin: Why Counterparty Has Won Support From Overstock's Chairman
The combined excitement over the currency and the Blockchain has kept the market capitalization above $4 billion for more than a year. This has attracted both imitators and innovators.
Asset Managers Set Sights on Defragmenting Back-Office Data
Defragmenting back-office data and technology will be a top focus for asset managers in 2015.
4 Mobile Security Predictions for 2015
As we look ahead, mobility is the perfect breeding ground for attacks in 2015.
Register for Wall Street & Technology Newsletters
Video
5 Things to Look For Before Accepting Terms & Conditions
5 Things to Look For Before Accepting Terms & Conditions
Is your corporate data at risk? Before uploading sensitive information to cloud services be sure to review these terms.