瑞克•凯兹曼 谈软件架构评估

软件架构评估是软件架构生命周期中非常重要的部分。《软件架构评估：方法和案例研究》（《Evaluating Software Architectures: Methods and Case Studies》）这本书涵盖了软件架构评估相关主题的细节，并针对多种不同架构的评估框架，如架构权衡分析方法 (ATAM)，软件架构分析方法 (SAAM)，中间设计的主动评审 (ARID) 等进行了阐述。作者还在书中讨论了一些相关应用的案例，并就此比较了各种软件架构评估方法。

InfoQ 就软件架构评估的意义以及如何在敏捷和精益软件开发组织中实施软件架构评估的话题，对上述书的合著者之一，卡耐基梅隆大学软件工程研究所的访问学者瑞克·凯兹曼做了访谈，并对这一领域的发展趋势进行了探讨。

InfoQ: 您当时写这本书的主要动机是什么呢？

瑞克·凯兹曼： 我们觉得需要有一本专注于架构评估的书。我们曾经写过很多文章，提出了很多方法，并且很多人开始去真正建立一些基于架构的方法。我们感觉，需要一本更加详实、专注于架构评估的书。同时也觉得这本书应该包括一些实质性的案例研究，因为这些年来这样的书实在是太少了。

InfoQ: 这本书的主要目标读者是哪些人?

瑞克： 软件架构师和有志于成为软件架构师的人，当然，包括项目经理在内的其他成员也可以通晓其流程原理，进而从中获益。

InfoQ: 您是否可以谈谈，如果想要将软件架构评估集成到软件产品开发的生命周期中，需要在哪些环节做相应的改变?

瑞克：这并不需要改变很多环节。自从开始写书以来，我们写了一些关于如何将以架构为中心的方法集成到统一过程和敏捷过程中去的专题。它们真的非常适合，你会愿意将它当作质量保证技术等任何成熟的软件开发方法论的一部分来执行。基本上，一旦你有了一个架构设计的概念，就应该在开始将资源投入实施前对其进行评估。从设计到实现总是有一个过程的。本书建议你在开始将主要的资源投入实施前对你的设计做些测试。

InfoQ: 在使用敏捷或精益软件开发过程的组织中如何进行软件架构评估？

瑞克： 对于这个问题，我可以给出两个答案。第一个是敏捷或精益软件开发过程仍然需要架构。敏捷开发的两个思想领袖：肯特·贝克（Kent Beck）和杰夫·萨瑟兰德（Jeff Sutherland）也是这么认为的。

这一方面没什么区别，另一方面，以敏捷和精益的精神来说，它们必定会在评估技术上进行裁剪以适应这种方法，从而在一个相对较小的团队内更加密切地工作。你不需要因此给你们的开发流程带来较大的干扰。

InfoQ: 相对传统的应用架构，在云计算或移动开发这样的新技术架构中进行架构评估会有何不同？

瑞克： 借用企业架构专家，约翰·扎卡曼（John Zachman）的一句话，“架构就是架构还是架构（architecture is architecture is architecture）。” 这意味着相同的原理也适用于企业架构，即使规模再大，也一样可以被认为是独立的系统或系统组件。SEI（即：卡耐基梅隆大学软件工程研究所）架构工作的最近 15 年的经验表明：领域和规模都无关紧要，架构就是架构。

InfoQ: 架构团队如何在组织中向高层管理团队呈现软件架构评估工作的效果?

瑞克： 架构团队可以做两件事来向管理层呈现评估的效果。首先是营销手段，你要让管理层明白你在做什么，为什么做，并且这么做可以带来什么收益。其次是技术手段，你可以通过展示一些硬性数据来衡量你正在做的工作。比如你在评估中发现了多少问题，并且由于这些问题的及时发现而为公司省下了多少钱。

举个例子，AT&T（美国电话电报公司）对他们的架构评估结果持续跟踪保持了 20 年。通过每个项目在其生命周期早期发现架构问题与较晚发现之间的比较，可计算出相应节省的资金，并据此向他们的主管提供相应的投资回报率（ROI）的估算。他们得到的数字是平均每个项目可因此节省大约 100 万美元【1】。

InfoQ: 有哪些软件架构评估的标准指标，可交付物或工件可以用来认识到实施评估带来的商业价值？

瑞克：一个主要并且非常明显的好处是架构评估可以暴露问题，如果这些问题未被发现，那么等到后期再去纠正，就要付出非常昂贵的代价。评估同样会催生出更好的架构。即使评估没有发现任何的问题，也会让每个人对目前的架构更有信心。

