Senior Software Engineer and Architect

I solve the problems that do not fit neatly inside one service, team, or technology.

I design distributed systems, developer platforms, automation, and full-stack applications that remain understandable and maintainable as they grow.

My work replaces one-off fixes with reusable systems, reduces repetitive engineering effort, and gives teams a reliable foundation for future development.

Reusable event processing across a distributed systemMultiple event sources pass through a shared interface and reusable processing capability before services and downstream consumers use the result.01EVENT SOURCESAPPLICATION EVENTSDEVICE EVENTSPLATFORM EVENTS02SHARED EVENT INTERFACEstable integration boundary03REUSABLE PROCESSINGconsistent platform behavior04ASERVICE OUTPUTSmaintainable04BDOWNSTREAM USEsupportedVERIFICATION
A conceptual view: reusable platform behavior keeps individual services from solving the same distributed-systems concern independently.

Capability index

The domains and recurring problems behind my work across software, data, infrastructure, and operations.

Distributed Systems and Event Processing

Designing systems that remain resilient when events arrive asynchronously or out of order.

  • Event ordering
  • Consistency and maintainability
  • Kafka-based systems
  • Failure handling

Platform Engineering and Developer Tooling

Creating shared foundations that reduce repetitive work and make consistent engineering practices easier to maintain.

  • Maven parent POMs
  • Reusable Git templates
  • Build standards
  • Workflow automation

Software Architecture

Turning business requirements into technical designs that can evolve without forcing every component to change together.

  • System boundaries
  • Service decomposition
  • Integration design
  • Technical direction

Cloud and Infrastructure

Building secure environments spanning application code, containers, networks, deployment systems, and production infrastructure.

  • AWS EKS
  • Docker and Kubernetes
  • Network architecture
  • High availability

Healthcare Platform Engineering

Designing shared RTLS services that support healthcare workflows and reporting in event-driven environments.

  • RTLS services
  • Event-driven design
  • Shared processing
  • Reporting integration

Reliability and Maintainability

Designing systems around their full operating life rather than treating maintenance and production behavior as later concerns.

  • Reusable reliability patterns
  • Configuration drift
  • Operational visibility
  • Sustainable ownership

Selected work

Production systems, platform engineering, and independent R&D.

Production platform capability

Self-Correcting Event Processing

A reusable event-processing framework that improved resilience to asynchronous and out-of-order events and gave distributed services a consistent engineering approach.

Problem
Service-specific handling of common event-ordering concerns made the system harder to reason about, test, and maintain.
Role
Architecture, implementation, adoption, and developer guidance

Evidence

  • Improved resilience to asynchronous and out-of-order events.
  • Replaced service-specific solutions with a consistent engineering approach.
  • Made common event-ordering behavior easier to test and maintain.
  • Provided a reusable model and guidance for participating teams.
Examine the event-processing system
Production developer platform

Microservice Platform Standardization

Centralized Maven parent POMs and reusable Git templates reduced duplicated Spring Boot configuration and created a maintainable source of truth.

Problem
Shared dependencies and configuration files had drifted over time and lacked a reliable source of truth.
Role
Architecture, implementation, migration, and automation

Evidence

  • Centralized Maven parent POMs.
  • Created reusable Git templates.
  • Reduced dependency and configuration drift.
  • Simplified shared maintenance updates.
  • Moved existing services to the shared foundation incrementally.
Examine the platform foundation

A controlled environment in which AI development agents perform ticket-driven implementation through the same branch, pull-request, CI, and review workflow used by human developers.

Problem
Unrestricted code generation does not provide branch discipline, repeatable validation, source-control safety, review participation, or accountable human approval.
Role
Architecture, implementation, operations, workflow design, and ongoing research

Evidence

  • Agents implement ticketed work, validate it, commit, push, and open structured pull requests.
  • Git and Forgejo operations are limited to approved policy-enforcing commands.
  • Agents retrieve review comments, apply corrections, rerun checks, and request re-review.
  • The workflow is used across more than a dozen projects, including dozens of merged pull requests that built and improved the platform itself.
Examine the agent workflow
Production manufacturing system

Assembly-Line Control System

An end-to-end assembly-line control platform spanning physical equipment inputs, technician interfaces, application services, databases, reporting, virtualization, servers, and networks.

Problem
The legacy system required stabilization and replacement because unplanned downtime carried significant financial penalties.
Role
End-to-end architecture, development, infrastructure specification, installation, integration, and production support

Evidence

  • Designed the application, database, virtualization, server, and network infrastructure as one integrated operating environment.
  • Integrated automated guided carts, torque tools, and physical equipment inputs.
  • Implemented VMware infrastructure and high-availability network failover.
  • Diagnosed first-release database deadlocking and delivered a stable second implementation.
Examine the control system

How I approach complex systems

The technologies change. The recurring job is to find the real failure, replace repeated cases with a durable model, and leave the system easier to operate than it was before.

STEP 01

Understand the actual failure

The visible error is rarely the whole problem.

Trace behavior across services, data, infrastructure, workflows, and ownership boundaries before deciding what should change.

Engineering principles

Operating rules with concrete consequences, not a manifesto.

  1. Understand the actual failure before choosing the fix

    The visible symptom may be several boundaries away from the underlying problem.

    Practical consequence

    Trace behavior across services, events, data, infrastructure, and operational workflows before changing the system.

    Supporting example

    Out-of-order events appeared as different service bugs, but the durable solution belonged in shared platform behavior.

    Examine the practice
  2. Replace collections of special cases with a coherent model

    A new conditional for every incident makes the system harder to reason about.

    Practical consequence

    Identify the shared rule and move it into reusable behavior that can be tested, adopted, and maintained consistently.

    Supporting example

    The event-processing framework replaced service-specific fixes with one reusable reliability pattern.

    Examine the practice
  3. Build leverage into repeated engineering work

    Repeated manual work is often evidence that the platform is missing a tool or source of truth.

    Practical consequence

    Use shared configuration, generation, templates, and automation so future work becomes routine.

    Supporting example

    Centralized Maven parent POMs and reusable Git templates replaced repeated service-by-service setup with a shared foundation.

    Examine the practice
  4. Treat operation and maintenance as part of the architecture

    A system's real design includes deployment, failure, observability, recovery, security, and ownership.

    Practical consequence

    Evaluate how a system will be supported and changed before implementation is considered complete.

    Supporting example

    The manufacturing control system included application code, virtualization, network failover, equipment integration, and production support as one design.

    Examine the practice

Experience snapshot

Fourteen years of work across healthcare platforms, emergency management, manufacturing control, and medical-resupply applications.

  1. TeleTracking

    Software Engineer III

    Designed event-driven healthcare systems, shared RTLS processing and reporting services, reusable platform capabilities, and microservice standards. Provided technical direction and mentoring for teams of 4–10 engineers and served as a resource for complex architecture, production, data, and maintainability problems.

  2. BoldPlanning

    Software Architect

    Independently built the front end for a metadata-driven emergency-management document platform, developed supporting services and automated tests, and architected the AWS network environment.

  3. Calsonic Kansei

    Systems Engineer II / Systems Engineer III

    Promoted from Systems Engineer II to Systems Engineer III

    Stabilized a failing legacy assembly-line control environment and designed its replacement across industrial equipment, technician interfaces, application services, databases, reporting, virtualization, servers, and high-availability networks.

  4. American HomePatient

    Application Developer

    Modernized a medical-resupply order-entry application and related business systems across the Java, front-end, middle-tier, and Oracle data layers.

Let's talk

Need someone who can take ownership when the problem crosses every boundary?

Open to remote software engineering and architecture opportunities in the United States.