<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Data Architecture on Andrew Hunter — Systems Architect &amp; Builder</title>
    <link>https://andrewphunter.com/tags/data-architecture/</link>
    <description>Recent content in Data Architecture on Andrew Hunter — Systems Architect &amp; Builder</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Thu, 24 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://andrewphunter.com/tags/data-architecture/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Transformation Under Scale — Part IV: Write Authority</title>
      <link>https://andrewphunter.com/writing/write-authority/</link>
      <pubDate>Thu, 24 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://andrewphunter.com/writing/write-authority/</guid>
      <description>&lt;p&gt;Part III produced the enterprise estate: the operating model from Part II laid over what the systems actually run. The estate names an owner for each capability and shows what is written where. It does not yet draw the lines. An owner can be named for a capability whose data is written in five places, and naming the owner does not say which of the five is allowed to. Drawing that line is the first half of this essay. Moving it is the second.&lt;/p&gt;&#xA;&lt;p&gt;A boundary is not defined by who reads a fact, or by who acts on it. It is defined by who writes it. Reads fan out and actions fan out, and a healthy system has many of both. Writes do not. The unit of a boundary is a single fact and the single capability permitted to write it.&lt;/p&gt;&#xA;&lt;p&gt;A capability&amp;rsquo;s boundary is the set of facts it alone writes.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
