Let’s keep making our patterns not just technically right — but clear, collaborative, and reusable.
Yesterday, Shane Gibson ran a fascinating public experiment.
He invited two peers — Christopher Gambill and Ramona C. Truta — to walk through his Data Architecture Layers Pattern Template live.
In 90 minutes they covered only a quarter of the template.
Not because the pattern was wrong — but because making it clear turned out to be the hardest part.
Press enter or click to view image in full size
Christopher had filled in the template alone beforehand. Shane can normally finish the whole thing with a subject-matter expert in about an hour. But this time the focus wasn’t speed; it was clarity.
Could someone new to the template understand each row and its values? Could they quickly tell whether the pattern would work in their world?
Ramona’s contribution was exactly what Shane hoped for: fresh eyes and tough questions. Sometimes she said “makes sense.” Sometimes she didn’t — and those unclear areas are now marked for iteration.
Shane summed it up perfectly: “It’s damn hard to describe a complex Data Engineering pattern in the few words Google Sheets allows.”
The hidden problem: communication
Most data architects love solving complex modeling problems.
We invent clever layers, reusable patterns, and elegant structures. But in practice, a pattern that only its author understands might as well not exist.
- Diagrams often live as isolated slides.
- Pattern templates get stuck in spreadsheets that lack shared vocabulary.
- Stakeholders see rows and columns but can’t grasp intent.
- Engineers misinterpret or re-invent because the original isn’t consumable.
The cost is real: duplicated effort, misunderstood models, brittle data platforms.
The session Shane hosted was a refreshing counterexample: build patterns in public, and let others break your mental model before it breaks in production.
Lessons from Shane’s live test
A few takeaways stood out:
- Test with outsiders early
Someone who has never seen the template can surface ambiguities you’ve stopped noticing. - Iterate on clarity, not just correctness
A technically perfect row that no one understands is still broken. - Feedback is design
Ramona’s “not so much” moments weren’t annoyances — they were gold. - Collaboration beats solitary modeling
Shane explicitly prefers to build with others, not alone. It’s slower in the moment but faster in the long run.
Why the next step is model-driven, metadata-first
Shane’s template lives in a Google Sheet — a good start for collaboration, but fragile at scale.
Over the past few years I’ve worked on a model-driven workflow that tries to solve this pain:
- Metadata first
Store pattern definitions and mappings as structured metadata (YAML, JSON, or in a lightweight DuckDB database).
This becomes the real “source of truth” — not a diagram or a spreadsheet. - Generate diagrams automatically
From metadata, scripts build draw.io diagrams (ERDs, mapping diagrams, architecture views).
They stay consistent and can be regenerated anytime. - Parse diagrams back
If someone tweaks a diagram, a parser can update the metadata.
No drift between picture and reality. - Use developer-friendly tools
Work in VS Code with the draw.io plugin; version everything in Git.
Review changes in pull requests, comment, and roll back. - Publish to stakeholders
Generate polished visuals and pattern descriptions for Confluence or other documentation spaces.
Non-technical users get clean, human-friendly diagrams and explanations.
The result: clarity + maintainability.
You can still test ideas in public like Shane did, but once a pattern stabilizes, you can scale it across teams without losing meaning.
Practical tips for sharing patterns
If you’re creating templates or frameworks, a few small moves make them easier to consume:
- Name things for readers, not authors
Use business-friendly terms where possible. - Add one-line purpose statements
Each row or column should say why it exists, not just what it is. - Pair text with visuals
Even a quick diagram alongside a table makes intent obvious. - Run the “Ramona test”
Have someone outside your core team read it cold.
If they stumble, fix the language or structure. - Keep metadata versioned
Use Git and text-based formats so patterns evolve predictably and transparently.
Architecture is storytelling
Shane’s experiment reminded me that architecture isn’t just design — it’s storytelling.
A brilliant model nobody can understand is invisible.
A clear but imperfect model gets adopted and improved.
If you’re investing in model-driven data engineering, don’t stop at building a great pattern. Build a communication layer around it:
- Collaborative review sessions (like Shane’s).
- Metadata-driven tooling that automates the grunt work.
- Diagrams that always stay in sync with the real model.
- Documentation that business and engineering can both read.
This isn’t fluff; it’s part of the work.
Watch, learn, and build better
If this resonates, watch Shane’s live session here: ▶️ YouTube replay
Try his latest template. And if you’re experimenting with model-driven, metadata-first approaches, check out my other posts on:
- Model-Driven Data Engineering
- Business-Friendly Mapping & Universal Models
- Automating draw.io with metadata
Let’s keep making our patterns not just technically right — but clear, collaborative, and reusable.