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

CMM --> MVA --> AI --> ROI AI won’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’s time to move past the “Minimum Viable” mindset and build your Most Valuable Architecture (MVA). Clean the slate, structure your data, and finally see the returns you were promised. Turn Technical Debt into AI Equity. High complexity shouldn’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. ...

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

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 “… 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.” ...

The AI hype cycle is running on fumes — and the fumes are labeled “Future,” “Promise,” and “More AI!” We’ve all seen it. A wobbly tower of buzzwords. Robots with megaphones. Executives cheering at a pile of rubble with “REALITY” written at the base. The cartoon writes itself because the pattern writes itself: Announce the AI initiative Stack acronyms until the tower looks impressive Call any collapse a “learning opportunity” Add more AI What’s actually out of hand isn’t AI. It’s the organizational incompetence that AI is being asked to hide. ...

There’s a word MIT hackers coined in the 1950s: cruft — useless, tangled, accumulated junk that makes a system incomprehensible and impossible to build on. Sound familiar? In 2026, we have a new variant: crufty AI. Chatbots 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. This isn’t an AI problem. It’s a cruft problem. ...

Is this post card from the past or is this a post card from the future? A fascinating and often overlooked chapter in AI history. Kunihiko Fukushima and his Neocognitron, a pioneering artificial “brain” was developed in 1979. That laid the foundation for today’s deep learning. The “Artificial Brain” (Neocognitron): Created by Kunihiko Fukushima in 1979, it was the world’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’s goal was to simulate the brain to understand human vision. The 1970s Context: He conducted this research during the so-called “AI winter” at NHK’s Science & Technical Research Laboratories. The WABOT-1 Connection There was an actual robot rather than just a brain model. WABOT-1, the world’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. ...

The Paper Everyone Forgot — Almost Tony Hoare published “Record Handling” in 1966. Before Simula 67. Before Smalltalk. Before anyone had coined the term object-oriented programming. He wasn’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. What 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’s it. ...