Defining the financial industry

As discussed in a previous post – What do you mean? – having a common set of key business terms and definitions is so beneficial to an enterprise and is at the core of good data management.

So it is good to see people in the financial industry discussing the importance of having a common language both within an individual organisation and across a sector. Andy Haldane – Bank of England’s executive director for financial stability – told the Securities Industry and Financial Market Association in New York yesterday that there is often no common way of calculating risks and liabilities. A few quotes from the article:

“the world’s banks should develop a common language, like the barcodes used in international trade, so that financial risks can be mapped and understood”

“Most financial firms have competing in-house languages, with information systems siloed by business line. Across firms, it is even less likely that information systems have a common mother tongue,”

“Without a common language, Haldane said, trying to map the complex networks between different financial firms and their clients and customers is a ‘high-dimension puzzle’, which hampered the clean-up after the collapse of Lehman Brothers.”

So not having a common set of definitions has hampered the clean-up and makes it more difficult to calculate risks/liabilities. Therefore, can it also be argued that not having this might be one of the root causes of the current financial crisis – or at least made it more difficult to identify/prevent?

One of the excuses often put forward for not having appropriate data management processes is centred around cost. But, following on from this speech, perhaps organisations need to start asking – “can we afford not to do this”.

Definitions in information management – book review

Most people involved in the data management space would agree on the importance of having explicit and unambiguous definitions for key enterprise data assets – see previous blog – What do you mean?.

Sadly, this area is often overlooked and is one of the key contributors to data quality issues in many organisations.

Perhaps a reason for this, is that there is very little practical guidance on creating and managing definitions. The book – ‘Definitions in information management’* – by Malcolm Chisholm addresses this.

I first ‘scan read’ this book on my commute to work just under a year ago. I have recently been working on an enterprise conceptual model – creating/reviewing definitions – and have taken this opportunity to take a more detailed look at this book.

It follows the high standards set by Malcolm Chisholm in his previous books such as ‘Managing Reference Data in Enterprise Databases’ *

It contains 235 pages and is split into 17 chapters.

Key chapters include:

• Justifying definition management.
• Theory and history of definitions.
• Definition types.
• Producing high quality definitions.
• Governance and management of definitions.

The last two chapters have proved particularly invaluable with my current work, as they provide a wealth of practical tips on creating and maintaining definitions.

All in all, a good book and one that I would recommend to anyone working in the data management space.

I will leave you with a quote from the book that particularly resonated with me – written by Ron Ross.

“Pay a little now, or pay a whole lot over time….Time and time again we find really big problems boiling down simply to what things really mean.”

* See Books and references for links to these books.

What do you mean?

‘The Power of a Common Business Language’ outlines the important of having a common set of key business terms and definitions within an enterprise.

It’s author asserts – the major challenges when deploying information systems are not technical – but are in having a “common business language”.

I am sure many of you can think of many examples within your own organisations where issues are caused by not having one.

Often the same term is used to mean different thing or differing terms are used for the same thing – leading to:

• confusion
• data quality issues
• increased costs
• the potential loss of opportunities to increase revenue

What is the best approach to take?
Most would agree that having a common business language will provide benefit – but there are a number of different approaches that can be taken.

I have recently been involved in setting up a centralised data dictionary/metadata repository – to start to record all key business terms/definitions.

The approach has been to build this up iteratively – collecting and reviewing as and when necessary, usually through project work.

I would be very interested to hear from anyone who has been involved in tackling this issue within an enterprise – the approach you took – what worked – what didn’t?

Technical debt – what about data quality debt?

In this article Martin Fowler discusses technical debt.

He says: “In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.”

He also explains the use of the ‘Technical debt quadrant’. 

Is the debt Inadvertant or deliberate? 

Is it a reckless or prudent debt? Can you afford to pay the debt back in the long run? 

Is it worth having a similar metaphor – ‘data quality debt’? 

It might be useful when discussing data quality and data management issues within project teams and with the wider business. 

So what constitutes data quality debt? 

Often the sort of decisions taken in projects that lead to: 

• the quality of data degrading overtime.
• having to continually support the system to mitigate against data issues.
• having to carry out expensive data cleansing exercises.

Some examples of data quality debt: 

• Not identitying who in the business is responsible for the data.
  • If no one  is responsible  for keeping it up to date it will degrade overtime.
• Not having clear definitions of the data and it’s purpose.
  • If you don’t - semantic integration with other systems will be an issue and the data is likely to be misused.
• Setting a column in table to null - even though business requirements say it should be compulsory.
  • Some rows in the initial data import didn’t have this data – it was easier to set it to null rather than go back to the business.
• Not having any data quality profiling/metrics - to ensure data quality is maintained over time. 
  • ‘If you cant measure it you cant manage it’.

These are only few examples I am sure there are many more!