我们一直在从开始的起点来讲架构，而如果我们对一个已经存在的系统而言，他的架构是什么呢？我们如何维护这样的系统？如何管理其演变以维护其架构为我们提供的质量属性？这里使用了一个新的名词，架构重构。架构重构是一种解释、交互和迭代的过程。重构并非自动进行的，需要的反向工程师和设计师具备相关技能并投入精力。重构这些元素，就需要应用反向映射。架构重构需要工具的支持，但任何一个工具或者工具集对进行架构重构都是不够的。从信息提取、数据库构造、视图融合到重构构成了软件架构的重构的活动。这些繁复工作源于架构的无形。而幸好，重构是有一定标准的。
在我们设计了架构，拿到了架构编档之后，我们怎么来知道架构满足了需求的？此处提出分析架构和评估架构的重要性。
作为本书的第三部分，分析架构自然是重要的一环。为了保证所有的努力都是值得的，要确保架构师满足需求的架构，需要在每个基于的开发方法中都应该进行架构评估。架构评估的基本问题，即原因、时间、成本、收益、技巧、计划内、计划外、前置条件和结果。
原因已经提过了，此处不再说明。
时间强调的是尽早评估，可以尽早修正，以确保其经济高效。
成本呢，也很好理解，是需要参加评估的人员所付出的时间。
对收益而言，过程较为复杂，但是也不是说不清的，进行架构审查，优点不用说大家都能明白。
而对于技巧，后面还有叙述，不先提，后面慢慢理解。
分出计划内与计划外，主要是因为问题的大小，计划外的评估师源于未曾预料的问题。
前置条件，很熟悉的一个名词了，不说了，概念相通。
此处开始讲述前面略去的分析部分，一种进行架构评估的综合方法——ATAM。确定好ATAM的参与人员，包括评估小组，项目决策者，架构涉众。ATAM的结果除了简单的文字说明，也有相应的敏感点和风险评估。ATAM分为四个阶段，分别是合作关系和准备、两个阶段的评估、后续写书面报告的阶段。重要的是中间的评估阶段!从商业动机表述和架构的表述开始、进行一系列的活动，对架构进行分类，生成质量属性效用树，分析架构方法，集中讨论并确定场景的优先级，最后对结果进行表述。