Brad Doleman
← Selected work

Case study · Principal Infrastructure Architect · 2026

Holding the architecture steady inside a $154M modernization

A three-year enterprise network modernization across more than 6,500 locations, delivered on a compressed timeline while the organization around it was being restructured.

Program scale

6,500+ Locations in scope
$154M Three-year program value
$80M Operating cost reduction the program was projected to deliver

The situation

A national retailer was midway into a multi-year modernization of its enterprise network — the kind of program where the design decisions made early determine the operating cost for the next decade. At the same time, the organization was going through a leadership transition and corporate restructuring.

That combination is where large programs quietly go wrong. Architectural authority becomes unclear, decisions get deferred, vendors fill the vacuum with their own roadmaps, and by the time the new leadership is settled the program has drifted somewhere nobody chose.

I was brought in as principal architect to hold the technical direction while that transition ran its course. The program itself was owned above me; my accountability was the architecture inside it.

What I owned

  • Core architectural governance and engineering direction for the program
  • Validation of high-availability headend designs against the program’s projected operating cost model
  • Cross-functional architecture governance across internal engineering, security, compliance, and vendor teams
  • Senior advisory to security, compliance, and infrastructure leadership through the restructuring
  • Alignment of multi-site vendor commitments to security compliance and long-term capacity requirements

The approach

Put the architecture in writing, not in people. The first risk in a leadership transition is that the reasoning behind decisions lives in someone’s head and walks out the door with them. I worked to get the design rationale, the constraints, and the tradeoffs documented and governed, so the program’s direction did not depend on who was in the room that quarter.

Tie the design to the money. The projected operating cost reduction was not a byproduct of the architecture — it was a design constraint. Headend designs were validated against availability requirements and the cost model together, because a design that hits one and misses the other does not survive a budget review.

Keep the vendors inside the architecture. At this scale, delivery runs through vendors, and vendors optimize for their own roadmap unless someone holds the line on security compliance and capacity planning. That line is an architect’s job, not a procurement function.

Protect momentum. A compressed delivery timeline across 6,500 locations leaves no room to stop and re-decide. Much of the work was keeping cross-functional teams aligned and moving while the organization above them changed shape.

The result

Architecture and headend designs were validated against the program’s projected $80M reduction in structural operating expense over its life. Program momentum and technical alignment held through the leadership transition, and architectural governance stayed intact across internal engineering, security, and vendor teams.

The hard part of a program this size is not the technology. It is keeping a decision made in month four still making sense in month thirty, after the people who made it have moved on.

Figures describe the program’s scope and projections as published in my public professional record, not outcomes I claim sole credit for. No client is named, and no architecture, topology, or vendor configuration detail is presented here.

Next: taking $85,000 a month out of telecom without taking anything away — the operations counterpart to this one.

The reasoning behind holding architecture through organizational change is set out at more length in Redundancy Is Not Resilience and on the leadership page.