<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>How to Document Software Architecture on DBJ.METHOD</title><link>https://method.dbj.org/kb/architecture/documenting-architecture/index.html</link><description>Recent content in How to Document Software Architecture on DBJ.METHOD</description><generator>Hugo</generator><language>en-us</language><copyright>dbj.org · IP Advisory</copyright><atom:link href="https://method.dbj.org/kb/architecture/documenting-architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>Legacy Ways of Software Documenting</title><link>https://method.dbj.org/kb/architecture/documenting-architecture/legacy_ways_of_softwae_documenting.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://method.dbj.org/kb/architecture/documenting-architecture/legacy_ways_of_softwae_documenting.html</guid><description>Legacy software architecture documentation frameworks — C4, arc42, ADRs — and why they are insufficient without a governing ADM.</description></item></channel></rss>