Adoption playbook
How teams use EventCatalog.
The question we hear most from architects is how other teams run it. This is the pattern we see work, from the first service to a catalog the whole organisation contributes to.
The pattern in six steps
01Decide what you want it for02Start with one service or domain03Deploy it and get feedback04Automate what can be automated05Give the catalog an owner06Let every team contributeStart small, then let it grow.
The catalogs that stick grow out of one useful area, not a big-bang documentation project.
- 01
Decide what you want it for
EventCatalog fits a lot of workflows, so start by naming the problem. Most teams pick one or two things that hurt today, like finding who owns a message or knowing what a change will break. That choice decides what you document first.
What should it do for you first?
Find what exists and who owns itCheck the impact of a changeOnboard new engineersGovern schemas and standardsGive AI agents contextPlan future architecture - 02
Start with one service or domain
Don’t try to document the whole organisation on day one. Pick one service, or the domain people ask about most, and document it properly: its owner, the messages it sends and receives, and its specs.
Learn by building a small catalogDomainPayments
ServicePayment ServiceOwned by Payments teamOpenAPI2 events1 commandRefund ServiceFraud ServiceLedger Service - 03
Deploy it and get feedback
Put it in front of a few teams early, even if it only covers one area. The questions they ask show you what is missing and what to document next.
Deploy your catalogOOrders teamWho owns PaymentTaken? We consume it.
PPlatform teamCan we see which Kafka topics Payments uses?
Your next three pages to write
- 04
Automate what can be automated
Once the shape is right, pull the facts in automatically. Generators read your OpenAPI and AsyncAPI specs and your schema registries across the organisation, so services, messages and schemas stay current without anyone maintaining them by hand.
See the integrationsOrders APIOpenAPISynced
Order eventsAsyncAPISynced
Schema registry48 schemasSyncedRebuilt in CI whenever a spec changes
- 05
Give the catalog an owner
Catalogs that last have an owner. Usually a central architecture or platform team owns the catalog itself: the structure, the standards and the deployment. They don’t write everything. They make it easy for everyone else to contribute.
Teams and ownershipArchitecture teamOwns the catalogSets the structure: domains, naming and templates
Runs the automation and the deployment
Reviews contributions from other teams
Automation for the facts. People for the meaning.
Step six is where the value compounds. Every team contributes in two ways: automation keeps what can be generated in sync, and pull requests add what only people know.
Automated
Pull requests from teams
What automation keeps current
Services, APIs, messages, channels and schema versions, generated from the specs and registries teams already maintain. The EventCatalog Agent updates the docs when code changes.
IntegrationsWhat people add
Business flows, what a schema means to the business, architecture decisions and domain language. Teams open a pull request like any other change, and the catalog owners review it.
How a catalog is structuredPlan your rollout with us.
Tell us how your teams work and we’ll help you choose where to start, what to automate and who should own it.
Where is the refunds flow documented?