Last week was a busy week for me, so I didn’t have any time to read articles for the BLOG. But I see more and more BLOGS are doing the same thing, creating a weekly list of interesting information. DID I START A TREND or WAS I ONE OF THE EARLY ADAPTORS TO THIS WEEKLY AGGREGATION on BLOGS….

This week I had a little more time to read articles, so here’s a list of articles I have read;

From the site Loosely Coupled Human Code Factory

• BI’s Promised Land (by Erik Thomson)
• IT Agility and Business Stove pipes (by Dan Linstedt)
• The new evolution of Data Modeling (by Dan Linstedt)
• New skills required for BI and Data Presentation going forward (by Dan Linstedt)
• Besparing door SOA van minder belang (on Computable) !!! DUTCH !!!

IT Agility and Business Stove pipes

Dan Linstedt talks about the lack of agility, spreadmarts and 2nd generation data warehouses. The 1st data warehouse solutions all seem to have a STOVE-PIPED APPROACH, according to him, because of wrong data modelling.

I must admit I agree that a lot companies don’t see the opportunities of the Data Vault (or DV-like data model). The goal, in my opinion, of companies should not be to create a Single Point of The Truth, because there’s no SINGLE thruth. When talking to managers, they all have different definitions of the same object, e.g. Customer, but they all have different needs for this object. The marketing department has a certain need for information when talking about customers, whilst the financial department might not even be interested in individual customers.

I agree with Dan on the fact we need ONE VERSION of THE FACT. We don’t want to change the truth that lies in the facts from the operational systems. Using this architectural principle, the streams of data towards the data warehouse look different from the ones needed for the SINGLE POINT of THE TRUTH. The IT department in the example by Dan Linstedt, is constantly working towards a conformed dimension set, but in fact creating a non-conformed dimension set. This is a little short sighted, because it’s only true if the IT department doesn’t look back to the former needs and has no communication about the enhancements to the information model. But he has a point there, we need fast and lean reactions to the changing information needs from the business, without losing the history and context.

If we don’t have speed and agility in the IT department, the business will start creating spreadmarts and use their own Microsoft Access database to fullfill their information needs. We just created a stove-pipe solution for the Business Information, something they will not like at the IT department. But how to solve this problem that seems to be happening in a lot of companies?

• We need to be prepared to fast changing information needs from the business, and be able to quickly implement any changes without losing history and context. (FLEXIBILITY)
• We need to think BIG and start small. This is a statement much heard in our business, but is it done enough and is the solution provided / suggested ready for this approach? (SCALABILITY)
• To support the first two, we need a solid basis, consisting of architecture and data model.

As a Data Vault Expert (See LinkedIn and Genesee Academy) I admit the concept is very useful, but … there are more dogs called fikkie (Dutch: Er zijn meer hondjes die fikkie heten). Dan mentioned the Anchor Modelling methodology and I have been looking at IBM’s Banking Data Warehousing Model which has some aspects that look like the Data Vault approach (identifier entities / dataconcept entities).

In the next few days / weeks / months I hope to enfold more information about my further opinions about data modelling and architecture.

The new evolution of Data Modeling

In this article Dan Linstedt and Bill Inmon state that they have found a revolutionairy approach to real-time (or better right-time) data warehouse and getting the data fast out-of the transactional systems within a company. They introduce the “Operational Data Warehousing” in this article, a “Operational Data Store (ODS) with history” or “a Data Warehouse with operational (raw) data”.

Bill and Dan have taken the Operational specifics – systems capturing data – and placed it on top of the Data Warehouse as a Single Integrated Historical and Operational Data Store. Some people might call this “Active Data Warehousing” (ADW), but Dan and Bill conclude, their ODW is one step beyond ADW.  They talk about the convergence between Operational Systems and Data Warehousing, the ODW is at the same time ODS AND Data Warehouse.

Especially their ‘conclusion’ / answer to the statement “So you mean to say there ‘is no operation system’?” attracted my attention. What they are stating (if I understand correctly) is that there will only be interfaces collecting operational information and, after this infomation arrives in the ODW, information is not stored within these interfaces. It seems the ODW is becoming the operational system of the future (or I understand it incorrectly again).

It intriges me what they are thinking of, convergence with the operational world by taking over the biggest part of this component within the enterprise architecture. I wonder how all reference architecture pictures will look like after this convergence has taken place?!? I like the idea of a closed loop, because that will arise when using this architecture. Let’s only hope this will be a positive circulus viciosus… 

Bookmark to: