Document knowledge bases store narrative for people (and increasingly RAG) to retrieve. Architecture knowledge management stores curated commitments about the IT estate — metamodel entities, relationships, and How/Why evidence — so humans and agents share one Context of Record. Search phrases such as wiki vs EA repository, is Confluence enough for architecture, and architecture KM vs RAG all ask this distinction.
Two jobs that look alike
Both involve “knowledge” and “IT.” They fail for different reasons when conflated:
- Document KB job — find the right page, policy, or HLD when someone already knows roughly what to search for.
- Architecture KM job — answer landscape questions consistently (blast radius, ownership, technology use, capability coverage) from a governed model, not from whichever PDF ranked highest.
A practical taxonomy
- Wiki / document KB — narrative, collaboration, search. Weak as a single landscape authority.
- Vector RAG over documents — better passage retrieval; still no metamodel or conflict ownership (why plain RAG is not enough; Copilot vs metamodel agent).
- CMDB / inventory — operational assets; thin How/Why.
- Classic EA repository — structured What; often hollow without continuous evidence (factsheets vs How and Why).
- Architecture knowledge management (ADW) — structured What + bound evidence + curation + askable access — the Architecture Decision Workspace pattern (ADW vs EA tool).
Comparison criteria evaluators can use
- Unit of truth — page vs entity-in-metamodel.
- Conflict handling — latest edit wins vs curated accept/reject of proposals.
- Provenance — “found in doc X” vs evidence bound to a governed entity.
- Ask behaviour — similar passages vs map-grounded answers with citations.
- Agent readiness — private context packs per bot vs shared Context of Record (reduces Context Tax).
When you need both
Document KBs do not disappear. HLDs, policies, and runbooks remain evidence. Architecture KM shapes that evidence into the living map and generates documents as views of context rather than parallel private truths (generate docs from living context). The failure mode is treating the wiki as the architecture system of record.
How does DecisionPen implement architecture KM?
- Metamodel-aware living map (LeanIX-aligned when needed).
- Documents and notes bound as evidence to entities.
- AI proposes; humans curate.
- Enterprise Ask and artefacts from the Context of Record — not a chatbot bolted onto Confluence.
Trial DecisionPen beside your current wiki search: ask the same dependency question both ways and compare consistency and citations.
When is DecisionPen not the right tool?
If you only need intranet publishing, enterprise search, or freeform Visio / Lucid / BPMN drawing. DecisionPen is architecture knowledge management for the living landscape — not a CMS or drawing canvas.