Database debunkings – up and running again


It’s great to see this up and running again after a number of years being ‘on hold’.

The purpose of Database Debunkings is to:

“To correct misconceptions about and educate on the practical implications of data fundamentals–concepts, principles and methods–that receive little, incorrect, or no coverage. And to make foundation knowledge accessible to the thinking database professional and user, regardless of the DBMS used”

Definitely worth a regular visit.

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”.

What is a conceptual, logical and physical model?


David Hay has written an excellent short presentation that describes the differences between these and places them within the context of the Zachman Framework.

He makes a greate point – how can we expect others to think about language/definitions when those in the data management community often use these terms in such an inconsistent fashion.

The presentation can be seen in the following – Introduction to Data Modeling

David mentioned this presentation in the following – LinkedIn discussion

Open data model


The Open Data Model site was launched recently.

It’s aim is to:

“bring together data modelers and subject matter experts both from IT and business. The purpose is to reach consensus on the best way to represent any given set of facts, by ensuring those facts are truly understood.”

Effectively to build up a set of conceptual models for different domains which can then be used as starting points in modelling efforts.

(As far as I am aware) It has only been running for a few weeks and has already built up some really useful resources.

Definitely worth taking a look at.

Note you have to register to access most parts of the site.

Data modelling standards


How to Draw an Architectural Data Model in UML – was published recently by David Hay. It lists a set of guidelines to follow when using UML notation for data modelling.

For those using ER/Barker notation, he also published a set of guidelines a number of years ago – see Data Model Quality: Where Good Data Begins.

Both are useful resources and worth taking look at. Especially if you are thinking about creating modelling standards within your organisation.

Enterprise architecture model resource


I’ve come across a really useful resource created by Louise McDonagh.

An Enterprise architecture model consisting of ‘generic data, function and application architecture model framework’.

The ‘data model’ is in effect a set of conceptual model patterns – based around the following subject areas:

  • Activities and events
  • Actor/parties
  • Agreements
  • Assets
  • Business rules
  • Locations
  • Financial accounts
  • Product and services

A set of definitions is also provided – could be useful for initial ‘straw man’ definitions with stakeholders.

Definitely worth taking a look at – especially for anyone about to undertake or currently undergoing a business capability or business information modelling exercise.

Enterprise Data Modeling 7 Mistakes You Can’t Afford to Make


An interesting article by Karen Lopez – Enterprise Data Modeling 7 Mistakes You Can’t Afford to Make. Definitely worth taking a look at.

The first one ‘Forgetting that an enterprise architecture is a living framework’ – not viewing ‘data architecture as a final, fixed deliverable’ particular resonates with me at the moment.

A mistake I would add to the list is along the lines of ‘Getting too bogged down in detail’.

There is definitely a sweet spot in getting just enough level of detail to make the enterprise model useful to it’s intended audience (or should that be audiences?) whilst not swamping it and making it a ‘boil the ocean’ type process to create and maintain.

There must be a couple more to make it to 10?