After being distracted by preparing a certain conference for quite some time, I finally found the time to have a look at Steve Hoberman’s latest book, The Rosedata Stone: Achieving a Common Business Language using the Business Terms Model. 

It’s hard to not know Steve when you’re working in our field but in case you’ve never heard of him, Steve Hoberman has written a significant number of data modeling books over the years, trained literally thousands of people in data modeling and been the mastermind behind the Data Modeling Zone series of conferences. Yours truly spoke at Data Modeling Zone Europe in Stuttgart last year (slides here) and is scheduled to appear at Data Modeling Zone in Antwerp next year as well.

Now, what is a Rosedata stone, exactly? 

Rosedata Stone book cover

If Rosedata Stone sounds a lot like Rosetta Stone to spare-time egyptologists like you and me, this is not an accident. The Rosetta Stone, created on behalf of the Hellenistic king Ptolemy V at the beginning of the 2nd century BC and rediscovered during Napoleon’s 1798 Egyptian expedition, contained the same text in three different versions – Ancient Egyptian written in the impressive-looking but somewhat cumbersome hieroglyphs, Ancient Egyptian written in the more practical Demotic script and Ancient Greek – and was instrumental in finally deciphering those hieroglyphs.

In many organizations, the terminology used by different departments varies so wildly that something like the Rosetta Stone would come in handy. According to Steve Hoberman, a well-made conceptual model can be exactly the Rosedata Stone that helps the people in an organization to finally understand what the other person is talking about. This definitely makes sense to me, Lars Rönnbäck and I explored similar ideas in our article on Closing the Business-IT Gap with a Model-Driven Architecture earlier this year.

In his new book, Steve explains why and how to build such a conceptual data model in a way that is fluent to read and also accessible to people without too much data modeling experience. The structure of the book is straightforward:

• In chapter 1, Steve describes the challenges that many organizations face when trying to work with data.
• In chapter 2, he outlines the requirements for overcoming these challenges.
• In chapter 3, he explains what a conceptual model is and which tools can help you to create one.
• In chapter 4, he guides you through the steps of building one using a bakery chain example.
• In chapter 5, he helps you internalize the process with a Data Modeling Zone example.

Throughout the book, it’s palpable that Steve has a lot of experience with teaching data modeling. The more practical chapters 4 and 5 are especially strong and I’m definitely considering to incorporate Steve’s six strategic questions into my work routine. I can recommend the book both as a short introduction for newbies to the field and to more seasoned practitioners that are open to review and adapt their own approach (we are a stubborn lot, us data modelers).

There’s just one thing that left me thinking: If we’re trying to achieve a common business language (and I think we all are in our different ways), why introduce a new name (Business Terms Model or BTM for short) for something many people already know as a conceptual model? I’m looking forward to meeting Steve again at Data Modeling Zone to discuss about this.