Software Architecture Insights

A plain language breakdown of what the regulation means for software teams building or deploying AI, even if you aren't in Europe. Your product manager has just heard about the EU AI Act. They send you a message: "We use AI in our product. Do we need to comply with this?" Maybe your legal team forwards a three page summary they don't fully understand. Maybe a customer in Germany asks whether your system is "EU AI Act compliant." Here's the honest answer: it depends on what your AI system...

The role of evolvability in modern application development. Your team adopted AI coding assistants four months ago. Output is up, and everyone is happy about it. Then last week someone shipped a change to the billing service that quietly broke an assumption three other services were making, and nobody caught it for nine days. Nothing about that change was careless. The system simply moved faster than anyone’s ability to remember what it was holding together. For most of the last decade, when...

Three terms that get used interchangeably, and that's a problem for practitioners. The VP of Engineering sends an email with the subject line "AI safety concerns." What exactly does that mean? The engineering team thinks it's about hallucination rates and failure modes. Legal thinks it's about regulatory exposure risks. The product ethics lead is certain it's about the recent bias tracking metrics. They all show up to the same meeting. All with different agendas. They all are wrong. Everyone...

Think back to the early cloud years. Every enterprise said they were “in the cloud.” What most of them meant was that they had taken the same monolith they’d been running in their data center and moved it onto rented virtual machines. Same architecture, same operational model, same failure modes. New invoice. We had a name for it. Lift-and-shift. And we spent the better part of a decade explaining why lift-and-shift was a starting point, and why the real value of the cloud came from something...

There are at least six distinct definitions of fairness, and most of them conflict with each other. Your team spent weeks tuning the hiring recommendation model. The product manager wants to know whether it's fair. You run the numbers. The model recommends candidates at roughly equal rates across demographic groups. Equal positive rates across the board. Seems fair. A month later, an auditor reviews the system. They're looking at something different. False positive rates. How often does the...

Accountability in AI driven decisions doesn't disappear because a model made the call. At some point in your career, you'll be asked to defend a decision your system made. Maybe a user was denied service. Maybe someone lost a job opportunity they thought they'd earned. Maybe the system flagged a transaction as fraud and the customer is furious. And someone in your organization will say, "Just tell them the algorithm made the decision." This is a moment worth pausing on. "The algorithm...

By: Lee Atchison Imagine you're doing a reliability review of a critical system. You're walking through the architecture, applying the standard single-point-of-failure test: what happens to this system if component X becomes unavailable? You find one. A database that three services depend on, with no replica. A message queue that sits in the path of every customer transaction. A third-party API call with no circuit breaker and no fallback. You document these items, prioritize them, and your...

Bias, opacity, accountability gaps, privacy exposure, and harm potential. Every AI system carries all five. You’re building a recommendation engine for a retail site. Nothing exotic. Not a criminal justice risk assessment, not a hiring algorithm, not facial recognition for law enforcement. Just product recommendations. Clean data, clear objective, straightforward deployment. It’s hard to imagine an AI ethics problem in there. And yet the system will encode bias from the purchasing patterns in...

By: Lee Atchison There's one idea in The Software Conductor that I keep coming back to, months after the book was finished. It's the one that took me the longest to really understand. It's easy to nod along with in the abstract. In practice, it costs something. It's the difference between conducting and playing. Not as a metaphor. As an actual description of what an architect's job is, and what it isn't. The Trap That Gets Almost Everyone A conductor doesn't play every instrument. That much...