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

six problems. six organizations. six wrong diagnoses.

The Devil (6-6-6) was in the details

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.

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. They had a tool that 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.

Three stories about trust, character & Integrity

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

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.

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