Most IT problems get misdiagnosed before they get solved.

Before you replace it, rewrite it, or restructure around it, let’s find out what is actually wrong. Here is what that looks like in practice.

Book a 20-minute screening call

Most IT problems get misdiagnosed before they get solved.

The problem

The answer usually isn’t sitting in one person’s head. It’s scattered — an offhand complaint from months ago, a setting nobody currently on the team has touched, a detail from an unrelated meeting that quietly contradicts what everyone assumes. Nobody inside the system has all the pieces at once, because nobody inside the system talks to everyone else who has one.

Why it can’t be a framework

A framework can’t be taught to a junior team and run at scale. The value isn’t in the hours — it’s in one person holding the whole picture, with nothing to lose by saying what it adds up to. It’s also, usually, why the answer has to come from outside: the people closest to a system are the ones with the most to lose by naming its real cause.

Why replacement wins by default

Most IT defaults to replacing what it doesn’t understand — the way cars once got junked over a fault a mechanic couldn’t place, because replacing was cheap and diagnosing was slow. That won’t hold forever. The more these systems grow, the more expensive “just replace it” becomes.

This isn’t an attempt to replace what you already do. It’s a narrow offer for the rare project that doesn’t resolve with the usual tools — the one that’s identified but never actually understood.

If you have one, I’d like to have a look.

six problems. six organizations. six wrong diagnoses.

Each of these was already being solved – expensively, invasively, or incorrectly – before the actual problem was identified. These are the cases that define how I work.

The Devil (6-6-6) was in the details – Read the stories

financial technology

A mission-critical proxy had failed three times in six months. A full replacement project was underway. The system had never failed.

The actual problem was a connection pool configuration set twenty years ago and never updated. Two days to diagnose. An afternoon to fix. The replacement project was cancelled.

Major CanadiaN Bank

A team had grown from one application to seven. A Big Four firm diagnosed an organizational problem. The problem was architectural.

A foundational domain modelling mistake had been compounding for years, creating linear cost growth with every new product. One application could replace seven. Same team. Lower cost.

Global Investment Bank

A compliance process had been silently failing for five years at the rate of 10%. 80,000 regulatory documents were missing. Nobody knew.

Discovered during unstructured time. Diagnosed independently. Fixed in production during business hours without disruption. The kind of gap that triggers eight-figure regulatory fines.

another CanadiaN Bank

An ETL system supporting five data streams was maintained by 15-20 people. It processed fewer than 7,000 records on a typical day.

The infrastructure was disproportionate to the problem by an order of magnitude. A re-architecture improved throughput tenfold and identified a path to a hundredfold improvement.

SaaS Provider

A food takeout software provider needed to migrate 10M records from the client to its own DB. Their tool would take 10 months to finish.

But they needed to do this repeatedly for testing. So I developed a tool, a set of scripts, that accomplished this very task-repeated full migrations-in 3-4 days every time.

Life insurance compan y

Management wanted to eliminate manual work when the manual work was the only thing preventing costly trading errors.

Management had been misreading this as inefficiency for years. The renovation objective needed to change entirely. One question to the operations manager confirmed everything.

A Few stories about trust, character & Integrity

Competence is necessary, but without trust, character and integrity, it’s meaningless

TRUST is a must

In 2007, months before the financial crisis, a botched system upgrade at a Wall Street firm created 10 million duplicate equity records across hundreds of dependent systems simultaneously. The fix had to happen immediately, during trading hours, with no safety net and no parallel environment. Nobody volunteered. I did.

character is the key

At a Canadian life insurance company, I was the enterprise architect on a segregated fund renovation project with a fatally flawed foundation — a vendor who did not understand the core custom functionality, requirements inverted from thirty percent new to seventy percent, timeline estimates that were not just optimistic but pure fiction.

integrity is personal

At a global bank’s Capital Research, I inherited a system that five thousand people relied on, with little support after the entire New Jersey development team left. No documentation was available, and no statistics had been compiled. I investigated and discovered an 8-9% daily failure rate. I reengineered the system over the next 2 years, and the failure rate dropped to 0.1%, but I wasn’t happy.

Parting Gift

In 2014, I was fired from a top hospital for refusing to believe in af airy tale. The architect wanted to build a custom DB driver in JavaScript with a team that had learned JavaScript on the way to the interview. I said it could not be done. The following week, his favourite agency delivered the news. I kept looking anyway.

We were all marx brothers

This is what Ground-Level Architecture Intelligence finds. Not the problems organizations report — those are already known and already managed. The problems organizations have stopped seeing because they have been normal for so long that nobody remembers they were ever problems at all.

Three ways to work together

Gain insights into your cloud spending, deep-dive into your E2E IT/architecture patterns and processes, or perhaps get help with any kind of IT architecture deliverables on fractional basis