The Work.

The methodology behind EAG wasn’t built in a boardroom. What follows is a selection of work from the career that built it — no client names, no logos. Just the shape of the problem and what happened.

Across five engagements — different industries, different environments, different constraints — the methodology didn’t change: understand what actually exists before recommending what replaces it. The five stories below are the evidence.

ENERGY RESELLER · EMERGENCY RESPONSE · ~150 USERS · MULTI-SITE · 2014

When Everything Goes Down at Once

The call came in around 6pm. All services down. A member of the client’s internal team had been mid-upgrade when the environment collapsed — his work wasn’t the cause, but the timing made the diagnosis harder. Nobody could agree on root cause. The clock was already running.

Two compounding problems revealed themselves during triage. The core switch had failed — and because the network was daisy-chained, that single failure cascaded outward and took everything with it. The second problem: switch configurations were inconsistent across all devices, with no reliable baseline documented anywhere. When the core went, there was no clean picture of what the network was supposed to look like to build back toward.

The replacement equipment had already been ordered. The planned upgrade was two weeks out. The core failure didn’t wait.

Four additional resources were brought in — network, compute, storage, application virtualization. The triage ran on parallel tracks simultaneously. Overnight: server interfaces and core network rebuilt from scratch. Next day: full Citrix VDI environment rebuilt. By morning production hours, the call center was operational.

A next-day team was coordinated so progress continued without a gap and the human element was covered.

Several of the engineers and leaders who were in the room that night still talk about it. It came up in conversations at other companies, with other teams, years later. Not because of what failed — because of what happened after the call came in.

Single point of failure identified and eliminated. Core network and full Citrix VDI environment rebuilt overnight. Call center operational by morning production hours.

MSP · MULTI-TENANT CLOUD ARCHITECTURE · HIPAA-SCOPE · BUILT 2012

The Architecture Nobody Had a Playbook For

The environment was flat. Segmented by VLANs and basic ACLs on Layer 3 switches, spread across multiple physical locations, with route overlap that made consistent policy enforcement nearly impossible. No order. No baseline. No path forward that anyone had documented — because at the time, nobody had published one.

The mandate: architect a multi-tenant environment that was redundant, flexible, secure, and scalable — capable of supporting 10 to 12 new client onboards per week, with HIPAA considerations baked into the design from the start. Build it around hardware that existed before virtual appliances were what they are today.

That meant solving for network segmentation, storage fabrics and data protection, ADC and load balancing, email security, public DNS, and DDoS mitigation — simultaneously, at scale, for clients who needed to log into their own slice of the environment and manage their own configurations without touching anyone else’s.

The work took 18 months. Change control windows, ISP provisioning delays, firmware bugs in chassis-based fabric modules that didn’t exist in any vendor documentation — because nobody had pushed the hardware this far yet. Solutions were built from first principles, tested under pressure, validated against requirements that kept evolving.

The design was built in 2012. The core architecture has been in production for over 13 years. Manufacturers eventually published their own guidance on how to build environments like this. The guidance looked familiar.

Multi-tenant architecture supporting HIPAA-compliant client isolation at scale. Core design in production 13+ years.

OIL AND GAS · M&A INTEGRATION · MULTIPLE ENGAGEMENTS

60 Days. No Margin for Error.

When a larger business consulting firm completes an acquisition in oil and gas, the operational and corporate integration is their domain. The infrastructure — the IT systems, the OT environment, the managed services stack the acquired company was running on — that’s a different problem. That’s where this work came in.

Sixty days. Every time.

These engagements required a specific kind of precision: data collection before a single architecture decision was made, a complete picture of what existed and why before anything moved. Which systems would convey. Which wouldn’t. Where the dependencies were. Where the risks were hiding. All of it documented and understood before a migration or integration plan was produced.

Then execution: alignment across multiple teams, no room for sequencing errors, no tolerance for surprises that hadn’t been anticipated in the planning phase. Cloud and professional services running in parallel, with a single lead across all phases.

Every date was hit. Every migration went as planned.

By the third engagement, the methodology was documented well enough to hand off. A trained lead ran it independently. The date was still hit.

Three M&A integrations delivered on 60-day deadlines. Zero missed dates. Methodology repeatable enough to train and hand off.

SECURITY · ASSESSMENT AND INCIDENT RESPONSE · MULTIPLE VERTICALS

When the Environment Is Already Compromised

Some engagements start before anything goes wrong. An organization wants to know where they actually stand — not what the last audit said, but what’s real. What’s exposed. What’s been missed. The assessment finds it. The remediation plan addresses it in order of actual risk, not audit priority. Biggest impact first, then fan out.

Other engagements start after something already happened.

The breach is a different conversation. The environment is already compromised, trust is already broken, and the first job isn’t remediation — it’s understanding exactly what happened, how far it went, and what’s still at risk right now. That requires someone who can read the environment without assumptions, follow the actual evidence, and tell the truth about what they find — even when the findings are inconvenient for the people who built what failed.

The pattern across both types of engagement is the same: honest assessment of what actually exists before any recommendation is made. No pre-sold solutions. No framework applied before the environment is understood. The design follows the diagnosis. Not the other way around.

Security assessments and post-incident response across enterprise and industrial environments. Findings delivered honestly. Remediation sequenced by actual risk.

DOD CONTRACTOR · INFRASTRUCTURE MODERNIZATION · ACTIVE ENGAGEMENT

When Compliance Isn’t Optional and the Gap Is Real

The client had recently signed. The compliance gap was already there — it just hadn’t been formally documented yet. Newer DoD requirements touched everything: network architecture, compute, storage, data protection, logging, and analytics. Nothing could be addressed in isolation because nothing existed in isolation.

The environment reflected years of different ownership — different generations of decisions, different standards, different priorities — all layered on top of each other in ways that made the gap harder to close than it looked on paper.

The partner handled the migration path into Azure Government Cloud. The focus here was the overall design and implementation of new infrastructure components — with NIST and FIPS compliance requirements shaping every decision from the start, not bolted on at the end.

The discovery process told the real story. Walking the facility, talking to IT management and leadership, you could see exactly where the generations changed and why the current state looked the way it did. That context matters. An architecture decision made without understanding the history of the environment it’s replacing is a guess dressed up as a plan.

Every design decision was explained to both leadership and the technical team — not just the what, but the why. When an organization has to pass a difficult audit, the people maintaining the environment need to understand the reasoning. Documentation and logging weren’t afterthoughts. They were requirements built into the design from day one.

Infrastructure modernization in active deployment. NIST/FIPS compliant network architecture live. Azure Government Cloud migration and remaining infrastructure in active deployment with ongoing Tier 4 support.

The Pattern

Five engagements. Five different environments. Five different sets of constraints.

The methodology was the same every time.

Take the environment apart. Understand what actually exists and why it exists that way before recommending what should replace it. Start with the biggest impact or the most urgent need. Tell the truth about what you find — to the technical team, to leadership, and to the client — even when it’s inconvenient.

Then build something that works the way the business needs it to work. And make sure the people who have to maintain it understand why it was built that way.

If you want to talk through a problem — even one you’re not sure is a problem yet — we’re genuinely interested. We like the conversation. We like the technical detail. We like the part where you describe something and we’ve seen exactly that pattern before.

That’s what The Triage Call is for.