Are you a Data Modeler or Data Worker?

A few months ago I was at a meeting with a customer who was involved with a BI project that was pulling data from an SAP system into a Data Mart.

One of the people at the meeting was very experienced in the ETL tool the customer was using for this project.

We were showing how our product Safyr® can be used to locate tables and relationships in an SAP system in support of the ETL/BI task that faced the project. Part of the demo was to show a set of user-selected tables visualized in an Entity-Relationship diagram. I’ve got most of the popular data modeling tools on my PC and I forget which one we used for this, but it was a graphical model of a set of SAP tables, showing ‘readable’ table and column names and the relationships between tables.

I also showed how the ‘technical’ names for tables and columns could be displayed – these names tend to be unintelligible for most people not versed in SAP architecture (e.g. Material Master is a table called MARA) but the BI expert became quite animated at this point: “that’s what I want!”, he said, “I’m not really interested in a data model, I just want to see the tables, columns and the joins between tables – that’s what I need for my ETL work”.

I was surprised that what I call a ‘logical model’ showing nice ‘English’ names for objects was of no interest to the BI expert. “It’s just a pretty picture”, he said dismissively. (By the way, I’m paraphrasing here and names and locations have been changed to protect the innocent). I was somewhat taken aback by this.

As a dyed-in-the-wool data modeler, I’ve always thought that seeing a ‘readable’ model of tables and relationships was a lynchpin of any project that used data. (So that means any project then). But here was a consumer of that same information, who could see value in the contents of the model, but was only interested in the model as a means to an end. The data model in this circumstance was like a sketch of a construction project. “This is what we need, now let’s get on and build it”. Once the work is done the sketch (or data model) is discarded, because it’s a working document, not a ‘deliverable’ in its own right.

Data Modeler or Data Worker?

So maybe we have two categories of ‘People that can benefit from Data Modeling’ – let’s call then ‘Data Modelers’ and ‘Data Workers’. Data Modelers typically work in Information Management roles and use the Data Modeling approach and Data Modeling tools to arrive at ‘artifacts’ that reflect key areas of the data across the Enterprise.

Finding the sources of valued data in your systems can be tough

Data Workers on the other hand, are normally ‘at the coal face’ hewing out chunks of data with a range of ETL, Data Integration, BI and other tools.

The success, or otherwise, of the Data Workers’ efforts depend on a good understanding of the data structures involved, particularly getting the joins between tables right. In my many years of involvement with the data modeling community, I’ve met a lot of people who can get very tied up in the pros and cons of different modeling methodologies and different modeling tools. Long discussions can take place over the meaning of Conceptual, Logical and Physical models.

What I’ve also seen in these times of squeezed budgets is that the business value of ‘Data Modeling’ in its purest sense can often be questioned and sometimes found wanting.

It’s just my opinion, but helping the Data Worker to get to grips with the data they need, in terms they are happy with, is a laudable aim for any Data Modeler, and offers a demonstrable raison d’etre for many data modeling groups that may be struggling to survive in a post-recession world.

Nick Porter
Technical Director