About

Brian Taylor — principal software architect and systems engineer.

Twenty-five-plus years turning architectural uncertainty into practical, accountable decisions across enterprise integration, modernization, scalability and data processing, security and identity, and decentralized, resilient systems.

Resolving Architecture is the practice this work is done under.

Résumé Selected work

Experience

Senior architecture experience across complex technology environments.

25+ years

Principal-level experience across enterprise, solution, application, integration, security, data, platform, and product architecture.

US Navy nuclear

Former naval nuclear reactor operator and prior DoD Secret clearance holder; honorable discharge. Where the discipline for high-consequence systems started.

Background

The arc.

From naval reactors to software architecture

Brian began in the US Navy's Naval Nuclear Power Program, operating nuclear propulsion reactors aboard the USS Theodore Roosevelt and training junior operators. That environment — formal qualification, reactor-safety discipline, and consequences that are not theoretical — still shapes how he approaches systems.

Software development started during shore duty and became the career: architecture and delivery across fintech, healthcare, enterprise integration, retail modernization, national identity, education technology, and decentralized systems.

A through-line across that work is resilient, infrastructure-independent systems — including a long-running personal engineering project, 1M5, on serverless peer-to-peer communication that keeps working under denied or degraded network conditions.

Senior architecture background

More than 25 years across enterprise, solution, application, integration, security, data, platform, and product architecture — grounded in hands-on work in Java/Spring, Python, and Rust. Past work has included architecture evaluation, modernization planning, solution design, integration strategy, security and identity alignment, data architecture, scalability work, lightweight governance, and complex technology decision support.

View Brian Taylor on LinkedIn
View résumé (PDF)

Architecture decisions, not architecture theater

The focus is not producing documentation for its own sake. It is helping leaders and teams identify the decisions that matter, understand why a direction is chosen, preserve the rationale, and create implementation guidance that survives delivery pressure.

See selected work

Point of view

Architecture is the design decisions required to achieve stakeholder consensus.

Architecture becomes useful when it helps people decide. Diagrams, documents, standards, tools, and reviews can all help, but they are supporting mechanisms. The central work is clarifying what must be decided, why it matters, who owns the decision, and what trade-offs are accepted.

Good architecture work helps teams understand the landscape, make better decisions, preserve important context, and create accountable ownership for implementation — while the people responsible stay responsible.

Operating principles

Practical architecture without unnecessary process.

Start with the decision: define what must be decided before producing artifacts.
Make trade-offs visible: every meaningful architecture choice has consequences.
Respect current reality: target-state architecture only matters if the transition path is practical.
Preserve rationale: decisions lose value when teams forget why they were made.
Support implementation: architecture should guide engineering work, not sit apart from it.
Keep governance lightweight: use just enough structure to make decisions repeatable and accountable.

Research

Independent engineering projects, run alongside client work.

Meridian is a prototype I use to test one question: whether capturing architecture decisions and their rationale in a structured way actually helps teams hold onto architectural intent as AI generates more of the code — or is just more process.

1M5 is a long-running open-source project on resilient, infrastructure-independent communication. SEDA bus is a small, recurring one: the same minimal staged-message-system design built across four runtimes. Rickover brings casualty procedures and drills — naval-reactor operational discipline — to software operations. DID is decentralized, self-sovereign identity and key management — the identity layer 1M5 runs on.

Rickover draws directly on nine years operating naval nuclear reactors before the software career.

See the research

Contact

Start a conversation.

Open to conversations about senior architecture and engineering work, past projects and references, or the research.

Contact Résumé