In 2001 Joel Spolsky warned us about Architecture Astronauts — “smart” people who floated so high above the oxygen line they couldn’t ship a working program. In 2026 they have MBAs, PhDs, MCK slide decks, and a very complex vocabulary. The problem is identical.
When very clever Consultants think about problems, they start to see patterns. They look at a bank running thirty-year-old COBOL, and they look at an insurer running twenty-year-old COBOL. They realise there is a general pattern that can be monetised: legacy modernisation. That is one level of abstraction already. Then they go up one more level: legacy modernisation is really just digital transformation. And digital transformation 2026 is really just AI-enabled enterprise synergy. And if you can think about it (there is no oxygen up there), that is really just value chain optimisation through technology-enabled operating model redesign. Nobody knows what that means any more. And for nobody is meant to.
When you go too far up, abstraction-wise, you run out of oxygen. “Smart” consultants simply do not know when to stop, and they produce these grand, all-encompassing frameworks — Transformation Roadmaps, AI Maturity Models, Digital North Stars — that are beautifully formatted, ruthlessly billed, and deliver nothing operable.
These are the people I call MCK Astronauts. It is very hard to get them to specify a module, name a table, or draw a sequence diagram, because they will not stop thinking about Operating Models. They are astronauts because they are above the oxygen line. I do not know how they are breathing. They tend to work for organisations that can afford to pay $400,000 for a PowerPoint deck that describes, at a very high level, the idea of doing the thing the organisation already knew it needed to do.
The Pattern
A simple example illustrates this. Your typical MCK Astronaut will take a fact like “this bank needs its core banking system replaced” and immediately ignore the bank, the system, the data model, the integration points, and the 3,000 people whose jobs depend on it — thinking the interesting thing is the AI modernisation pattern. Suddenly, it is not a core banking replacement. It is a Composable Banking Transformation leveraging a Modular Architecture with AI-augmented Operations at Scale.
All they will talk about is platform thinking, ecosystem strategy, and hyperscaler synergies. Suddenly, you have Transformation Steering Committees, a Chief AI Officer reporting to the Chief Digital Officer reporting to the Chief Transformation Officer, and a (AI or no AI) Programme Management Office with forty people, none of whom have written a line of code or run a production incident at 3 am.
The Architecture Astronaut of 2001 abstracted away the software. The MCK Astronaut of 2026 abstracts away the delivery.
The MCK Astronaut will say things like: “Can you imagine a bank where everything is a composable platform, not just the payments layer?” Then they will build a Target Operating Model that is more general than an actual architecture, but which has somehow neglected that small feature called a working system — the feature the business wanted in the first place. If the bank were not cloud-native, but did process transactions reliably, meet Basel 3 compliance, and not go down on the last Friday of the month, it would have been just as successful.
The Vocabulary
Another thing MCK Astronauts like to do is invent new vocabulary and claim it solves something. Agile at Hyper Scale, DevSecOps, Synergy Engineering, AI-First, Composable Enterprise, Autonomus Deployment Automation, Cloud-Native Transformation, Agentic Enterprise — I cannot keep up. And that is just the last eighteen months.
I am not saying there is anything wrong with these concepts. By no means. They are quite good concepts. What bothers me is the stupendous amount of hype that surrounds them — and the way they are used to substitute activity for timely delivery, under budget. Consider:
EXHIBIT A — The Transformation Vision Statement
“Through an AI-first, cloud-native operating model redesign, we will unlock exponential value creation by empowering your people to harness the transformative potential of intelligent automation across your end-to-end value chain — delivering differentiated customer experiences whilst building the resilient, composable technology foundation required for sustained competitive advantage in the AI era.”
Source: Actual language. Any bank, insurer, or telco. Any year from 2019 to 2026. Author: MCK Astronaut, Engagement Manager grade.
That is not a strategy. That is a weather forecast written in a language where it cannot be wrong because it contains no falsifiable claim.
One sure signal that you are being visited by an MCK Astronaut: the incredible density of nominalised verbs. Not “we will build” but “delivery of build-out.” Not “we will connect systems” but “integration ecosystem orchestration.” The grammar itself has been abstracted. Subject and predicate have been dissolved into a warm fog of nouns. Nobody is doing anything. The doing has been architectured away.
Joel’s Astronauts Grew Up and Got PhDs
In 2001, Architecture Astronauts were usually technologists — smart engineers who had floated too far from working code. CORBA. DCOM. SOAP. XML as a universal solvent. Each promised interoperability nirvana; each delivered integration tax. The astronaut was at least building something, even if that something was a distributed object broker that required a PhD to configure.
In 2026, the MCK Astronaut had floated out of the engineering department entirely. Today’s MCK Astronaut has an MBA from INSEAD, two years at an AI strategy consultancy, and has never been responsible for a production system. They do not know what a failed schema migration feels like at 2 am. They have never had to explain to a regulator why a batch job failed. They have never debugged a race condition. Their entire career has been measured in PowerPoint slides approved and workshops facilitated.
This is not a personal failing. It is a structural one. The consultancy model selects for people who are excellent at producing persuasive documents under time pressure. It does not select for people who understand that software is a living system with weight, inertia, dependencies, and — crucially — operational cost that accrues every day you run it.
Remember that the MCK Astronaut is solving problems they think they can solve — frameworks, strategies, operating models — not problems which are useful to solve: working, running, maintainable IT landscapes.
How to Spot One in the Room
Ask them: What layer consolidates the legacy data domain? Watch carefully. The MCK Astronaut will not say “the customer services” or “we have not decided yet.” They will say: “That is a great question and it really gets to the heart of our data governance operating model, which we are addressing in workstream four of the transformation programme coming.”
Workstream four has no code in it. Workstream four is a set of workshops. Workstream four will use the generic consultancy template to produce a Data Governance Framework document. The document will describe, at a high level, the importance of deciding who owns the data. The bank will pay £2.4 million for this. The legacy data will still have no owner.
Or ask them: what are the deployment units? The MCK Astronaut will pivot immediately to organisational design. The deployment units are not their concern. Their concern is the Target Operating Model. The Target Operating Model has boxes and arrows. The boxes have names like “Agents Factory”, “Tribe”, and “AI Centre of Excellence.” None of the boxes contains a Dockerfile. (standard deployment unit for the last several years)
The Verdict
Remember that the MCK Astronaut is solving problems they think they can solve. Not a problem, you have. They will claim that an AI Strategy can be delivered in eight weeks. A Cloud Maturity Assessment in four. A Target Operating Model in twelve. Most importantly, all of these can be invoiced before any production system is touched. This is known to be structurally safer than actually building the thing.
None of these deliverables will reduce your infrastructure bill, decommission your legacy estate, shorten your release cycle, or improve your incident rate. They may, however, restructure your engineering department into “tribes” and “squads” in a way that means the people who understood the legacy data imprisoned in a legacy system no longer report to anyone who cares about the legacy knowledge.
Tell us something new that customers can deploy, or stay up there in the stratosphere and stop invoicing for the privilege of your altitude sickness.
The antidote in 2001 was the same as the antidote in 2026: find the person in the room who knows what the data model looks like, who has been paged at 3 am, who can name the three things most likely to break in production. Give that person the pen. Unlike astronauts, I take notes.
Enterprise Architecture should land safely. If it cannot be containerised, deployed, tested, and monitored, it is not architecture. It is tourism.
Inspired by Joel Spolsky, “Don’t Let Architecture Astronauts Scare You,” joelonsoftware.com, 21 April 2001. Original text and argument © Joel Spolsky. This translation updates terminology and examples to 2026; the core diagnosis is also his, unchanged and unimproved.
