<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Software Architecture on Arrans Technical blog</title><link>https://arran4.github.io/blog/categories/software-architecture/</link><description>Recent content in Software Architecture on Arrans Technical blog</description><generator>Hugo -- gohugo.io</generator><language>en</language><managingEditor>technicalblog123@arran4.com (Arran Ubels)</managingEditor><webMaster>technicalblog123@arran4.com (Arran Ubels)</webMaster><copyright>Arran Ubels. This work is licensed under a &lt;a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License&lt;/a>.</copyright><lastBuildDate>Tue, 15 Sep 2026 17:35:48 +1000</lastBuildDate><atom:link href="https://arran4.github.io/blog/categories/software-architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>Scenarios as Executable Application State</title><link>https://arran4.github.io/blog/post/2026/046-scenarios-as-executable-application-state/</link><pubDate>Tue, 15 Sep 2026 17:35:48 +1000</pubDate><author>technicalblog123@arran4.com (Arran Ubels)</author><guid>https://arran4.github.io/blog/post/2026/046-scenarios-as-executable-application-state/</guid><description>There is a recurring problem in application development that tends to acquire a collection of unrelated solutions.
Tests need data. Developers need a populated application to work against. Demonstrations need a recognisable set of users and content. Screenshots need a known visual state. Bug reports need a reproducible situation. Continuous integration sometimes needs to run the application against something more interesting than an empty database. An LLM working on a user interface needs to be able to create exactly the state it is trying to inspect.</description></item></channel></rss>