#11 Implementing business glossary? Define a structure & treat it like a product!


A few weeks ago, I shared with you that we will be doing a two-part series on decoding what goes into successfully implementing a glossary in your organization. In Part 1, we covered how to use a glossary as a shared language in the organization and the types of glossary you can set up. As promised, this week we will be covering glossary best practices that can serve as guiding principles as you implement a business glossary.

Since every organization's glossary is designed to reflect its unique style, it's natural that your glossaries would look different. But following certain best practices in the implementation process can provide you with guiding principles that ensure you set up a robust glossary.

1. Structure first, execution second

Once you are clear on the type of glossary, you want to begin with, your next step should be to identify individual/s who can take ownership of each part of the glossary. For example, if you are defining a Metrics glossary that includes metrics from 5 different teams, ensure that you have at least one person from each team to take ownership. With these individuals, draft a broad structure where you can brainstorm on estimated terms for each team and assess their fit for MVP.

Example: Planning glossary implementation
Example: Planning glossary implementation

2. Treat glossary as a product

What that means is that every term in the glossary should be designed keeping end-user value in mind. The desired glossary should be:

  • Reusable and accessible — Every end-user, whether an analyst, business stakeholder, or data engineer, should be able to understand what a term means. They should be able to refer to this context in their day-to-day work.
  • Well-documented — The term should be as comprehensive as possible. For example, you can decide that in order for the end-user in the organization to get the maximum value, it should have, 1)Business definition in the description, 2)Any gotchas captured in Readme, 3)Calculations (if, any) are linked as saved queries
  • Scalable — Glossary should be designed keeping the organization's need in mind, and not just for 1-2 users. That's why it becomes essential that you spend some time upfront deciding on a structure that will scale as your data maturity grows over the years
Example: Glossary terms as a product
Example: Glossary terms as a product

3. Choosing an implementation approach

When it comes to implementing a glossary structure, you need to find an approach that works for your organizational dynamics. Below, we share three broad implementation approaches we have typically observed.

  • Data Definition Expert — In this approach, you implement a glossary by having a dedicated data definition expert. Especially, when you have smaller data teams where 1-2 people have all the context and they can take ownership.
  • Team of SMEs — In teams that are medium-large, and context is spread across multiple people, you assign terms by category owners/data sources. If you plan to use this approach, ensure that all the contributors have a clear idea of ownership across terms.
  • Crowdsourcing — And finally, when the context is so far spread out in the team that it's hard to identify owners, you can use dedicated documentation hours or gamification drives to crowdsource terms.

A detailed article is also up on community - Link!

Are you facing challenges in deciding what's the right business glossary structure for you? Just shoot me an email and I'll be happy to help over an office hours session.

Speak soon,


P.S. The purpose of these emails is to share learnings and best practices to empower our community of DataOps Leaders. All the previous editions of these weekly digests can be found on our community website. Though we have put a lot of thought into curating the most relevant content, if you do not wish to have access to this, you can choose to opt-out by emailing me here: opt-out 🙂