Being able to systematically change the original architecture of a component-based system to a desired target architecture without changing the set of functional requirements of the system is a useful capability. It opens up the possibility of making the architecture of any system conform to a particular form or shape of our choosing. The Behavior Tree notation makes it possible to realize this capability by inserting action-inert bridge component-state. For example, we can convert typical network component architectures into normalized tree-like architectures which have significant advantages. We can also use this "architecture change" capability to keep the architecture of a system stable when changes are made in the functional requirements. The results in this paper build on earlier work for formalizing the process of building a system out of its requirements and formalizing the impact of requirements change on the design of a system.