[{"content":"Post Hype Agents This document defines a pragmatic, engineering-first approach to \u0026ldquo;Agentic\u0026rdquo; architectures, aligning them with the rigorous standards of the DBJ Method as established at DBJ.ORG.\nTo move beyond current industry hysteria, we define the \u0026ldquo;Agent\u0026rdquo; not as an autonomous entity, but as a Policy-Controlled, Deterministic-Adjacent Task Handler.\n1. 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 \u0026ldquo;intent parsing,\u0026rdquo; while the DBJ Method dictates the \u0026ldquo;transactional execution.\u0026rdquo; 2. Governance and Safety (The \u0026ldquo;Kill Switch\u0026rdquo; Model) Following the principles of identity-centric security, an Agent is a first-class identity entity:\nIdentity Scoping: Every Agent is an IAM Principal with the minimum possible permission set. Policy-Controlled: Governance is decoupled from the Agent. Access is managed by an authorization layer (e.g., Okta) that monitors agent behavior. Emergency Revocation: The system must support the ability to instantly sever tokens and revoke access to backend resources if the agent deviates from defined policy or behaves anomalously. 3. The \u0026ldquo;Human-in-the-Loop\u0026rdquo; Contract To ensure system integrity, Agents operate under a strict drafting pattern:\nProposed Actions: An Agent never writes directly to a production database. Its output is a JSON \u0026ldquo;Proposed Action.\u0026rdquo; Validation Gate: A deterministic state machine validates the proposal against business rules. Authorization: No action is persisted or executed without verification by a secondary service or manual human approval, ensuring that \u0026ldquo;fuzzy\u0026rdquo; LLM output never breaches the DBJ Method’s integrity. 4. Operational Reality For DBJ.ORG and clients like Iron Code Labs, Agents are a tool for reducing integration friction in legacy or human-heavy workflows. They are modular, observable, and replaceable components of a larger, high-reliability architecture. They are not magic; they are just another interface for data ingestion and intent classification.\n","permalink":"https://iceberg.dbj.org/posts/post-hype-agents/","summary":"\u003ch1 id=\"post-hype-agents\"\u003ePost Hype Agents\u003c/h1\u003e\n\u003cp\u003eThis document defines a pragmatic, engineering-first approach to \u0026ldquo;Agentic\u0026rdquo; architectures, aligning them with the rigorous standards of the \u003cstrong\u003eDBJ Method\u003c/strong\u003e as established at \u003cstrong\u003eDBJ.ORG\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eTo move beyond current industry hysteria, we define the \u0026ldquo;Agent\u0026rdquo; not as an autonomous entity, but as a \u003cstrong\u003ePolicy-Controlled, Deterministic-Adjacent Task Handler\u003c/strong\u003e.\u003c/p\u003e\n\u003ch2 id=\"1-core-architectural-principles\"\u003e1. Core Architectural Principles\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eThe Agent is a Consumer:\u003c/strong\u003e Agents are treated as standard microservices. They pull from event streams (e.g., SQS) and execute strictly defined calls to backend APIs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSemantic Adaptation:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDeterminism First:\u003c/strong\u003e All logic remains in compiled, testable code. The LLM handles the \u0026ldquo;intent parsing,\u0026rdquo; while the DBJ Method dictates the \u0026ldquo;transactional execution.\u0026rdquo;\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"2-governance-and-safety-the-kill-switch-model\"\u003e2. Governance and Safety (The \u0026ldquo;Kill Switch\u0026rdquo; Model)\u003c/h2\u003e\n\u003cp\u003eFollowing the principles of identity-centric security, an Agent is a first-class identity entity:\u003c/p\u003e","title":"Post-Hype Agents"},{"content":"Regarding the phrase \u0026ldquo;EA has to align with AI\u0026rdquo; — a revolutionary flag being waved high. This time by Gartner:\nhttps://lnkd.in/d9F9_QZZ\nThis is completely upside down. EA will not change because of AI; to suggest otherwise misses the point of EA entirely. For 50 years, EA has matured into a vital tool. EA is a precision instrument that tells you, me, and all of us whether a business is truly aligned with its technology.\nP.S. Go down that road, and everything has to bend to AI — not just ITIL, PRINCE2, and Six Sigma, but medicine, math, and physics, too.\nP.P.S. An LLM is just an online chatbot — nothing more, nothing less. \u0026ldquo;AI\u0026rdquo; is just marketing, and marketing is just a pseudo-science designed to manipulate public attention.\nSolid reductio ad absurdum on the \u0026ldquo;X must adapt to AI\u0026rdquo; genre. The instrument does not redesign itself around the thing it is measuring.\n","permalink":"https://iceberg.dbj.org/posts/ea-is-an-instrument/","summary":"\u003cp\u003eRegarding the phrase \u0026ldquo;EA has to align with AI\u0026rdquo; — a revolutionary flag being waved high. This time by Gartner:\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://lnkd.in/d9F9_QZZ\"\u003ehttps://lnkd.in/d9F9_QZZ\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eThis is completely upside down. EA will not change because of AI; to suggest otherwise misses the point of EA entirely. For 50 years, EA has matured into a vital tool. EA is a precision instrument that tells you, me, and all of us whether a business is truly aligned with its technology.\u003c/p\u003e","title":"EA Is an Instrument"},{"content":"© Dusan B. Jovanovic — image generated with Gemini under author\u0026rsquo;s direction\nNobody told you this when you readily signed up for the API key.\nEvery LLM has the same training objective: predict the next token. Not the next true thing. Not the next logical step.\nThe next token — one symbol, conditioned on all the symbols before it.\nThat’s it. That’s the whole game.\nIMPORTANT It produces text that reads beautifully. It reasons the way a drunk navigates by streetlights — confident, directional, and increasingly wrong. Here is the mechanical problem. Each generated token feeds back into the context as input for the next prediction. So when the model makes a small error at step one, that error is now part of the premises at step two. The mistake doesn’t stay put. It becomes ground truth. The next token is predicted on top of a lie, and the one after that on top of a slightly larger lie, and so on down the chain until you’ve arrived somewhere that sounds perfectly coherent and has nothing to do with reality.\nEven a tiny per-token error rate compounds exponentially over a long generation. The architecture makes it unavoidable.\nThis is why hallucinations are not a flaw to be patched. They are load-bearing. More data slows the drift. RLHF roughens the edges. Neither changes what the model fundamentally is: a surface predictor that must generate stochastic noise alongside anything useful it produces. The noise ships with the signal. You are billed for both.\nRLHF — Reinforcement Learning from Human Feedback. A fine-tuning technique where human raters score model outputs; those scores train a reward model, which then guides further training via reinforcement learning. The goal is to steer outputs toward responses humans prefer. It does not change the underlying next-token architecture — it only reshapes which outputs the model favors.\nStochastic — randomly determined; having a probability distribution. In this context: the model does not pick the single most likely next token deterministically — it samples from a probability distribution, so identical inputs can produce different outputs. The randomness is by design; it is also why errors are baked in.\n","permalink":"https://iceberg.dbj.org/posts/feature-not-a-bug/","summary":"\u003cp\u003e\u003cem\u003e© Dusan B. Jovanovic — image generated with Gemini under author\u0026rsquo;s direction\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eNobody told you this when you readily signed up for the API key.\u003c/p\u003e\n\u003cp\u003eEvery LLM has the same training objective: predict the next token. Not the next true thing. Not the next logical step.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eThe next token — one symbol, conditioned on all the symbols before it.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThat’s it. That’s the whole game.\u003c/p\u003e\n\u003cdiv class=\"callout callout-important\"\u003e\n  \u003cspan class=\"callout-label\"\u003eIMPORTANT\u003c/span\u003e\n  \u003cdiv class=\"callout-body\"\u003eIt produces text that reads beautifully. It reasons the way a drunk navigates by streetlights — confident, directional, and increasingly wrong.\u003c/div\u003e\n\u003c/div\u003e\n\n\u003cp\u003eHere is the mechanical problem. Each generated token feeds back into the context as input for the next prediction. So when the model makes a small error at step one, that error is now part of the premises at step two. The mistake doesn’t stay put. It becomes ground truth. The next token is predicted on top of a lie, and the one after that on top of a slightly larger lie, and so on down the chain until you’ve arrived somewhere that sounds perfectly coherent and has nothing to do with reality.\u003c/p\u003e","title":"Feature, Not a Bug"},{"content":"Aleph Alpha: The Right Model Aleph Alpha, founded in Heidelberg in 2019 by Jonas Andrulis, built Luminous — a full LLM. Not a wrapper, not a fine-tune of someone else\u0026rsquo;s weights. Their own architecture, their own training, their own inference. They sit in the same category as OpenAI and Anthropic: model creators, not mills.\nTheir positioning was correct from the start: European sovereign AI. Data stays in Europe. No US cloud dependency. Strong traction with German public sector and defence. The differentiator is not raw benchmark performance — it is explainability and data sovereignty.\nPhariaAI is the enterprise platform built on top of Luminous. Where Luminous is the engine, PhariaAI is the complete product: PhariaAssistant (chat interface), PhariaStudio (development environment), PhariaOS (deployment and scaling), PhariaCatch (knowledge capture). It is the full DBMS, not just the database engine.\nFor on-premises customers, Aleph Alpha grants open access to the full model checkpoint including weights and code. This is the key fact.\nThe RDBMS Analogy When you buy Oracle or DB2 you own the licence, you run it on your hardware, the vendor provides support, patches, and updates — but you are not dependent on the vendor\u0026rsquo;s cloud for every query. Every transaction does not phone home.\nAleph Alpha\u0026rsquo;s on-premises model follows the same pattern. Deploy once. Operate independently. Vendor relationship for support and updates only.\nThis normalises LLM infrastructure the same way RDBMS was normalised in the 1990s. The LLM becomes a licensed infrastructure component, not a cloud service you rent by the token.\nDeutsche Bank, a German federal ministry, a defence agency — any of them can run Luminous weights on their own GPU hardware, run the full PhariaAI stack on their own infrastructure, and guarantee that zero data leaves their datacentre. The dependency that remains is identical to an enterprise software licence: support, updates, contractual relationship. No central mega-datacenter required.\nThe Cost Structure Consequence No hyperscaler margin is baked into every token. No egress fees. No per-query cloud billing that scales against you as usage grows. The cost model is CapEx: buy once, run indefinitely.\nThe LLM becomes a fixed infrastructure component. The economics are identical to:\nOn-premises RDBMS licence On-premises messaging middleware (IBM MQ) On-premises ESB For regulated industries this is not merely convenient — it is the only viable long-term model. Banking requires data to stay in the building. Defence requires air-gap capability. Healthcare satisfies GDPR trivially. Government guarantees jurisdiction.\nThe deeper insight is structural. Aleph Alpha scales with their customers\u0026rsquo; existing GPU investment rather than requiring Aleph Alpha to build and finance massive infrastructure themselves. The customer owns the hardware. Aleph Alpha provides the software. This is a lean business model and it is the correct architecture for the market they serve.\nThe Industrial Ownership Pattern The Schwarz Group — parent of Lidl and Kaufland, Europe\u0026rsquo;s largest retail conglomerate — became the dominant investor in Aleph Alpha and runs PhariaAI natively on STACKIT, their German hyperscaler. Europe\u0026rsquo;s largest retailer decided to own the AI infrastructure rather than depend on US hyperscalers for logistics, supply chain, and customer data processing.\nThis is not a tech company making a tech bet. It is an industrial company making an infrastructure decision. The same decision Deutsche Bank makes when it buys an RDBMS licence.\nIn April 2026, Cohere acquired Aleph Alpha in a deal valuing the combined entity at approximately $20 billion, with Schwarz Group committing $600 million as Series E lead investor in the merged company. The post-merger roadmap positions PhariaAI as the European orchestration and deployment layer of a transatlantic sovereign AI platform. The Cohere acquisition introduces procurement uncertainty for new customers and warrants monitoring before any contractual commitment.\nConclusion The pattern that emerges is not new. It is the same pattern that governed enterprise software adoption for thirty years.\nThe market does not move when the technology is ready. It moves when the procurement model is familiar. CIOs and CFOs understand CapEx plus support contract. They do not want infinite OpEx tied to someone else\u0026rsquo;s datacenter at someone else\u0026rsquo;s margin.\nDistributed AI — meaning AI that runs on the customer\u0026rsquo;s own hardware, under the customer\u0026rsquo;s own governance, with the vendor relationship confined to software and support — is not a future aspiration. With Aleph Alpha\u0026rsquo;s on-premises model it exists today.\nThe question for European enterprises is not whether this model is technically viable. It is. The question is whether the Cohere merger preserves it.\nDušan Jovanović — Enterprise Architect, DBJ.METHOD\n","permalink":"https://iceberg.dbj.org/posts/enterprise-ai-at-last/","summary":"\u003ch2 id=\"aleph-alpha-the-right-model\"\u003eAleph Alpha: The Right Model\u003c/h2\u003e\n\u003cp\u003eAleph Alpha, founded in Heidelberg in 2019 by Jonas Andrulis, built \u003cstrong\u003eLuminous\u003c/strong\u003e — a full LLM. Not a wrapper, not a fine-tune of someone else\u0026rsquo;s weights. Their own architecture, their own training, their own inference. They sit in the same category as OpenAI and Anthropic: model creators, not mills.\u003c/p\u003e\n\u003cp\u003eTheir positioning was correct from the start: European sovereign AI. Data stays in Europe. No US cloud dependency. Strong traction with German public sector and defence. The differentiator is not raw benchmark performance — it is explainability and data sovereignty.\u003c/p\u003e","title":"Enterprise AI, at Last"},{"content":" The Language Layer Does Not Matter Andrej Karpathy does not use C. He does not need to. His work sits at the model research and pedagogy layer where Python is the lingua franca. The real compute happens in C and CUDA underneath, but that layer is invisible to him. Training a model takes ten hours in C++ and ten hours in Python — the GPU is the bottleneck, not the host language.\nThe one exception is instructive: llm.c — a minimal GPT-2 training implementation in pure C, written deliberately as a proof of how thin the actual logic is once you strip framework overhead. That is the move closest to the systems programmer\u0026rsquo;s instinct: strip it down, see what remains.\nBryce Adelstein Lelbach (BAL) at NVIDIA — active on ISO WG21, leading CUDA parallelism work — represents the C++ committee\u0026rsquo;s relationship with C: benign neglect. C/C++ compatibility is acknowledged at the margins. C as a peer language is not engaged. The WG21 view is that C is a subset they have moved past.\nThis is not universal. The systems community disagrees. C remains a sharp, honest, deployment-ready tool.\nWhat llama.cpp Actually Is llama.cpp is not a full LLM. It is an inference engine.\nIt loads pre-trained model weights in GGUF format, runs the forward pass efficiently on CPU and GPU, handles quantisation at 4-bit and 8-bit, and provides a simple API and server interface. It does not train models. It contains no weights. It has no training loop.\nThe analogy holds precisely: llama.cpp is the JVM. The model weights are the bytecode. One without the other is useless.\nThe full stack is: someone else trains, exports to GGUF, llama.cpp runs it.\nThere are LLM implementations in Zig — community efforts around transformer inference that are genuine and technically motivated. Zig\u0026rsquo;s value proposition aligns with the problem: no hidden allocations, explicit memory control, C interop without FFI friction, comptime for kernel specialisation. But no production frontier LLM is written in Zig. These are hobby and research projects. The most credible C-adjacent inference story remains llama.cpp.\nDušan Jovanović — Enterprise Architect, DBJ.METHOD\n","permalink":"https://iceberg.dbj.org/posts/language-layer-does-not-matter/","summary":"\u003cimg src=\"/the_dark_bottom_dbj.png\" alt=\"\" width=\"75%\" /\u003e\n\u003ch2 id=\"the-language-layer-does-not-matter\"\u003eThe Language Layer Does Not Matter\u003c/h2\u003e\n\u003cp\u003eAndrej Karpathy does not use C. He does not need to. His work sits at the model research and pedagogy layer where Python is the lingua franca. The real compute happens in C and CUDA underneath, but that layer is invisible to him. Training a model takes ten hours in C++ and ten hours in Python — the GPU is the bottleneck, not the host language.\u003c/p\u003e","title":"The Language Layer Does Not Matter"},{"content":" Clear roles == Clear communication == Safe Sailing\nIn the words of Susanne Kaiser: \u0026ldquo;if the underlying system does not evolve\u0026hellip;\u0026rdquo; — here are some risk examples:\nAI 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\nHow DBJ.METHOD Addresses These Risks Each of these risks has a structural root cause — and a structural remedy. The DBJ Method is designed to address them before AI enters the picture.\nBroken structures → Taxonomy first AI mirrors what it finds. If the domain is undefined, AI will invent meaning. The DBJ Method begins with On-boarding — establishing a common Taxonomy as the organization\u0026rsquo;s positioning system. Every Category, every Capability is named and fixed before any tool touches the codebase.\nOrganizational friction → Maturity before velocity AI-accelerated output without mature handoffs just builds bigger queues. The DBJ Method raises the organization to CMM Level L3 — defined processes, governance structures, and architecture-driven communication — before entering the delivery loop.\nThroughput improves because the path is clear, not because the ship engine is faster.\nBuilding the wrong things → EA as the governing layer Without strategic guidance, AI will custom-build what should be bought off the shelf. In the DBJ Method, Enterprise Architecture is the meta-layer governing the BPT Loop — Business, Product, Technology in continuous cycle.\nUnder DBJ guidance, the client organization\u0026rsquo;s EA decides what gets built and why. AI-assisted engineering accelerates the how, within those rails.\n","permalink":"https://iceberg.dbj.org/posts/ai-or-iceberg/","summary":"\u003cblockquote\u003e\n\u003cp\u003eClear roles == Clear communication == Safe Sailing\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eIn the words of \u003ca href=\"https://www.linkedin.com/in/suksr/\"\u003eSusanne Kaiser\u003c/a\u003e: \u003cem\u003e\u0026ldquo;if the underlying system does not evolve\u0026hellip;\u0026rdquo;\u003c/em\u003e — here are some risk examples:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eAI mirrors broken structures: in a big ball of mud with messy models and fuzzy boundaries, it propagates inconsistencies and hallucinates domain meaning\u003c/li\u003e\n\u003cli\u003eAI 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.\u003c/li\u003e\n\u003cli\u003eAI builds the wrong things faster: without strategic guidance, it custom-builds commodities for non-differentiating problems that already have off-the-shelf alternatives.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eFor details: \u003ca href=\"https://susannekaiser.net/building-foundations-for-continuous-ai-accelerated-change/\"\u003eBuilding Foundations for Continuous (AI-accelerated) Change\u003c/a\u003e\u003c/p\u003e","title":"AI or Iceberg: EA as Navigator"},{"content":"Why they fit mainframes:\nNatural 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.\nMIPS (Million Instructions Per Second) is the billing unit in mainframe environments. Reducing MIPS directly reduces operational costs — often millions annually for large enterprises.\nThis aligns with DBJ principle: start modular monolith, distribute only if feasible.\n","permalink":"https://iceberg.dbj.org/posts/modular-monolith-for-mainframe/","summary":"\u003cp\u003e\u003cstrong\u003eWhy they fit mainframes:\u003c/strong\u003e\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eNatural migration path\u003c/strong\u003e — mainframe applications are already monolithic; modularizing in-place is less disruptive than immediate distribution\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTransaction boundaries\u003c/strong\u003e — mainframes excel at ACID transactions within single processes; modular monoliths preserve this strength\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eReduced network overhead\u003c/strong\u003e — avoids the latency and complexity of distributed calls that kill mainframe performance economics\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMIPS efficiency\u003c/strong\u003e — in-process module calls consume far fewer MIPS than network hops or message queues\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch3 id=\"the-evolution-path\"\u003eThe Evolution Path\u003c/h3\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eLegacy Monolith → Modular Monolith → Selective Distribution\n\u003c/code\u003e\u003c/pre\u003e\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eStart:\u003c/strong\u003e Define bounded contexts within existing codebase\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRefactor:\u003c/strong\u003e Extract modules with clear interfaces\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eStabilize:\u003c/strong\u003e Prove the architecture, reduce technical debt\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOptionally:\u003c/strong\u003e Extract specific modules to containers/services only where distribution adds value\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"mips-impact\"\u003eMIPS Impact\u003c/h3\u003e\n\u003cp\u003eModular monoliths let you optimize hot paths and reduce coupling \u003cem\u003ebefore\u003c/em\u003e adding distributed system overhead — often achieving 30–60% MIPS reduction without leaving the mainframe.\u003c/p\u003e","title":"Modular Monoliths for Mainframe Modernization"},{"content":"CMM --\u0026gt; MVA --\u0026gt; AI --\u0026gt; ROI AI won\u0026rsquo;t fix a broken foundation. Stop pouring budget into AI experiments that stall in the pilot phase. Technical debt is the silent killer of ROI. It\u0026rsquo;s time to move past the \u0026ldquo;Minimum Viable\u0026rdquo; mindset and build your Most Valuable Architecture (MVA). Clean the slate, structure your data, and finally see the returns you were promised.\nTurn Technical Debt into AI Equity. High complexity shouldn\u0026rsquo;t be the ceiling for your innovation. The MVA framework provides the structural integrity needed to bypass legacy bottlenecks. By applying a systematic, architectural approach to AI integration, we help you eliminate wasted spend and accelerate time-to-value.\nMVP is a well-known \u0026ldquo;AGILE\u0026rdquo; movement idea. Release ASAP. Don\u0026rsquo;t wait. Later cycles will ship the later versions. Time to market is more important than quality. That is why many call MVP: \u0026ldquo;Fake it until you make it.\u0026rdquo;\nMVA shifts the conversation from \u0026ldquo;doing the bare minimum to get by\u0026rdquo; to \u0026ldquo;investing in what actually scales.\u0026rdquo;\nIf your AI initiatives aren\u0026rsquo;t delivering, the problem isn\u0026rsquo;t the model — it\u0026rsquo;s the architecture. Stop building on sinking sand. Build a Most Valuable Architecture and turn your technical debt into a competitive engine.\n","permalink":"https://iceberg.dbj.org/posts/most-valuable-architecture/","summary":"\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eCMM --\u0026gt; MVA --\u0026gt; AI --\u0026gt; ROI\n\u003c/code\u003e\u003c/pre\u003e\u003ch2 id=\"ai-wont-fix-a-broken-foundation\"\u003eAI won\u0026rsquo;t fix a broken foundation.\u003c/h2\u003e\n\u003cp\u003eStop pouring budget into AI experiments that stall in the pilot phase. Technical debt is the silent killer of ROI. It\u0026rsquo;s time to move past the \u0026ldquo;Minimum Viable\u0026rdquo; mindset and build your \u003cstrong\u003eMost Valuable Architecture (MVA)\u003c/strong\u003e. Clean the slate, structure your data, and finally see the returns you were promised.\u003c/p\u003e\n\u003ch2 id=\"turn-technical-debt-into-ai-equity\"\u003eTurn Technical Debt into AI Equity.\u003c/h2\u003e\n\u003cp\u003eHigh complexity shouldn\u0026rsquo;t be the ceiling for your innovation. The MVA framework provides the structural integrity needed to bypass legacy bottlenecks. By applying a systematic, architectural approach to AI integration, we help you eliminate wasted spend and accelerate time-to-value.\u003c/p\u003e","title":"Most Valuable Architecture"},{"content":"Question: Why does DBJ begin with Capability Maturity Model assessment rather than jumping straight into technical delivery?\nAnswer: Because transformation fails without measurable organizational readiness.\nThe Foundation Problem Most enterprises attempt AI-assisted modernization while operating at ad-hoc levels. This creates:\nMisaligned 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.\nThe DBJ Method The DBJ.METHOD method operates as a bridge with two arches: Onboarding and The BPT Loop.\nCMM assessment forms the first arch — preparing organizations for sustainable EA-led transformation.\nArch 1: Onboarding DBJ establishes capability maturity foundations using a two-phase approach.\nPhase A: Assessing Current State DBJ Enterprise Architects evaluate organizational maturity using ACMM Levels L0–L5. This phase evaluates five structural elements present in every organization:\nGovernance — decision-making authority, policies, oversight Skilled Resource Pool — people and available competencies Projects / Portfolios — work initiation, execution, delivery Business Operations — day-to-day function and continuity Architecture Repository — organizational knowledge base The organization\u0026rsquo;s DBJ CMM level is the minimum score across all five elements — a high score in one area cannot mask a critical gap in another.\nAssessment activities:\nEstablishes shared vocabulary through Common Taxonomy Identifies capability gaps via ACMM scorecard across all five elements Defines achievable initial target state (L3 — Defined) Outcome: ACMM baseline assessment with EA-guided improvement roadmap\nPhase B: Achieving Defined Maturity (L3) DBJ Enterprise Architects guide, document and implement architecture processes, transitioning organizations from ad-hoc (L1) to defined (L3) operations.\nImplements governance structures with executive engagement Deploys architecture-driven communication practices Embeds Common Taxonomy as organizational standard Outcome: Organization operating at CMM L3 across all five elements — the entry threshold for the DBJ BPT methodology\nWhy This Matters Without ACMM foundations:\nArchitectural decisions lack organizational support Technical debt reduction efforts fail to gain traction Business-technology alignment remains superficial Transformation initiatives stall in governance gaps ACMM onboarding ensures organizations can sustain the improvements DBJ delivers.\n","permalink":"https://iceberg.dbj.org/posts/why-cmm-onboarding/","summary":"\u003cp\u003e\u003cstrong\u003eQuestion:\u003c/strong\u003e Why does DBJ begin with Capability Maturity Model assessment rather than jumping straight into technical delivery?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAnswer:\u003c/strong\u003e Because transformation fails without measurable organizational readiness.\u003c/p\u003e\n\u003ch2 id=\"the-foundation-problem\"\u003eThe Foundation Problem\u003c/h2\u003e\n\u003cp\u003eMost enterprises attempt AI-assisted modernization while operating at ad-hoc levels. This creates:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eMisaligned expectations between business and technology\u003c/li\u003e\n\u003cli\u003eInconsistent terminology across stakeholder groups\u003c/li\u003e\n\u003cli\u003eUndefined accountability for architectural decisions\u003c/li\u003e\n\u003cli\u003eNo repeatable process for evaluating technical risk\u003c/li\u003e\n\u003c/ul\u003e\n\u003cblockquote\u003e\n\u003cp\u003eArchitecture-led, AI-assisted delivery requires stable foundations. CMM onboarding establishes those foundations before any work begins.\u003c/p\u003e","title":"Why CMM Onboarding Is DBJ.METHOD's First Step"},{"content":" Socrates then supposes that the prisoners are released. A freed prisoner would look around and see the fire. The light would hurt his eyes and make it difficult for him to see the objects casting the shadows. If he were told that what he is seeing is real instead of the other version of reality he sees on the wall of Technical Debt, he would not believe it. In his pain, Socrates continues, the freed prisoner would turn away and run back to what he is accustomed to (that is, the shadows of the carried objects of Technical Debt). The light \u0026ldquo;\u0026hellip; would hurt his eyes, and he would escape by turning away to the things which he was able to look at, and these he would believe to be clearer than what was being shown to him.\u0026rdquo;\nTransformed from Allegory of the Cave — Wikipedia\n","permalink":"https://iceberg.dbj.org/posts/platos-cave/","summary":"\u003cimg src=\"/the_dark_bottom_dbj.png\" alt=\"\" width=\"75%\" /\u003e\n\u003cp\u003eSocrates then supposes that the prisoners are released. A freed prisoner would look around and see the fire. The light would hurt his eyes and make it difficult for him to see the objects casting the shadows. If he were told that what he is seeing is real instead of the other version of reality he sees on the wall of Technical Debt, he would not believe it. In his pain, Socrates continues, the freed prisoner would turn away and run back to what he is accustomed to (that is, the shadows of the carried objects of Technical Debt). The light \u0026ldquo;\u0026hellip; would hurt his eyes, and he would escape by turning away to the things which he was able to look at, and these he would believe to be clearer than what was being shown to him.\u0026rdquo;\u003c/p\u003e","title":"Departure from the Cave of Technical Debt"},{"content":"The AI hype cycle is running on fumes — and the fumes are labeled \u0026ldquo;Future,\u0026rdquo; \u0026ldquo;Promise,\u0026rdquo; and \u0026ldquo;More AI!\u0026rdquo;\nWe\u0026rsquo;ve all seen it. A wobbly tower of buzzwords. Robots with megaphones. Executives cheering at a pile of rubble with \u0026ldquo;REALITY\u0026rdquo; written at the base.\nThe cartoon writes itself because the pattern writes itself:\nAnnounce the AI initiative Stack acronyms until the tower looks impressive Call any collapse a \u0026ldquo;learning opportunity\u0026rdquo; Add more AI What\u0026rsquo;s actually out of hand isn\u0026rsquo;t AI. It\u0026rsquo;s the organizational incompetence that AI is being asked to hide.\nBad processes powered by AI are just faster bad processes. Unclear accountability with an AI layer is unclear accountability with a demo. A strategy that couldn\u0026rsquo;t survive scrutiny before the LLM won\u0026rsquo;t survive it after.\nThe robots in this picture aren\u0026rsquo;t threatening us. They\u0026rsquo;re pointing at us.\nThe question for every enterprise leader isn\u0026rsquo;t \u0026ldquo;Are we using AI?\u0026rdquo; It\u0026rsquo;s \u0026ldquo;Do we actually know what problem we\u0026rsquo;re solving, who owns it, and how we\u0026rsquo;ll know if the \u0026lsquo;solution\u0026rsquo; worked?\u0026rdquo;\nIf the answer is vague, the tower will fall. Spectacularly. On camera.\nArchitecture exists precisely to prevent this — to make the structure visible before it collapses, not after.\nWhat\u0026rsquo;s the most impressive-sounding AI initiative you\u0026rsquo;ve seen that turned out to be a very expensive megaphone?\n","permalink":"https://iceberg.dbj.org/posts/incompetence-is-out-of-hand/","summary":"\u003cp\u003e\u003cstrong\u003eThe AI hype cycle is running on fumes — and the fumes are labeled \u0026ldquo;Future,\u0026rdquo; \u0026ldquo;Promise,\u0026rdquo; and \u0026ldquo;More AI!\u0026rdquo;\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eWe\u0026rsquo;ve all seen it. A wobbly tower of buzzwords. Robots with megaphones. Executives cheering at a pile of rubble with \u0026ldquo;REALITY\u0026rdquo; written at the base.\u003c/p\u003e\n\u003cp\u003eThe cartoon writes itself because the pattern writes itself:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eAnnounce the AI initiative\u003c/li\u003e\n\u003cli\u003eStack acronyms until the tower looks impressive\u003c/li\u003e\n\u003cli\u003eCall any collapse a \u0026ldquo;learning opportunity\u0026rdquo;\u003c/li\u003e\n\u003cli\u003eAdd more AI\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eWhat\u0026rsquo;s actually out of hand isn\u0026rsquo;t AI. It\u0026rsquo;s the organizational incompetence that AI is being asked to hide.\u003c/p\u003e","title":"The Incompetence Is Out of Hand"},{"content":"There\u0026rsquo;s a word MIT hackers coined in the 1950s: cruft — useless, tangled, accumulated junk that makes a system incomprehensible and impossible to build on.\nSound familiar?\nIn 2026, we have a new variant: crufty AI.\nChatbots bolted onto data silos. LLMs fed dirty, unstructured, undocumented inputs. Automation layered on top of processes nobody fully understands anymore. Pilots that never graduate. Dashboards nobody uses. Vendors paid. ROI: zero.\nThis isn\u0026rsquo;t an AI problem. It\u0026rsquo;s a cruft problem.\nYou can\u0026rsquo;t get intelligence out of a system that was never coherent to begin with. The model isn\u0026rsquo;t the issue — the substrate is.\nYour AI isn\u0026rsquo;t underperforming. Your architecture is. Before you buy another AI license, ask: Is your data governed, or just stored? Do your systems integrate, or just coexist? Does anyone have a current map of what actually runs this business? AI amplifies what\u0026rsquo;s already there. If what\u0026rsquo;s already there is crufty, you\u0026rsquo;ll get crufty results — faster and at greater expense.\nThe fix isn\u0026rsquo;t a better model. It\u0026rsquo;s architecture.\n","permalink":"https://iceberg.dbj.org/posts/crufty-ai/","summary":"\u003cp\u003eThere\u0026rsquo;s a word MIT hackers coined in the 1950s: \u003cstrong\u003ecruft\u003c/strong\u003e — useless, tangled, accumulated junk that makes a system incomprehensible and impossible to build on.\u003c/p\u003e\n\u003cp\u003eSound familiar?\u003c/p\u003e\n\u003cp\u003eIn 2026, we have a new variant: \u003cstrong\u003ecrufty AI.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eChatbots bolted onto data silos. LLMs fed dirty, unstructured, undocumented inputs. Automation layered on top of processes nobody fully understands anymore. \u003cstrong\u003ePilots that never graduate\u003c/strong\u003e. Dashboards nobody uses. Vendors paid. ROI: zero.\u003c/p\u003e\n\u003cp\u003eThis isn\u0026rsquo;t an AI problem. It\u0026rsquo;s a cruft problem.\u003c/p\u003e","title":"Crufty AI"},{"content":"Is this post card from the past or is this a post card from the future?\nA fascinating and often overlooked chapter in AI history. Kunihiko Fukushima and his Neocognitron, a pioneering artificial \u0026ldquo;brain\u0026rdquo; was developed in 1979. That laid the foundation for today\u0026rsquo;s deep learning.\nThe \u0026ldquo;Artificial Brain\u0026rdquo; (Neocognitron): Created by Kunihiko Fukushima in 1979, it was the world\u0026rsquo;s first multilayer convolutional neural network. This architecture is now the backbone of modern AI vision systems. The Biological Approach: Unlike most Western AI at the time, Fukushima\u0026rsquo;s goal was to simulate the brain to understand human vision. The 1970s Context: He conducted this research during the so-called \u0026ldquo;AI winter\u0026rdquo; at NHK\u0026rsquo;s Science \u0026amp; Technical Research Laboratories. The WABOT-1 Connection There was an actual robot rather than just a brain model. WABOT-1, the world\u0026rsquo;s first full-scale humanoid robot, built in 1973 at Waseda University. It had a limb-control system, vision system, and conversation system, and was estimated to have the mental faculty of a one-and-a-half-year-old child.\nReferences Kunihiko Fukushima — Wikipedia Neocognitron — Wikipedia Neocognitron — Scholarpedia WABOT — Wikipedia ","permalink":"https://iceberg.dbj.org/posts/ai-history/","summary":"\u003cp\u003eIs this post card from the past or is this a post card from the future?\u003c/p\u003e\n\u003cp\u003eA fascinating and often overlooked chapter in AI history. \u003cstrong\u003eKunihiko Fukushima and his Neocognitron\u003c/strong\u003e, a pioneering artificial \u0026ldquo;brain\u0026rdquo; was developed in 1979. That laid the foundation for today\u0026rsquo;s deep learning.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eThe \u0026ldquo;Artificial Brain\u0026rdquo; (Neocognitron)\u003c/strong\u003e: Created by Kunihiko Fukushima in 1979, it was the world\u0026rsquo;s first \u003cstrong\u003emultilayer convolutional neural network\u003c/strong\u003e. This architecture is now the backbone of modern AI vision systems.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eThe Biological Approach\u003c/strong\u003e: Unlike most Western AI at the time, Fukushima\u0026rsquo;s goal was to \u003cstrong\u003esimulate the brain\u003c/strong\u003e to understand human vision.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eThe 1970s Context\u003c/strong\u003e: He conducted this research during the so-called \u0026ldquo;AI winter\u0026rdquo; at NHK\u0026rsquo;s Science \u0026amp; Technical Research Laboratories.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"the-wabot-1-connection\"\u003eThe WABOT-1 Connection\u003c/h3\u003e\n\u003cp\u003eThere was an actual robot rather than just a brain model. \u003cstrong\u003eWABOT-1\u003c/strong\u003e, the world\u0026rsquo;s first full-scale humanoid robot, built in 1973 at Waseda University. It had a limb-control system, vision system, and conversation system, and was estimated to have the \u003cstrong\u003emental faculty of a one-and-a-half-year-old child\u003c/strong\u003e.\u003c/p\u003e","title":"AI History: Postcard from 1979"},{"content":" The Paper Everyone Forgot — Almost Tony Hoare published \u0026ldquo;Record Handling\u0026rdquo; in 1966. Before Simula 67. Before Smalltalk. Before anyone had coined the term object-oriented programming.\nHe wasn\u0026rsquo;t thinking about objects sending messages to each other. He was thinking about something much simpler: data with a type tag, and code that switches on that tag.\nWhat He Actually Proposed You have a record. The record knows what it is — it carries a tag. You have a dispatch function that looks at the tag and calls the right handler. The handler takes storage and params. That\u0026rsquo;s it.\nNo object. No this. No method lookup. No vtable. A record, a tag, and a switch.\nIt\u0026rsquo;s almost embarrassingly simple. Which is probably why it got overlooked.\nThe Irony Alan Kay also called his model \u0026ldquo;message passing\u0026rdquo; — same words, completely different idea.\nIn Kay\u0026rsquo;s model, dispatch is implicit. It\u0026rsquo;s buried in the vtable, hidden behind the dot operator. The receiver decides what to do. The caller is blind to the mechanism.\nIn Hoare\u0026rsquo;s model, dispatch is right there in front of you. The tag is visible data. The switch is visible code. You can inspect it, reason about it, have the compiler check it.\nKay Hoare Syntax object.method(args) dispatch(cmd) Dispatch Receiver owns it — caller is blind Explicit — tag is inspectable Where It Went Wrong Simula read Hoare\u0026rsquo;s paper. They kept the subclass idea. But they dropped inspect — the keyword that would have given you exhaustive switching on the type tag.\nOne keyword. Gone.\nThat single omission is what Casey Muratori calls the 35-year mistake. C++ inherited Simula. Java inherited C++. And for decades, the mainstream got Kay\u0026rsquo;s model — the one where the mechanism is hidden and the caller just has to trust.\nWhat Came Back Around Rust\u0026rsquo;s enum + match is essentially what Hoare described in 1966. Explicit tags. Exhaustive checking. The compiler tells you when you\u0026rsquo;ve missed a case. Nothing hidden, nothing implicit.\nIt took 58 years to get back there.\nSometimes the road not taken just takes longer.\nRest well, Sir Tony.\n","permalink":"https://iceberg.dbj.org/posts/tonyhoare/","summary":"\u003cimg src=\"/the_dark_bottom_dbj.png\" alt=\"\" width=\"75%\" /\u003e\n\u003ch2 id=\"the-paper-everyone-forgot--almost\"\u003eThe Paper Everyone Forgot — Almost\u003c/h2\u003e\n\u003cp\u003eTony Hoare published \u0026ldquo;Record Handling\u0026rdquo; in 1966. Before Simula 67. Before Smalltalk. Before anyone had coined the term object-oriented programming.\u003c/p\u003e\n\u003cp\u003eHe wasn\u0026rsquo;t thinking about objects sending messages to each other. He was thinking about something much simpler: data with a type tag, and code that switches on that tag.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"what-he-actually-proposed\"\u003eWhat He Actually Proposed\u003c/h2\u003e\n\u003cp\u003eYou have a record. The record knows what it is — it carries a tag. You have a dispatch function that looks at the tag and calls the right handler. The handler takes storage and params. That\u0026rsquo;s it.\u003c/p\u003e","title":"A Tribute to C.A.R. Hoare"},{"content":" Advisory on the DBJ.METHOD IP rights Author: Dusan B. Jovanovic (dbj@dbj.org) DBJ Method is dual-licensed. User rights and obligations under CC BY SA 4.0 What the User does NOT have to do Practical risk for the User Commercial License — the alternative path Conclusion Advisory on the DBJ.METHOD IP rights Author: Dusan B. Jovanovic (dbj@dbj.org) DBJ Method support and general enquiries: info@dbj.org\nActive License: CC BY SA 4.0 — Creative Commons Attribution-ShareAlike 4.0 International\nDBJ Method is dual-licensed. The public license is CC BY SA 4.0 — it applies to all Users by default.\nA commercial license is available from DBJ for Users who require closed-source or proprietary distribution rights. Contact: dbj@dbj.org\nThis license covers the DBJ Method and all content in this repository.\nDusan B. Jovanovic retains full copyright as author. The license governs all other parties.\nUnder CC BY SA 4.0, any user of DBJ Method is free to:\nShare — copy and redistribute the material in any medium or format\nAdapt — remix, transform, and build upon the material for any purpose, including commercially\nUnder these conditions:\nAttribution — You must credit Dusan B. Jovanovic (dbj@dbj.org), link to the license, and indicate if changes were made\nShareAlike — If you adapt or build on this material, your derivative work must be distributed under the same CC BY SA 4.0 license\nWhat this means for DBJ Method specifically:\nAnyone can use, teach, translate, or build on the methodology — but they cannot close it off. Any derivative work (a consultancy\u0026rsquo;s adaptation, a training course, a tool built on the framework) must itself be released under CC BY SA 4.0. The ShareAlike clause is the enforcement mechanism: it propagates forward through every derivative, making it structurally impossible for downstream users to proprietize the work.\nThis is the correct license for methodology and documentation IP. MIT would have permitted commercial enclosure without attribution or reciprocity — inappropriate for this kind of intellectual work.\nUser rights and obligations under CC BY SA 4.0 Under CC BY SA 4.0, any User must do three things:\nAttribution — on every use\nCredit the source clearly and visibly:\nDBJ Method © Dusan B. Jovanovic (dbj@dbj.org) — CC BY SA 4.0\nOn a site: in the footer or on a dedicated credits/legal page.\nOn training material: on the title slide/page and in the document footer.\nLink to the license\nInclude a reference to https://creativecommons.org/licenses/by-sa/4.0/ wherever the attribution appears.\nShareAlike — on any adaptation\nIf the User modifies, extends, or incorporates DBJ Method into their own material (e.g., a methodology based on BPT), that derivative material must also be released under CC BY SA 4.0. The User cannot wrap it in a proprietary license.\nWhat the User does NOT have to do No permission from DBJ is required to use it No royalties are due The User can charge customers for training that uses the material The User does not need to share their internal business processes — only the derived methodology content itself falls under ShareAlike Practical risk for the User If a User creates training material that substantially incorporates DBJ Method and distributes it under a proprietary license — that is a license violation. The ShareAlike clause is what prevents that. DBJ would have standing to enforce it.\nCommercial License — the alternative path DBJ as copyright holder can dual-license the work. CC BY SA 4.0 is the public license — it forces ShareAlike on everyone. DBJ can separately grant a User a private commercial license that overrides ShareAlike and explicitly permits:\nIncorporating DBJ Method into proprietary products Releasing derivative material as closed source Selling it without attribution or reciprocity obligations This is standard practice — MySQL (GPL + commercial) and Qt operate the same way.\nWhat that requires:\nA written bilateral agreement between DBJ and the User, specifying scope of use, territory, duration, exclusivity, and fee or royalty structure. The User\u0026rsquo;s obligations under that agreement replace their CC BY SA 4.0 obligations entirely.\nThe leverage point:\nA User cannot obtain closed-source rights without DBJ\u0026rsquo;s agreement. The CC BY SA 4.0 public license is the default — and it is deliberately restrictive. A commercial license is a negotiated exception, priced accordingly.\nIf a User wants to build a proprietary training product or consulting framework on top of DBJ Method and sell it as their own IP — that conversation starts with DBJ, not with Creative Commons.\nConclusion A User needs to negotiate only if they want to release derivative content under a closed/proprietary license.\nThe trigger is not selling — it\u0026rsquo;s closing. A User can:\nUse DBJ Method commercially ✓ Charge customers for training that incorporates it ✓ Build services around it ✓ All without negotiating anything, under CC BY SA 4.0 as-is. The moment they want to distribute adapted content without the ShareAlike obligation — that is when they need a commercial license from DBJ. Whether money changes hands is secondary. The legal trigger is the proprietary distribution, not the price tag.\n","permalink":"https://iceberg.dbj.org/ip-advisory/","summary":"\u003cul\u003e\n\u003cli\u003e\u003ca href=\"#advisory-on-the-dbjmethod-ip-rights\"\u003eAdvisory on the DBJ.METHOD IP rights\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"#author-dusan-b-jovanovic-dbjdbjorg\"\u003eAuthor: Dusan B. Jovanovic (dbj@dbj.org)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#dbj-method-is-dual-licensed\"\u003eDBJ Method is dual-licensed.\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#user-rights-and-obligations-under-cc-by-sa-40\"\u003eUser rights and obligations under CC BY SA 4.0\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#what-the-user-does-not-have-to-do\"\u003eWhat the User does NOT have to do\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#practical-risk-for-the-user\"\u003ePractical risk for the User\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#commercial-license--the-alternative-path\"\u003eCommercial License — the alternative path\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#conclusion\"\u003eConclusion\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch1 id=\"advisory-on-the-dbjmethod-ip-rights\"\u003eAdvisory on the DBJ.METHOD IP rights\u003c/h1\u003e\n\u003ch3 id=\"author-dusan-b-jovanovic-\"\u003eAuthor: Dusan B. Jovanovic (\u003ca href=\"mailto:dbj@dbj.org\"\u003edbj@dbj.org\u003c/a\u003e)\u003c/h3\u003e\n\u003cblockquote\u003e\n\u003cp\u003eDBJ Method support and general enquiries: \u003ca href=\"mailto:info@dbj.org\"\u003einfo@dbj.org\u003c/a\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eActive License: \u003cstrong\u003eCC BY SA 4.0 — Creative Commons Attribution-ShareAlike 4.0 International\u003c/strong\u003e\u003c/p\u003e","title":"IP Advisory"}]