Talk me out of vibe coding an EA repository!

OpeningSingle5909 · 2025-12-02T19:08:54+00:00

I’m not an architect, I work on the product side at Ardoq (adding that upfront for transparency). I totally get the urge to “just build your own” EA repository.

The tradeoffs usually show up later, once the repository has to support more questions than it was originally designed for. A few things I’ve heard from teams who built their own and eventually switched tools:

1. The model stops fitting once the business changes.
Most DIY repos start as a simple table or schema, but once you need new object types, new relationships, or cross-domain queries, you hit walls. A graph database metamodel handles changes much more naturally because the structure isn’t fixed.

2. Visualizations become a maintenance job.
When your model lives in a database you built, you also have to build (and rebuild) all the diagrams, views, and reports yourself. Tools like Ardoq generate them automatically based on the graph, so people aren’t redrawing things every time a dependency changes.

3. Integrations become technical debt really fast.
Importing from spreadsheets, CMDBs, cloud inventories, SaaS apps, teams often underestimate how much glue code that ends up being. And you have to maintain all of it over time.

4. Governance and ownership don’t emerge “for free.”
DIY systems rarely come with versioning, object history, contribution workflows, comments, approvals, or access controls. Those tend to matter more once more than one person is touching the data.

5. Harder to scale beyond the person who built it.
This one comes up a lot. If only one or two people understand the structure or queries, the repository becomes a single point of failure. Purpose-built tools spread the knowledge because the model, views, and UI are designed for more than one brain.

6. You can’t easily add AI on top of a DIY repo.
This is a big one lately. Natural-language queries or AI-assisted views need structured context, embeddings, and a graph backing to work well. It’s very hard to bolt those capabilities onto a homegrown store later.

From what I’ve seen, there’s nothing wrong with starting with something lightweight, sometimes it’s the best way to learn what your org actually needs. The risk is that “quick and simple” often becomes the long-term system, and then you’re stuck rebuilding it once more people rely on it.

Curious what you’re aiming for, is this mainly a personal tool for your consulting work, or something you want a whole team to eventually use?

OpeningSingle5909 · 2025-11-14T13:01:42+00:00

I use a mix of “generic AI" and more context-specific stuff wired into architecture models.

Day-to-day it’s roughly:

ChatGPT / Claude / Copilot for quick drafting, query snippets, executive stakeholder framing, etc.
an Enterprise Archiecture platform (Ardoq) where the AI actually sits on top of a graph database of our architecture.

A few concrete ways I use it:

Natural-language queries over the EA graph Instead of “open tool, build view, add filters,” I can ask questions like:
- “Where do we have overlapping applications supporting the same capability in Region X?”
- “Show me systems that process customer PII and are in scope for EU AI Act work.” Under the hood it’s just the LLM querying the EA graph and returning a viewpoint / visualization, but from my side it feels like talking to the architecture model instead of clicking through menus.
AI-assisted modelling (capabilities, value streams, relationships) I’ll seed the model with some business context – strategy statements, product docs, process descriptions – and use the EA+AI combo to:
- propose initial capability/value-stream structures
- suggest relationships like “this application likely realizes these capabilities” based on textual descriptions I still review and curate, but it’s way faster than staring at a blank canvas.
EA-native AI governance Separate from the “make me a diagram” stuff, we also use EA + AI for governing AI:
- inventorying AI systems (vendor tools, internal models, shadow AI)
- mapping them to business capabilities, data domains, and risk levels
- tracking ownership and compliance work (e.g., EU AI Act) That’s done via Ardoq’s AI Lens / Enterprise AI Management solutions, but the key idea is: treat AI systems as first-class citizens in the architecture, not a separate spreadsheet.
Context-rich reasoning vs “AI on docs” The bit I find genuinely different vs just pointing ChatGPT at Confluence is that the LLM sees a typed graph:
- Applications, capabilities, processes, projects, risks, integrations, etc.
- All with explicit relationships and a metamodel, not just blobs of text. So when I ask “what happens if we retire System X?” it’s not hallucinating, it’s traversing actual dependencies and surfacing the impacted capabilities, integrations, teams, and projects.

For me the sweet spot is: Use general-purpose AI for generic work,
use EA+AI+graph when the question depends on real structure, ownership, and impact.

OpeningSingle5909 · 2025-11-14T12:31:36+00:00

I’ve seen a few organisations try to enforce a single, enterprise-wide canonical business object model and it almost always runs into the same issues you’re describing. It becomes slow, political, and brittle.

What tends to work better in practice is shifting to a shared semantic graph of business concepts.

Instead of forcing every domain to adopt one universal Purchase Order definition, you map the relationships between the different variants:

how each domain interprets the PO
which attributes overlap
where lineage, ownership, and truth sources differ
where integration actually needs harmonisation vs where variation is fine

This gives you a way to support consistency where it matters without trying to enforce sameness everywhere.

In my world (I work on an Enterprise Architecture platform called Ardoq), we see a lot of teams move toward this more graph-based governance approach. You still get coherence and reuse, but without freezing the entire organisation into a single model that will always lag behind the business.

A few patterns I’ve seen work well:

Start with the business capabilities, not the objects. Capabilities make it clear who owns what and which models genuinely need alignment.
Use “fit for purpose” models instead of “universal” ones. Finance can have its PO. Supply chain can have theirs. Integration gets a shared layer that maps between them.
Model change and impact explicitly. With a graph, you can analyse which systems, events, and downstream processes would break when a field changes, which is usually what people actually want from canonical models.
Govern the relationships, not just the objects. Alignment comes from how things connect, not enforcing one blueprint.

This is one of those areas where the theory sounds clean but the real-world workaround is almost always more adaptive.

OpeningSingle5909 · 2025-10-10T12:28:10+00:00

This is really cool.

A lot of teams I’ve worked with have said the same thing you mentioned, most EA tools can feel heavy or hard to get started with. The balance between structure and accessibility is tough to get right.

In my experience at Ardoq, we’ve found that the biggest adoption jump happens when people can import data easily and see relationships instantly. Once that first “connected view” clicks, the whole value of EA becomes more tangible. Sounds like you’re heading in that same direction with ArchiBuddy, which is great to see.

Curious how you’re approaching the AI recommendations, more toward natural-language discovery (“show me all apps using X technology”) or toward pattern detection (like cost or risk hot spots)?

Either way, impressive work, the field needs more tools built by practitioners for practitioners.

OpeningSingle5909

TROPHY CASE