Selected Work
A closer look at the work
The examples below show different sides of the same integration challenge: helping a system move forward while accounting for the environment, the people, and the products it needs to support. Some come from professional engineering efforts; others are architecture studies where I've been working through a design.
Helping a legacy product adopt a modern software supply chain
Engineering effort
Modernizing a delivery process means understanding what already works and what the product still depends on. In this effort, the product needed to retain its legacy development tools while adopting a more structured and traceable approach to builds and releases.
My work involves orchestrating that approach using OCI registries and ORAS for software supply-chain integration. It brings modern artifact practices to outputs from the existing build systems, including immutable digests, caching, release tags and configurations, signing, and attestations.
The customer conversations are an essential part of the work. Understanding which artifacts move between teams, what the final deliverable requires, and why each step exists helps me distinguish necessary requirements from the details of the current environment. That gives the modernization effort a useful starting point and keeps the design connected to the product it serves.
Bringing independent products into a larger system
Collaborative professional project
Each product in this effort had value on its own and could be deployed independently. The challenge was bringing products from different business areas together into a larger system while preserving that independence.
I contributed to a system-of-systems build and integration architecture using Kubernetes, Helm, Argo CD, and GitOps. Software supply-chain quality gates checked the minimum requirements for integration, with a feedback loop to help product teams understand what needed correction and how to address it.
The architecture was a shared effort across multiple organizations, regions, and engineering and business perspectives. Listening to those different needs was part of working out how the products could fit together and how their teams could participate in the integration.
Making GitLab provisioning easier to manage consistently
Architecture study and implementation roadmap
This study grew out of the need for a consistent way to provision groups, subgroups, projects, and permissions in a self-managed GitLab environment. It explores how infrastructure as code can give that work a repeatable structure and a clear change process.
The design direction uses OpenTofu/Terraform, reusable modules, and a centralized configuration repository. The roadmap connects provisioning with governance, CI/CD, module releases, and validation, while keeping decisions about state boundaries and lifecycle protection visible.
I kept the first phase focused on new resources, with existing-resource imports and broader team ownership left for later phases. That gives the initial implementation a manageable scope while preserving a route for the platform to develop.
