<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>Software Architecture Insights</title>
  <subtitle>Architecture thinking you can actually use. Every Tuesday morning.</subtitle>
  <link href="https://softwarearchitectureinsights.com/feed.xml" rel="self" />
  <link href="https://softwarearchitectureinsights.com/" />
  <id>https://softwarearchitectureinsights.com/</id>
  <updated>2026-10-13T00:00:00-07:00</updated>
  <author><name>Lee Atchison</name></author>

  <entry>
    <title>Bolted On, Then Bolted Together</title>
    <link href="https://softwarearchitectureinsights.com/posts/bolted-on-then-bolted-together/" />
    <id>https://softwarearchitectureinsights.com/posts/bolted-on-then-bolted-together/</id>
    <published>2026-10-13T00:00:00-07:00</published>
    <updated>2026-10-13T00:00:00-07:00</updated>
    <author><name>Lee Atchison</name></author>
    <summary>The distributed monolith was the cloud-native failure that looked like success. AI already has its own catalog: the load-bearing prompt, the eval that tests the model instead of the system, RAG on a data model never meant to be retrieved from, the agent with tool access, and the special-case integration. Each one, and the check that finds it.
</summary>
  </entry>
  <entry>
    <title>You&#39;re at Level 2 and You Think You&#39;re at Level 4</title>
    <link href="https://softwarearchitectureinsights.com/posts/ai-native-maturity/" />
    <id>https://softwarearchitectureinsights.com/posts/ai-native-maturity/</id>
    <published>2026-10-06T00:00:00-07:00</published>
    <updated>2026-10-06T00:00:00-07:00</updated>
    <author><name>Lee Atchison</name></author>
    <summary>Five levels, from &quot;we added a chat feature&quot; to &quot;this is how we build now,&quot; each with an observable test instead of an adjective. Most organizations are two levels below where they believe they are, for the same reason they were on cloud maturity. The demo works, so the architecture must be fine.
</summary>
  </entry>
  <entry>
    <title>AI Didn&#39;t Break Your Risk Matrix. It Broke Your Scores.</title>
    <link href="https://softwarearchitectureinsights.com/posts/ai-didnt-break-your-risk-matrix/" />
    <id>https://softwarearchitectureinsights.com/posts/ai-didnt-break-your-risk-matrix/</id>
    <published>2026-09-29T00:00:00-07:00</published>
    <updated>2026-09-29T00:00:00-07:00</updated>
    <author><name>Lee Atchison</name></author>
    <summary>AI components belong on the same risk matrix as everything else. What changes is how you score them: a likelihood rubric built on how often a person meets the failure, and a severity rubric built from reach, reversibility, and detection lag.
</summary>
  </entry>
  <entry>
    <title>You Didn&#39;t Change Anything. It Changed Anyway.</title>
    <link href="https://softwarearchitectureinsights.com/posts/you-didnt-change-anything/" />
    <id>https://softwarearchitectureinsights.com/posts/you-didnt-change-anything/</id>
    <published>2026-09-22T00:00:00-07:00</published>
    <updated>2026-09-22T00:00:00-07:00</updated>
    <author><name>Lee Atchison</name></author>
    <summary>Services version on your schedule. Models drift, get deprecated, and improve on someone else&#39;s. Designing the boundary around a component you do not control, and the honest math on how much abstraction is worth paying for.
</summary>
  </entry>
  <entry>
    <title>The Model Isn&#39;t Wrong. Your Context Is.</title>
    <link href="https://softwarearchitectureinsights.com/posts/the-model-isnt-wrong/" />
    <id>https://softwarearchitectureinsights.com/posts/the-model-isnt-wrong/</id>
    <published>2026-09-15T00:00:00-07:00</published>
    <updated>2026-09-15T00:00:00-07:00</updated>
    <author><name>Lee Atchison</name></author>
    <summary>Retrieval, freshness, and data boundaries stop being back-office plumbing the moment a model depends on them. The context supply chain deserves the same rigor we learned to give service contracts, and it is where AI security actually lives.
