写点什么

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

  • 2012-04-02
  • 本文字数:3441 字

    阅读完需:约 11 分钟

软件架构评估是软件架构生命周期中非常重要的部分。《软件架构评估:方法和案例研究》(《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 )关注我们,并与我们的编辑和其他读者朋友交流。

2012-04-02 00:003354
用户头像

发布了 52 篇内容, 共 22.0 次阅读, 收获喜欢 5 次。

关注

评论

发布
暂无评论
发现更多内容

直播倒计时|30分钟带你解锁“技术写作”新技能

有只小耳朵

技术 写作 直播 技术创作 RTC征文大赛

关于手机里的IP地址,你不得不知道的“秘密”

脑极体

windows平台python3使用impyla连接hive问题汇总

誓约·追光者

hive python3.x Windows 10

不想搞Java了,4年经验去面试10分钟结束,现在Java面试为何这么难

Java架构师迁哥

Spring Cloud 微服务实践(0) - 开篇闲话

xiaoboey

微服务 Spring Cloud Spring Boot Spring Framework

IP网络

菜鸟小sailor 🐕

python——dict常用方法

菜鸟小sailor 🐕

2020年7月云主机性能评测报告

博睿数据

云计算 测试 公有云 评测 排行榜

在线游戏,如何把握住1个亿以上的DAU?

博睿数据

运维 监控 AIOPS 系统 用户体验

为什么很多人不买iPhone?

北柯

甲方日常 16

句子

随笔杂谈

2020年8月北京BGP机房网络质量评测报告

博睿数据

测试 机房 评测 排行榜 IDC

算法大赛评委亲授通关秘籍,报名倒计时!

易观大数据

配置时间特性

小知识点

大数据 flink scal

一次压缩引发堆外内存过高的教训

AI乔治

Java kafka JVM

【高并发】面试官:Java中提供了synchronized,为什么还要提供Lock呢?

冰河

Java synchronized 同步 lock 锁机制

架构师训练营结业作业

superman

Python基础知识(二)

Python基础

食堂就餐卡系统设计

Geek_Albert

食堂就餐卡系统设计

LeetCode题解:622. 设计循环队列,使用数组,JavaScript,详细注释

Lee Chen

大前端 LeetCode

血的教训!千万别在生产使用这些 redis 指令

redis 学习 编程 程序员

Electronjs

Neil

Java 大前端 Electron 客户端开发

危与机并存 保险业如何走好线上线下业务并举转型之路?

博睿数据

运维 监控 保险 AIOPS 系统

Java 基础语法

InfoQ_34a83d636158

JDK15真的来了,一起来看看它的新特性

程序那些事

Java JDK15 JDK15新特性 java15新特性

如何进步神速

Sean

学习 个人成长

架构师训练营大作业

叮叮董董

Spring Cloud 微服务实践(2) - Gateway重试机制

xiaoboey

maven Spring Cloud Gateway modules 重试

网上赌博输了怎么办?上岸戒赌是唯一的选择

jdxj

网上赌博输了怎么办 网上赌博玩快三输了怎办 网上玩快三输了怎么回血 网赌输了怎么戒赌

UML练习1-食堂就餐卡系统设计

博古通今小虾米

UML

Spring Cloud 微服务实践(1) - 用Initializr初始化

xiaoboey

Spring Cloud Eureka Gateway Hoxton

瑞克•凯兹曼 谈软件架构评估_架构_Srini Penchikala_InfoQ精选文章