<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Enterprise Architecture on Andrew Hunter — Systems, Architecture, and Engineering Governance</title>
    <link>https://andrewphunter.com/tags/enterprise-architecture/</link>
    <description>Recent content in Enterprise Architecture on Andrew Hunter — Systems, Architecture, and Engineering Governance</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 24 Aug 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://andrewphunter.com/tags/enterprise-architecture/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Transformation Under Scale — Part I: Constrain the Possible, Not the Ideal</title>
      <link>https://andrewphunter.com/applications/constrain-the-possible-not-the-ideal/</link>
      <pubDate>Mon, 24 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://andrewphunter.com/applications/constrain-the-possible-not-the-ideal/</guid>
      <description>&lt;!--&#xA;DRAFT prose. draft: true until reviewed. Voice = locked article standard (memory `article-voice`):&#xA;impersonal-authoritative, author as judge, light strategic &#34;I&#34; only at the intro turn and the close.&#xA;Running example is PRINCIPLE 2 (Simple Customer Experience / Composable Platform): the objective forced&#xA;DDD over bloated SOA and pure microservices, and set TM Forum Open APIs as the one consumer contract.&#xA;The catalog / state-authority / projection-test material moved OUT to essay 4 (Boundaries).&#xA;&#34;Architecture is practiced constraint&#34; stays PLAIN TEXT, no cross-link to the theory corpus (different&#xA;ontological layer). Date is a placeholder.&#xA;--&gt;&#xA;&lt;p&gt;When a transformation begins, the instinct is to draw the target: a clean picture of the system as it should be, planned backward from. Over an existing estate, that is the wrong first move.&lt;/p&gt;&#xA;&lt;p&gt;You do not design the ideal system. You constrain the possible one, and the constraints come from what the company is trying to do, not from taste. Each objective, taken seriously, becomes a constraint that rules some designs out.&lt;/p&gt;&#xA;&lt;p&gt;That is what I mean by architecture as practiced constraint. A transformation is that practice at estate scale: a set of limits drawn from the company&amp;rsquo;s objectives and held over the estate you have, not a picture to build toward. Get the limits right and the program follows from them. Reach for a picture and you spend three years learning it was a wish.&lt;/p&gt;&#xA;&lt;p&gt;The examples in this series come from one program: an architecture-led transformation at a national wireless carrier serving millions of subscribers, on a fifteen-year estate that had grown without a central architecture function. Everything concrete is genericized, but the decisions are real.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