</summary>
  </entry>
  <entry>
    <title>Your Function Call Was Free. This One Isn&#39;t.</title>
    <link href="https://softwarearchitectureinsights.com/posts/your-function-call-was-free/" />
    <id>https://softwarearchitectureinsights.com/posts/your-function-call-was-free/</id>
    <published>2026-09-08T00:00:00-07:00</published>
    <updated>2026-09-08T00:00:00-07:00</updated>
    <author><name>Lee Atchison</name></author>
    <summary>Distributed systems changed architecture because the network made a function call expensive. AI does it again, except the cost is money as well as latency. Model routing is an architectural decision, not an optimization you do later.
</summary>
  </entry>
  <entry>
    <title>It Passed the Test. That Doesn&#39;t Mean It Works.</title>
    <link href="https://softwarearchitectureinsights.com/posts/it-passed-the-test-that-doesn-t-mean-it-works/" />
    <id>https://softwarearchitectureinsights.com/posts/it-passed-the-test-that-doesn-t-mean-it-works/</id>
    <published>2026-09-01T00:00:00-07:00</published>
    <updated>2026-09-01T00:00:00-07:00</updated>
    <author><name>Lee Atchison</name></author>
    <summary>Every testing, monitoring, and reliability practice you own rests on one assumption: same input, same output. An LLM in the call path removes it. What replaces it is evaluation, thresholds, and verification as an explicit architectural layer with a cost and an owner.
</summary>
  </entry>
  <entry>
    <title>When Everything Is Critical, Nothing Is</title>
    <link href="https://softwarearchitectureinsights.com/posts/when-everything-is-critical-nothing-is/" />
    <id>https://softwarearchitectureinsights.com/posts/when-everything-is-critical-nothing-is/</id>
    <published>2026-08-25T00:00:00-07:00</published>
    <updated>2026-08-25T00:00:00-07:00</updated>
    <author><name>Lee Atchison</name></author>
    <summary>Reliability isn&#39;t only a technical property, it&#39;s an ownership property. Two decisions sit underneath every reliable system, what actually matters and who is accountable for keeping it up, and most organizations have made neither.
