Architecture

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. ...

DBJ Observations and Comments Observation: runtime infrastructure != deployment infrastructure Agreed. In the era of the general lack of experienced engineers that has to be said. Plainly. Observation: Skill is runtime artifact. That is the key problem keeping the whole agent harness non-deterministic It’s not Skill, it’s the inherent mechanism Skill is used by — fuzzy natural-language matching against a description, decided by the model at invocation time rather than fixed dispatch. That same mechanism is what makes deferred-tool loading (ToolSearch), subagent selection. Also the ordinary tool choice (Grep vs Read vs Agent) non-deterministic too. Skills are just the most visible facet of the LLM non-determinism because they’re named and listed explicitly. But used non deterministically. The classical-software analogue is late binding / reflection-based plugin dispatch Trading a fixed call graph for runtime flexibility, and paying for it in determinism missing. It is not “Skill” that is the problem, it is that harness resolves most capability binding (skills, tools, subagents, memory recall) via probabilistic matching instead of a deterministic dispatch table — and that’s a structural property of the whole LLM architecture, not a flaw isolated to the Skills. There is no deterministic table dispatch. It is as simple as that

The Flight Plan and the Autopilot The elusive goal of the “Competitive Advantage” What will “give” the “competitive advantage” is the Operational model, in order to navigate the whole organization around that huge iceberg of legacy. https://method.dbj.org/shop/ OP model introduction is not simple. But its worth it. Especially if organization is small(ish) and not too calcified. Just decide on one OP model, implement it and follow it. AI or no AI. ...

Summary “Workflow” is one word doing four jobs, and the collision is costing organizations clarity about what they actually own. Here’s the untangling. Just as we have different kinds of Architecture, we have different kind of Workflows. Again, DBJ Taxonomy brings order to the confusion. Feasibility replaces the struggle of intertwined responsibilities. And the required precondition of the functioning BPT (aka “the Loop”), of the DBJ Method Operating Model of the AI Readiness. ...

There’s a ladder. The rungs are labeled “AI Competence.” A novice climbs it, rung by rung, using a critical shortcut: “I didn’t learn, but the AI did.” It works. For a while it works great. The climb is fast, the view improves with every step, and the effort-to-altitude ratio feels like magic. Then the ladder ends. Not because the climber ran out of energy — because the ladder did. That point is the Danger-Kruger Peak: the spot where AI hallucinations start looking exactly like wisdom, because the climber has no competence of their own left to tell the difference. ...

Post Hype Agents This document defines a pragmatic, engineering-first approach to “Agentic” architectures, aligning them with the rigorous standards of the DBJ Method as established at DBJ.ORG. To move beyond current industry hysteria, we define the “Agent” not as an autonomous entity, but as a Policy-Controlled, Deterministic-Adjacent Task Handler. 1. Core Architectural Principles The Agent is a Consumer: Agents are treated as standard microservices. They pull from event streams (e.g., SQS) and execute strictly defined calls to backend APIs. Semantic Adaptation: The LLM is strictly used as a semantic bridge—translating unstructured input (text, legacy formats) into structured data—not as a substitute for business logic. Determinism First: All logic remains in compiled, testable code. The LLM handles the “intent parsing,” while the DBJ Method dictates the “transactional execution.” 2. Governance and Safety (The “Kill Switch” Model) Following the principles of identity-centric security, an Agent is a first-class identity entity: ...

Why they fit mainframes: Natural migration path — mainframe applications are already monolithic; modularizing in-place is less disruptive than immediate distribution Transaction boundaries — mainframes excel at ACID transactions within single processes; modular monoliths preserve this strength Reduced network overhead — avoids the latency and complexity of distributed calls that kill mainframe performance economics MIPS efficiency — in-process module calls consume far fewer MIPS than network hops or message queues The Evolution Path Legacy Monolith → Modular Monolith → Selective Distribution Start: Define bounded contexts within existing codebase Refactor: Extract modules with clear interfaces Stabilize: Prove the architecture, reduce technical debt Optionally: Extract specific modules to containers/services only where distribution adds value MIPS Impact Modular monoliths let you optimize hot paths and reduce coupling before adding distributed system overhead — often achieving 30–60% MIPS reduction without leaving the mainframe. ...

(Image source: https://cs.stanford.edu/people/eroberts/courses/soco/projects/2008-09/tony-hoare/images/hoare%20main.jpg ) In case you like code more than prose about the code, here is the code. That is vibed. Quality is average, bordering on bad. I spent some time, in between other tasks, and made what is I might claim, elegant, human optimised code. ( https://godbolt.org/z/9M8oj34TT ) Those improvements need never stop, of course. The Foundation Everyone Forgot — Almost Before Simula 67. Before Smalltalk. Before anyone had coined the term object-oriented programming. Tony Hoare formalized the concept of the discriminated union in his seminal 1965 paper, “Record Handling.” ...