以下是其他一些软件架构评估带来的好处。其中有部分很难去衡量，但是它们都对创造成功的项目或更成熟的团队有所帮助。

1. 所有的利益相关者都齐聚一堂。 一次架构评估往往是所有利益相关首次齐聚一堂。这让每个人都参与到这个团队并可以为同一目标而努力：成功的系统。
2. 清晰的质量目标。在一次评估中，利益相关者们需要明确，一个成功的架构必须满足哪些特定的质量目标。这些目标提供了明确的质量标准，但常常未记录在需求文档中。
3. 冲突目标的优先级。 团队针对利益相关者之间关于目标的冲突给予表述，并作好相应的优先级安排。
4. 对架构进行明确解释。 那些还不了解架构的人将有机会得到架构师的帮助以了解架构的细节。
5. 改进架构文档的质量。 如果评估需要文档，项目将因此而受益，因为这为它进入开发做了更好的准备。
6. 发现跨项目复用的机会。 因为一些利益相关者和评估小组都来自开发项目之外。他们所在的位置正好能发现目前项目的组件可以被其他的项目复用，或知道某些组件已经存在，只需导入到当前的项目即可。
7. 促进改进的架构实践。如果某组织将实践架构评估纳入他们开发流程的标准部分，那以后他们会看到更好的架构，而不仅仅限于此次。随着时间的推移，这些组织将自然而然的为执行评估赋予更加重要的定位，并发展出一种文化，促进更好的架构设计。

InfoQ: 您能谈谈架构师在实施软件架构评估时，需要考虑哪些问题，以及有哪些最佳实践？

瑞克： 你需要在评估架构前做好相关的架构文档。

并且还需要具备一些架构评估的必需条件。举个例子，你必须邀请到正确的利益相关者在场。同样重要的是需要一位训练有素的主持人在会议中控制好时间，保证每个人都专注于评估。总之，你需要通过所有利益相关者来保证提高架构的质量。

InfoQ: 在很多组织中，一个非常关键的问题是需要确认，在软件架构模型中是否合适地论述了要满足安全性以及需求的要求。如何在指导软件架构评估中论述安全问题？

瑞克： 确认是否满足安全性和需求的要求与其他架构问题并无差异。如果有需要，可以将此问题作为一种架构解决方案论述，你需要捕捉这个问题的场景，具备明确的刺激条件与对应响应，并利用这个场景来指导调研和分析架构的过程。

InfoQ: 在这个领域中有什么新的发展趋势吗?

瑞克：我清楚地看到了一个更加边缘化发展的趋势（a trend towards more edge development）。如果你考虑应用平台，比如 iPhone 或 Android，架构事实上已经分成两个部分。你需要理解这个平台本身的架构，还要理解了在这个基础设施上编写的应用的架构。它也对评估活动进行了拆分，而你将在相应的生命周期中做好评估。

我们也发现有一些工具可以提供支持。最近几年中有很多反向工程和分析工具如雨后春笋般涌现出来。这是我们九年前写这本书时所未曾见到的。

人们也开始寻找方式，让架构更多的融入到大学课程中，相比 10 年前，这将会造就更多精通架构语言的人。

关于本书作者

瑞克•凯兹曼（Rick Kazman） 是夏威夷大学的教授，同时也是卡耐基梅隆大学软件工程研究所的访问学者（同时是前资深技术员）。他主要的研究方向是软件架构，设计和分析工具，软件可视化以及软件工程经济学，同时也对人机交互和信息检索很感兴趣。凯兹曼创建了多个具有高影响力的架构分析的方法和工具，包括 SAAM (软件架构分析方法)，ATAM (架构权衡分析方法) 以及 Dali 反向工程工具。他撰写了超过 100 篇论文，也是多本书的合著者，包括《软件架构实践》（Software Architecture in Practice）和《软件架构评估：方法和案例研究》（Evaluating Software Architectures: Methods and Case Studies）。

关于译者

赵震一 5 年软件开发经验，创业者，关注电子商务与互联网，对 Java 平台及服务器后端技术较感兴趣。新浪微博： @Emerson_ 赵震一

参考信息

[1] Architecture Reviews: Practice and Experience IEEE Software, March/April 2005 (vol. 22 no. 2) pp. 34-43 Joseph F. Maranzano, Millennium Services Sandra A. Rozsypal, Lucent Technologies Gus H. Zimmerman, Lucent Technologies Guy W. Warnken, AT&T Labs Patricia E. Wirth, AT&T Labs David M. Weiss, Avaya Labs

查看英文原文： Rick Kazman on Evaluating Software Architectures

感谢侯伯薇对本文的审校

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。