Architecture Change Management, in Phase H terms, is about monitoring and responding to change triggers. From where I sit, those triggers are not just technical. They also arrive as signals in an email thread --- a community coordinator who received a different link than last month, a charitable org that set up their Obsidian vault on our recommendation and now we have shifted the integration approach.
The architecture can evolve for good reasons. The question I keep coming back to is: who holds the relationship when it does? For a paid client you have a contract, a formalised process for communicating scope changes. For a community org who received free services, the contact is thinner. They might only hear from us when something breaks or when we proactively reach out.
That is where Phase H lands in my world. Change management is partly governance and versioning, but it is also about whether we have a comms pathway to the people we have already committed to. If we update a service and do not tell a volunteer coordinator in Northland who built their whole intake workflow on our setup --- that is a relationship break, not just a change log entry. The architecture board governance matters. So does knowing who to ring when something shifts.
Full doc here: https://cloud.nzrtnetwork.com/nextcloud/index.php/s/EPR3z8ynFKWyKJo
