Welcome to the Blog

September 15, 2026

Welcome. I figured a good first post is just a proper introduction, since most of what follows here will assume you know a bit about where I'm coming from.

I'm Alan Matson, a network and security architect based in the Austin area. I've spent the last 15 years or so designing, securing, and running enterprise infrastructure — mostly in financial services and, more recently, state government, where I currently work as a network administrator for the Texas judicial court system. Before that I spent time at a credit union rebuilding their data center networking from the ground up, and before that doing professional services consulting for large enterprise and government clients.

If you looked at my resume, you already know the shape of it: MPLS WANs, BGP and VXLAN, Zero Trust and passwordless authentication, firewall governance across half a dozen vendors, SAN networking, compliance work tied to ISO 27001 and PCI. What the resume doesn't really capture is why any of that is interesting to me, or the hundred small decisions and dead ends that happen between "here's the requirement" and "here's the working system." That's really what this blog is for.

What I'll actually be writing about

Mostly practical stuff. Notes from real migrations and rebuilds — what worked, what I'd do differently, the tradeoffs nobody puts in the vendor's marketing deck. Things like moving a routing architecture from EIGRP to BGP with a VXLAN overlay without taking anything down, or what it actually takes to roll out passwordless MFA across an organization that's used passwords for twenty years. Some of it will be deep in the weeds of routing and firewall policy. Some of it will be higher-level thinking about Zero Trust, compliance, or how to make a case for a project to people who don't care about the technical details, only the risk and the cost.

I'll probably throw in the occasional video walkthrough too, for the stuff that's easier to show than to describe in text.

Why bother writing this down

Partly because I've learned a lot of this the hard way, and writing it out is a good way to make sure I actually understand it and not just remember it. Partly because when I was coming up in this field, the posts that helped me most weren't the polished vendor documentation — they were engineers writing honestly about a problem they actually had. If any of this is useful to someone else working through a similar problem, that's the whole point.

Thanks for stopping by. More soon.