Skip to content
ale@portfolio:~/portfolio$ cat README.md

portfolio

Every case study here answers one question: measurable outcome.

taxonomy.mdZapier · 2022

Namespace & Events Taxonomy: Design and Enforcement

ShippedTeam: Data + Eng + DWE6 months
TL;DR

A four-level hierarchical taxonomy for events and namespaces, enforced automatically via CI/CD, replacing an ungoverned, one-Kafka-topic-per-event free-for-all.

Outcome

  • ↓requests to manually add new namespaces
  • 6modesign to full CI/CD enforcement
Saw It
  • Product teams created events with no naming guidance: one Kafka topic per event, sometimes shared across unrelated use cases, making cluster resources and consumers nearly impossible to monitor.
  • Left unaddressed, this was an operational scaling risk, not just a tidiness problem.
↓
Figured It Out
  • Hosted several rounds of discussion and validation with product and data teams to agree on a consistent, business-needs-based naming structure.
  • Deliberately designed the structure to survive org changes rather than needing rework every reorg.
↓
Did It
  • Designed a four-level hierarchical namespace taxonomy plus an object-action naming convention for events.
  • Enforced both automatically through CI/CD validation, removing reliance on manual review or tribal knowledge.

My Role

Owned the taxonomy design decision to ground it in business needs rather than team names specifically so it would survive reorgs, and made the call to enforce via CI/CD rather than documentation alone: documentation doesn't scale, automated enforcement does.

Engineering Collaboration

Worked closely with Data Warehouse Engineering to fold modeling logic and needs directly into the naming convention, and with the CI/CD owners to implement automated validation,including internal mapping tables to handle exceptions without breaking production topics mid-migration.

Full breakdown

Problem & Risk

Business Viability RiskFeasibility Risk

Product teams created events with no naming guidance: one Kafka topic per event, sometimes shared across unrelated use cases, making cluster resources and consumers nearly impossible to monitor. Left unaddressed, this was an operational scaling risk, not just a tidiness problem.

Customer Discovery & Validation

Evidence

Hosted several rounds of discussion and validation directly with product and data teams to agree on a consistent, business-needs-based (not team-based) naming structure, deliberately designed to survive org changes rather than needing rework every reorg.

Context

This was the first time the company had rules for event creation at all. Multiple teams had already diverged into inconsistent, ad hoc conventions, so the taxonomy had to be retrofit-compatible, not just a greenfield standard.

Timeline

git log --oneline⏱ 6 months to v1, plus v2 for exceptions
discovery: rounds of validation with product + data teamsMonth 1–2
ship v1: four-level taxonomy + CI/CD enforcement liveMonth 6
ship v2: internal mapping tables added for edge-case exceptionsPost-launch

What We Did

Designed a four-level hierarchical namespace taxonomy plus an object-action naming convention for events, then enforced both automatically through CI/CD validation, removing reliance on manual review or tribal knowledge.

~ rough sketch, not an actual screenshot ~

subject area

level 1

category

level 2

subcategory

level 3

object_action

level 4, event name

Who Benefits

Product teams identify the area of impact of their events faster and onboard to naming conventions with less friction. Data governance enforcement became automated instead of relying on manual review, a durable, low-maintenance win. This taxonomy later became the foundation the Events Salad Bar tool was built on top of.

Next Steps

Leadership prioritizes making the taxonomy tooling itself more user-friendly: the Events Salad Bar (see that case study) was the direct next step here.