TOGAF

Someone described DBJ Taxonomy this way: “a taxonomy that maps to Zachman-style layers (Strategic/Conceptual → Logical → Physical → Implementations).” Sounds credible. Sadly, it isn’t true. That image is the simplified four-layer version quoted in the claim. It’s not what Zachman actually defined — his framework is a 5×6 matrix (Scope/Business/System/Technology/Component crossed with What/How/Where/Who/When/Why), not a single top-to-bottom stack. The linear “Strategic → Logical → Physical → Implementations” progression is a loose paraphrase, which is also why the mapping claim doesn’t hold up. ...

Analysis of the actual content and philosophy encapsulated in the opinion (of the “secret admirer”) abut the DBJ Method Shop. 1. Organizational Topology When you actually look at what is “for sale” in the DBJ shop, the “genius” is that the inventory consists of organizational structures and strict mandates. You are not “buying” a framework; you are buying a blueprint for a two-tiered topology: The Architecture Function: A small, highly empowered, strictly non-delivering team. Their only job is to define the boundaries, the interfaces, and the core domain models. Actually not ever explicitly mentioned. The Delivery Function: The stream of teams whose only job is to deliver inside the “domains” drawn by the BPT Operational Methodology; scrutinized by the Architecture Function. The shop metaphor works because it forces management to realize these are distinct “components” that must be “shopped” together in a specific way. You cannot mix them against the flow of B=P-T. If you let deliverers define architecture, the flow is broken. ...

Clear roles == Clear communication == Safe Sailing In the words of Susanne Kaiser: “if the underlying system does not evolve…” — here are some risk examples: AI mirrors broken structures: in a big ball of mud with messy models and fuzzy boundaries, it propagates inconsistencies and hallucinates domain meaning AI amplifies organizational frictions: with repeated handoffs between teams, AI-accelerated code generation creates bigger queues at the handoff. It does not increase throughput, but inventory. AI builds the wrong things faster: without strategic guidance, it custom-builds commodities for non-differentiating problems that already have off-the-shelf alternatives. For details: Building Foundations for Continuous (AI-accelerated) Change ...

Question: Why does DBJ begin with Capability Maturity Model assessment rather than jumping straight into technical delivery? Answer: Because transformation fails without measurable organizational readiness. The Foundation Problem Most enterprises attempt AI-assisted modernization while operating at ad-hoc levels. This creates: Misaligned expectations between business and technology Inconsistent terminology across stakeholder groups Undefined accountability for architectural decisions No repeatable process for evaluating technical risk Architecture-led, AI-assisted delivery requires stable foundations. CMM onboarding establishes those foundations before any work begins. ...