</summary>
  </entry>
  <entry>
    <title>What the EU AI Act Actually Requires (And What It Doesn&#39;t)</title>
    <link href="https://softwarearchitectureinsights.com/posts/what-the-eu-ai-act-actually-requires-and-what-it-doesn-t/" />
    <id>https://softwarearchitectureinsights.com/posts/what-the-eu-ai-act-actually-requires-and-what-it-doesn-t/</id>
    <published>2026-08-20T00:00:00-07:00</published>
    <updated>2026-08-20T00:00:00-07:00</updated>
    <author><name>Lee Atchison</name></author>
    <summary>The EU AI Act&#39;s reach extends to any company whose AI system&#39;s output is used by people in the EU, no European office required. A plain-language breakdown of the four risk tiers, what high-risk systems (hiring, credit, biometrics) must actually do, and what the Act does not require.
</summary>
  </entry>
  <entry>
    <title>Scalability Thinking Has a New Dimension</title>
    <link href="https://softwarearchitectureinsights.com/posts/scalability-thinking-has-a-new-dimension/" />
    <id>https://softwarearchitectureinsights.com/posts/scalability-thinking-has-a-new-dimension/</id>
    <published>2026-08-18T00:00:00-07:00</published>
    <updated>2026-08-18T00:00:00-07:00</updated>
    <author><name>Lee Atchison</name></author>
    <summary>AI coding assistants let teams move faster, but velocity changes the risk profile of an existing system. Boundary clarity, narrow contracts, and continuous architectural validation are what make a system evolvable at AI speed, not just human speed.
</summary>
  </entry>
  <entry>
    <title>The Difference Between AI Safety, AI Ethics, and AI Governance</title>
    <link href="https://softwarearchitectureinsights.com/posts/the-difference-between-ai-safety-ai-ethics-and-ai-governance/" />
    <id>https://softwarearchitectureinsights.com/posts/the-difference-between-ai-safety-ai-ethics-and-ai-governance/</id>
    <published>2026-08-13T00:00:00-07:00</published>
    <updated>2026-08-13T00:00:00-07:00</updated>
    <author><name>Lee Atchison</name></author>
    <summary>&quot;AI safety concerns&quot; means something different to engineering, legal, and the ethics lead — and that confusion wastes meetings. Safety asks what could go catastrophically wrong, ethics asks what we should do, and governance asks how we prove we did it. Three distinct disciplines, often mistaken for one.
</summary>
  </entry>
  <entry>
    <title>From Cloud-Native to AI-Native: The Next Evolution of Enterprise Architecture</title>
    <link href="https://softwarearchitectureinsights.com/posts/bolting-ai-onto-your-app-is-the-new-lift-and-shift/" />
    <id>https://softwarearchitectureinsights.com/posts/bolting-ai-onto-your-app-is-the-new-lift-and-shift/</id>
    <published>2026-08-11T00:00:00-07:00</published>
    <updated>2026-08-11T00:00:00-07:00</updated>
    <author><name>Lee Atchison</name></author>
    <summary>Every enterprise says it&#39;s adopting AI, the same way every enterprise once said it was in the cloud. Bolting AI features onto an existing system is the new lift-and-shift — the four-properties test for what genuinely AI-native architecture requires instead.
</summary>
  </entry>
  <entry>
    <title>Fairness in AI: Is Fairness Even Possible?</title>
    <link href="https://softwarearchitectureinsights.com/posts/fairness-in-ai-is-fairness-even-possible/" />
    <id>https://softwarearchitectureinsights.com/posts/fairness-in-ai-is-fairness-even-possible/</id>
    <published>2026-08-06T00:00:00-07:00</published>
    <updated>2026-08-06T00:00:00-07:00</updated>
    <author><name>Lee Atchison</name></author>
    <summary>There are at least six distinct, defensible definitions of AI fairness — demographic parity, equal opportunity, equalized odds, predictive parity, individual fairness, counterfactual fairness — and a proven mathematical result shows several are incompatible with each other. Every consequential AI system has already chosen one, whether the team meant to or not.
</summary>
  </entry>
  <entry>
    <title>Why &quot;The Algorithm Decided&quot; Is Never an Acceptable Answer</title>
    <link href="https://softwarearchitectureinsights.com/posts/why-the-algorithm-decided-is-never-an-acceptable-answer/" />
    <id>https://softwarearchitectureinsights.com/posts/why-the-algorithm-decided-is-never-an-acceptable-answer/</id>
    <published>2026-07-30T00:00:00-07:00</published>
    <updated>2026-07-30T00:00:00-07:00</updated>
    <author><name>Lee Atchison</name></author>
    <summary>&quot;The algorithm decided&quot; isn&#39;t an explanation — it&#39;s a way organizations dodge accountability for the human choices baked into a system. What accountability actually requires as an architecture: explainable decisions, genuine human authority, auditable logs, and a real escalation path.
</summary>
  </entry>
  <entry>
    <title>The Single-Architect Availability Problem</title>
    <link href="https://softwarearchitectureinsights.com/posts/the-single-architect-availability-problem/" />
    <id>https://softwarearchitectureinsights.com/posts/the-single-architect-availability-problem/</id>
    <published>2026-07-28T00:00:00-07:00</published>
    <updated>2026-07-28T00:00:00-07:00</updated>
    <author><name>Lee Atchison</name></author>
    <summary>Reliability engineering asks what happens when a component becomes unavailable. Most organizations never ask that about the person who holds all the architectural context — and the six-week test to find out if you have that single point of failure.
</summary>
  </entry>
  <entry>
    <title>The Five Ethical Risks Every AI System Carries</title>
    <link href="https://softwarearchitectureinsights.com/posts/the-five-ethical-risks-every-ai-system-carries/" />
    <id>https://softwarearchitectureinsights.com/posts/the-five-ethical-risks-every-ai-system-carries/</id>
    <published>2026-07-22T00:00:00-07:00</published>
    <updated>2026-07-22T00:00:00-07:00</updated>
    <author><name>Lee Atchison</name></author>
    <summary>Even a plain product recommendation engine carries all five structural ethical risks of AI: bias, opacity, accountability gaps, privacy exposure, and harm potential. They aren&#39;t specific to controversial applications — they come with the technology itself, and the only variable is how well a team manages them.
</summary>
  </entry>
  <entry>
    <title>The Lesson at the Heart of The Software Conductor</title>
    <link href="https://softwarearchitectureinsights.com/posts/the-lesson-at-the-heart-of-the-software-conductor/" />
    <id>https://softwarearchitectureinsights.com/posts/the-lesson-at-the-heart-of-the-software-conductor/</id>
    <published>2026-07-21T00:00:00-07:00</published>
    <updated>2026-07-21T00:00:00-07:00</updated>
    <author><name>Lee Atchison</name></author>
    <summary>A conductor who steps off the podium to play an instrument makes the ensemble worse, not better. The Hero Trap — architects jumping in to solve problems themselves instead of building their team&#39;s judgment — is the idea at the center of The Software Conductor, and the one that took longest to really land.
</summary>
  </entry>
  <entry>
    <title>What AI Ethics Actually Means for Engineers</title>
    <link href="https://softwarearchitectureinsights.com/posts/what-ai-ethics-actually-means-for-engineers/" />
    <id>https://softwarearchitectureinsights.com/posts/what-ai-ethics-actually-means-for-engineers/</id>
    <published>2026-07-14T00:00:00-07:00</published>
    <updated>2026-07-14T00:00:00-07:00</updated>
    <author><name>Lee Atchison</name></author>
    <summary>AI ethics gets used to mean three different things at once: philosophical principles, technical system properties, and governance. For engineers, the leverage is in the middle layer — the three zones (building, deploying, consuming AI) where fairness, accountability, and transparency are architectural properties you either build in or leave out.
</summary>
  </entry>
  <entry>
    <title>AI Closes the Ticket. But Who Builds the System?</title>
    <link href="https://softwarearchitectureinsights.com/posts/ai-closes-the-ticket-but-who-builds-the-system/" />
    <id>https://softwarearchitectureinsights.com/posts/ai-closes-the-ticket-but-who-builds-the-system/</id>
    <published>2026-07-07T00:00:00-07:00</published>
    <updated>2026-07-07T00:00:00-07:00</updated>
    <author><name>Lee Atchison</name></author>
    <summary>AI coding tools close tickets fast, but GitClear&#39;s 2026 research across 623 million code changes shows refactoring down 70% and duplicated code up 81% since 2023. AI doesn&#39;t make developers better — it amplifies the habits they already have.
</summary>
  </entry>
  <entry>
    <title>Your Architectural Style Is Part of Your Architecture</title>
    <link href="https://softwarearchitectureinsights.com/posts/your-architectural-style-is-part-of-your-architecture/" />
    <id>https://softwarearchitectureinsights.com/posts/your-architectural-style-is-part-of-your-architecture/</id>
    <published>2026-06-30T00:00:00-07:00</published>
    <updated>2026-06-30T00:00:00-07:00</updated>
    <author><name>Lee Atchison</name></author>
    <summary>Conway&#39;s Law says systems mirror communication structures. The less-discussed corollary: how an architect leads (centralized control vs. distributed judgment) shapes the coupling and evolvability of the system itself, not just the org chart.
</summary>
  </entry>
</feed>
