The Book Look: The Rosedata Stone

I know there is a bit of a bias when I dedicate this quarterly column to my own book … but, oh well.

My latest book, The Rosedata Stone, has very recently been released.

Similar to how the Rosetta Stone provided a communication tool across multiple languages, The Rosedata Stone provides project managers, data governance professionals, and business analysts with a set of business terms to allow consistent communication across all business languages. The Rosedata Stone, called the “business terms model”, formally documents a common business language for a particular business initiative.

I’ve been data modeling for over 30 years, and the data model, a tool for precisely capturing information on the business, frequently is limited to database design. During my last few consulting gigs however, I was hired not to design a database, but instead to create a business terms model capturing a common set of terms such as “customer”, “employee”, and “account”. Once organizations have a clear understanding of what terms mean, they can build more useable applications, and better address government regulations such as GDPR, the MiFID, and the California Consumer Privacy Act.

The book contains five chapters. Chapter 1, Challenges, explains that with intense competition, strict regulations, and rapid-spread social media, the financial, liability, and credibility stakes have never been higher.  Therefore, it is imperative to have a common business language more than ever. Chapter 2, Needs, demonstrates how precise minimal visuals are the most effective communication tool. Chapter 3, Solution, introduces the business terms model and shows how CaseTalk, ER/Studio, erwin DM, and Hackolade represent the model. Chapter 4, Construction, shows how to build operational (relational) and analytics (dimensional) models, and Chapter 5, Practice, assists you in building one for your initiative.

Here is an excerpt from Chapter 1 (I used a bakery example throughout the book, as I was hungry while working on this first chapter.):

Imagine you are the Chief Information Officer for the bakery chain Chips Inc. Not only do you receive a salary and health benefits, but you also can eat as many pastries as you like for free from any of the 30 bakeries that Chips Inc. owns and operates. Now that is a great job perk!
Due to the independent culture of Chips Inc.―combined with how Chips Inc. grew by buying a bakery at a time―each bakery has its own way of operating. Each bakery uses its own systems such as Quicken, Excel, and sometimes even pencil and paper, to assist with ordering supplies, baking pastries, managing sales, and handling payroll.
With costs for raw materials such as sugar on the rise, and increased competition from other bakeries and high-end supermarkets, Chips Inc.’s executives are looking for ways to save money and therefore increase profits. One way is the potential savings in centralizing pastry purchasing followed by a centralized payroll. Centralizing business processes such as purchasing should not only save money, but also allow for more consistent reporting across the organization, identifying additional ways to save money and uncovering new business opportunities.
In addition, Chips Inc. would like to franchise their brand, recipes, and processes to other bakeries. Prior to approaching bakeries on franchising opportunities, Chips Inc. needs to follow more consistent practices across their 30 stores. Once consistent practices are in place, they can be applied to the franchisee bakeries.
The executive team is convinced―mostly due to a one-hour sales pitch presentation from a large software consulting organization―that centralizing business processes will take minimal effort. The presenter touted his software solution as a seamless way to integrate all Chips Inc. processes. “It’s as easy as baking a cookie,” this software consultant said as the executives nodded their heads in hypnotic agreement. You, however, are not as optimistic. And it’s not just because you find baking a challenge. You wonder how a software solution can magically solve a very complex business problem.
After lunch you stroll down the road to Chips Inc.’s flagship bakery to treat yourself to a free chocolate chip cookie. After showing the store employee your Chips Inc. badge and receiving your free cookie, you browse the tantalizing cakes, cupcakes, and cookies.
As an attempt to convince yourself of the similarity across bakeries, you decide to take a bus ride to another Chips Inc. bakery on the other side of town within an upscale neighborhood. Since this bakery caters to a higher-end clientele, what was called a cookie at the last bakery is called a biscuit in this bakery. This bakery has an extensive pie selection yet no cakes. They also sell parfaits, smoothies, and artisan breads which the first bakery did not carry.
As you munch on a free chocolate chip biscuit (which tastes strikingly similar to a chocolate chip cookie), questions start brewing:
    • How do cookies and biscuits differ?
    • How do pies and cakes differ?
    • Are artisan breads, smoothies, and parfaits within the scope of the pastry purchasing initiative?
Successfully purchasing ingredients for our bakeries requires a common set of terms. Asking the first bakery how much sugar they order for biscuits and the second bakery how much sugar they order for cookies would most likely cause confusion as the first bakery calls them cookies and the second biscuits. In addition, a third bakery sells dog biscuits which have different ingredients and therefore different purchasing requirements than the biscuits from the second bakery.
Note that it is ok for the first bakery to keep calling them cookies and for the second bakery to keep calling them biscuits, if they are recognized by the corporate purchaser to be the same thing. This will require a common term that disambiguates all of the variations. Similar to the Rosetta Stone translating between ancient scripts, the Rosedata Stone translates between terms from different departments or locations. For example, Bakery A calls it cookie, Bakery B calls it biscuit, other bakeries have their own terms, and the corporate purchaser calls it cookie. The corporate purchaser would be the common term across the bakeries.

I’ve written nine books on data modeling. The Rosedata Stone is the shortest book I have written and yet it took me the longest time to write! “Keep it concise and practical,” I kept telling myself—the reader needs to be able to read the book in an afternoon and yet obtain the skills for creating effective models.

Share this post

Steve Hoberman

Steve Hoberman

Steve Hoberman has trained more than 10,000 people in data modeling since 1992. Steve is known for his entertaining and interactive teaching style (watch out for flying candy!), and organizations around the globe have brought Steve in to teach his Data Modeling Master Class, which is recognized as the most comprehensive data modeling course in the industry. Steve is the author of nine books on data modeling, including the bestseller Data Modeling Made Simple. Steve is also the author of the bestseller, Blockchainopoly. One of Steve’s frequent data modeling consulting assignments is to review data models using his Data Model Scorecard® technique. He is the founder of the Design Challenges group, Conference Chair of the Data Modeling Zone conferences, director of Technics Publications, and recipient of the Data Administration Management Association (DAMA) International Professional Achievement Award. He can be reached at

scroll to top