本书主要描述软件架构与软件组织之间的相互关系，依次介绍了作者根据多年管理经验和研究总结出的软件架构组织的VRAPS 5项原则——构想(Vision)、节奏(Rhythm)、预见(Anticipation)、协作(Partnering)和简化(Simplification)，并通过案例分析、模式和反模式展示了如何运用这一模型。本书的主要读者为软件企业的管理人员、开发人员和软件产品的客户等，也可作为大学计算机及相关专业的本科生、研究生和教师的参考用书。

软件生产除了开发代码外还往往涉及到产品与相关组织整合的问题，而软件架构对于这两种活动都极其重要，如今更是如此。例如，一个普通的商业事务将穿越软件架构的许多层次，其中利用了各种共享平台，包括因特网、客户机浏览器、Web服务器、业务逻辑构件、安全系统和后台数据库，等等。在该环境中，众多的协作者不仅必须对采用哪些核心接口和标准集，而且还要对如何使用这些标准，达成一致意见。协作者还必须对他们的贡献所增加的价值或获得的回报拥有共识。所有这些共识必须在技术的快速更新、合作重组、业务目标和需求变化以及经常发生合并与收够的情况下保持并继续有效。一旦这些共识不复存在，所开发的产品及其架构将会失败，并给开发人员、客户、管理者和发起人(sponsor)带来不小的麻烦。
　　本书重点介绍了软件架构与组织的相互关系。软件架构作为一种框架，不仅仅定义并规范了开发和实现产品所必需的技术层面互动，而且还包括团体与个人之间的互动。软件架构长期实现这一角色的能力依赖于组织因素。
　　长期以来，人们注意到软件架构与创建并使用它们的组织结构之间是相互影响的，并深入研究揭示出它们之间广泛而复杂的关系。现实中的架构与目标结构往往大相径庭，它包含了大量隐藏的软件块、怪异的连接、硬编码的“捷径”、遗漏的部分以及其他非常的东西。同样令人吃惊的是一个组织的文化，包括成员、信念、能力和行为。实践中，架构与组织形成一个敏感、易变的矩阵。处理得当，组织和架构将会产生价值；而一旦处理不好，就有可能腐蚀掉企业的精华。
　　本书的目的是帮助那些对软件架构的成功拥有重要利益的人们理解、应对软件架构与组织所带来的双重挑战。这些受益人随着软件产品在开发和使用过程中跨越更多的组织边界而逐渐形成一个越来越大的独立团体，这一团体包括管理、开发、实现、维护、获得和使用软件架构的人们，其中的每一个人都能够通过更好地理解软件架构与组织的互动而受益。例如，协作技能可以帮助开发人员缩短找到软件架构或平台发布版本变更信息的时间，从而促进他们通过协商来恢复那些对于继续使用这一架构至关重要的软件特性。如果没有这些技能，软件架构师将很快失去其主顾；后者也不得不维护更多的代码，因而大大减少了可开发产品的数量。
　　本书的基础是我们在美国著名的大型软件开发机构和许多工作组中所从事的5年以上的研究，以及为各类大、中、小型单位设计产品线和实现软件架构的工作。此外，该书还吸收了我们在其他学科尤其是组织开发(organizational development)中的工作经验。我们的研究成果是一个影响软件架构成功的5项组织原则——构想(Vision)、节奏(Rhythm)、预见(Anticipation)、协作(Partnering)、简化(Simplification)，我们称其为VRAPS模型。
　　VRAPS原则提供了一种模型，可以利用它掌握该做些什么以提高你和公司从依赖于软件架构的产品和投资中获取长期价值的能力。VRAPS模型将帮助读者组织并理解个人的观察，并把它与其他人已经成功运用的实践方法和模式联系起来。读者还可以利用这一模型和原则识别长处与短处，交流思想，促进组织内外跨越角色、边界和层次的行动。
　　读者可以通过以下几条线索阅读本书：
　　首先通过第1章了解全书概貌，然后阅读第8章中Allaire公司的案例分析，了解该公司是如何运用VRAPS原则从一家小公司发展成为因特网应用开发工具领先供应商的。从第3—7章读者可以了解每一个VRAPS原则的更多内容。在定义、描述了这些原则之后，这些章节还提供了衡量标准以帮助读者评估在本单位运用这些原则的效果。模式、实例和反模式提供了实用的向导，告诉读者为了从这些原则受益该做些什么，不该做些什么。
　　从第2章中读者可以全面理解VRAPS模型及其外部联系。第9章介绍了如何在现实环境中运用该模型，提供了9种专门的模板、工具和向导，可以帮助读者评估自己单位的状况并与其他组织进行比较。此外，我们还介绍了在一次商业基准测试中这些模板是如何使用的。
　　最后，请往下阅读，并欢迎访问我们的Web站点：www．VRAPS．com。
　　David M．Dikel
　　David Kane
　　James R．Wilson

（美）David M.Dikel 等：暂无简介

张恂 等：暂无简介

与其他制造业一样，软件的生产也需要一流的生产设备、流水线和高素质的生产者与管理者；而作为高度智慧与知识的结晶，软件的生产又有着其独有的内在规律。
　　跨入21世纪，蓬勃发展的中国民族软件业正面临着前所未有的机遇和挑战。虽然在龙头企业的带领下中国软件业短短几年内获得了长足的进步，实力大增，但是国内软件产业的整体发展水平与美国、欧洲、印度等国家和地区相比仍明显落后，尤其在生产方式、过程控制、组织管理等领域差距更大。多年以来，与其他成熟行业(如建筑、制造业)相比，国内的软件生产和项目开发一直缺乏有效的工程化管理。
　　究其原因，译者认为根源在于不健全、不规范的市场环境造成软件产业链的资源分布不均衡。在急功近利、片面追求效益的行业风气影响下，国内软件工程的教育、技术和管理水平严重滞后并与软件生产实践相脱节，导致民族软件业长期在低水平上徘徊。与国外高度发达的软件工业化生产相比，我们的软件生产企业大部分还停留在手工作坊时代。这一瓶颈问题如不能得到根本解决，无疑将严重制约民族软件业健康和持续地发展。
　可喜的是，近两年来，许多软件企业和有识之士逐步认识到掌握软件生产规律、提升软件工程管理水平的重要性与迫切性。软件架构(Architecture)和框架(Framework)、CMM、统一软件过程(Unified Software Process)、UML、软件模式(Pattern)与反模式(Antipattern)、构件式开发(Component-Based Development)等先进的软件工程理论和方法开始被接受，其普及与应用正方兴未艾。在落后了国外3-5年甚至更长时间之后，人们终于意识到原来还可以这样做软件。
　　译者从事面向对象技术和软件工程咨询与管理工作多年，有幸接触了各类规模的软件生产企业，也结识了不少业界朋友。译者在与他们的交流切磋中了解到，中国软件企业面临的主要内部问题是管理问题，而不是技术问题，其关键是当代先进的软件生产技术如何与现代化的企业管理方法有机结合，这已经成为很多人的共识。
　　Ivar Jacobson大师在其里程碑著作《软件重用》(Software Reuse)[Jacobson 97](中文版由机械工业出版社出版)中指出，影响软件产品或项目成败的主要因素包括架构、过程和组织三个方面。其中，软件架构是决定软件产品内在质量的核心因素，合理的开发过程与高效的组织管理则是软件架构乃至软件产品、产品线成功的重要保障。
　　本书中所说的软件架构及其组织原则的适用范围既包括单一产品架构，又包括产品家庭或产品线上多个产品共享的架构；这里所谓的"组织"既包括一个项目组也包括一个部门、一个企业甚至有多个合作伙伴的联盟。本书的原则无论对于国内只做工程项目或单一产品的企业，还是拥有一个或多个产品线的组织都具有指导或借鉴意义。
　　同样以架构为中心，《软件重用》提出了面向重用的软件工程业务(RSEB)的概念，而本书则重点介绍与软件架构互动的组织管理原则，笔墨侧重于技术和人文管理的结合部分。译者认为这是此书的一大特色。
　　在国内我们一般只听说过程序员、高级程序员、系统分析员的认证考试，但很少听说软件架构师这样一个非常重要却易被人忽视的岗位。本书恰恰是专为软件架构师和软件企业的管理者(如高层经理、技术总监、产品经理、事业部经理、部门经理和项目经理等)写的，适合的读者还包括各类开发人员(实施者)、软件产品的客户等。
　　本书结构严谨，依次介绍了作者依据多年管理实践和研究经验总结出肋软件架构组织的VRAPS 5项原则(模型)，即构想(Vision)、节奏(Rhythm)、预见(Anticipation)、协作(Partnering)与简化(Simplification)。针对每项原则，每个主要章节都讨论了度量准则(Criteria)与指导实施的模式和反模式。
本书的价值在于体现了组织管理原则与软件生产技术的有机结合，用高度概括的VRAPS5项原则(含15个度量准则)、16种模式和17种反模式的形式，把宝贵的软件架构组织管理的真知灼见和经验教训系统地奉献给读者。　　
软件模式即解决软件领域常见问题的最佳方法，而反模式则是针对特定问题应该避免的错误做法，相应地就有软件分析、设计、实现和管理等各个方面的(反)模式。建立并全面有效地利用好模式知识库，是借鉴国外软件业成熟经验、重用其先进思想方法的一条捷径，可以大大加快提升国内软件企业工程管理和技术水平的过程。不久之前机械工业出版社华章分社曾经推出过一本软件设计模式的经典之作(《设计模式--可复用面向对象软件的基础》，ISBN7-111-07575-7)[Gamma94]，而本书很可能是国内第一本正式的有关软件管理模式的译著。
　　本书实例丰富，尤其详细分析了美国Allaire公司(其ColdFusion开发平台在国内有不少用户)、苹果公司、微软公司、著名的电信制造业巨人加拿大Nortel公司(Northern Telecom)以及美国国防部课题研究的一些案例。本书深入阐述了构想、受益人(Stakeholder)、迭代递增式开发(Iterative Incremental Development)等许多国内读者不甚理解的重要概念。相信通过阅读此书，读者一定会加深对这些先进软件工程思想和方法的认识。
　　原书的三位作者并非业界权威或名流。国内的管理者对于书中所介绍的某些概念和经验教训也许会有似曾相识的感觉，甚至可能认为这"没什么了不起的，平时我们就是这么做的嘛"。但是，能够把这些实践经验系统完整地记录下来并有序地组织成模式，从而将其升华为管理原则和方法论，这种职业精神和创造是难能可贵的。　　
　　相信此书的翻译出版，对促进国内软件从业人员掌握现代化软件生产与管理的内在规律和技术大有裨益，一定能引起广泛的共鸣。
　　非常感谢机械工业出版社华章分社的编辑们向我推荐了这样一本好书，同时也感谢我的家人、同事和朋友们(特别是郭永林和邵荣)给予我一贯的鼓励与支持，能使我顺利地完成这次翻译创作。
　　因时间仓促和水平局限，难免存在一些疏漏和差错，恳请各位读者批评指正。
　　E-mail:zhangxun2001@hotmail．com
　　张　恂
　　2002年2月于上海
　　译者简介　　　
　　张恂，1972年生。东南大学计算机软件硕士，国内某自主研发的分布式对象通信中间件的主要开发成员，曾在国内一家著名移动通信设备厂负责一个大型通信系统软件研发项目的管理近两年，后任某民营软件公司的CTO，目前主要从事软件工程和面向对象技术的咨询。

第1章　无形的帮助
1．1　本书主题
1．1. 1　软件架构愈显重要
1．1．2　对于某些人"他们是受益人"的消息来得太晚了
1．2　原则揭示本质
1．3　实践组织原则：架构师的新任务
1．3．1　节奏
1．3．2　构想
1．3．3　简化与预见
1．3．4　协作
1．4　VRAPS原则在Web领域中的应用
1．5　小结
第2章　VRAPS参考模型：各组成部分的关系
2．1　概述
2．1．1　模型的重要性
2．1．2　VRAFS模型
2．2　应用环境
2．3　软件架构的组织原则
2．4　概念框架
2．4．1　准则
2．4．2　模式
2．4．3　反模式
2．5　使用VRAPS模型
2．6　VRAPS模型演变过程
2．7　小结
第3章　形成并统一构想
3．1　概述
3．2　构想定义
3．2．1　把价值映射为架构约束
3．2．2　一致性与灵活性
3．3　构想挑战
3．3．1　架构师影响力的局限
3．3．2　高级经理与架构师的合作
3．3．3　产品线加剧了架构师和高级经理面临的挑战
3．3．4　识别构想的瓦解
3．4　形成构想
3．4．1　谁是真正的架构师
3．4．2　构想与领导
3．4．3　缺乏尊重
3．5　将构想原则付诸实践：准则、反模式与模式
3．5．1　准则1：架构师的构想与其发起人、用户和最终客户期望实现的目标保持一致
3．5．2　准则2：实施人员信任并使用架构
3．5．3　准则3：关于架构和构件的潜藏知识对其用户是可见的和可获得的
3. 6　小结
3．7　其他可用的模式与反模式
第4章　节奏：保证节拍、过程与进展
4．1　概述
4．2　节奏定义
4．3　动因
4．3．1　节奏帮助移交管理
4．3．2　节奏驱动活动完结
4．4　将节奏原则付诸实践：准则、反模式与模式
4．4．1　准则1：经理们定期地再评估、同步和调整架构
4．4．2　准则2：架构用户对架构发布的进度和内容具有高度的信心
4．4．3　准则3：通过节奏协调明确的活动
4．5　小结
4．6　其他可用的模式与反模式
第5章　预见：预测、验证与调整
5．1　概述
5．2　预见定义
5．2．1　预测
5．2．2　验证
5．2．3　调整
5．3　预见应用
5．3．1　朝多个方向发展架构
5．3．2　架构客户与他们的客户
5．3．3　目标离现实太远
5．3．4　目标离现实太近
5．3．5　平衡现在和未来的需求
5．3．6　掌握平衡
5．4　将预见原则付诸实践：准则、反模式与模式
5．4．1　准则1：不断增强架构的能力以响应预见到的风险和架构客户及其客户的需求；市场驱动的标准和演变的技术；战略性业务方向的改变
5．4．2　准则2：通过快速复审和开发周期，评估技术和业务上的风险与机会
5．4．3　准则3：当发现关键的估计或假设有错时，及时调整功能特性、预算、计划或进度
5．5　小结
5．6　其他可用的模式与反模式
第6章　协作：建立合作型组织
6．1　概述
6．2　协作定义
6．2．1　架构受益人
6．2．2　明确、合作的角色
6．2．3　价值最大化
6．3　产业基础
6．3．1　契约管理
6．3．2　网络化组织
6．3．3　价值链
6．3．4　信任
6. 4　将协作原则付诸实践：准则、反模式与模式
6．4．1　准则1：架构师不断地努力了解谁是最关键的受益人，他们如何贡献价值，以他们需要什么
6．4．2　准则2：受益人之间达成明确和强制性的契约
6．4．3　准则3：通过社会行为制度和非正式规范强化合作
6．5　小结
6．6　其他可用的模式与反模式
第7章　简化：澄清与最小化
7．1　概述
7．2　简化定义
7．2．1　Conway定律
7．2．2　澄清
7．2．3　最小化
7．3　将简化原则付诸实践：准则、反模式与模式
7．3．1　准则1：开发人员长期不断地使用架构，减少了总成本和复杂性
7．3．2　准则2：架构小组明确理解关键最小需求并且将其构造成多应用共享的核心元素
7．3．3　准则3：长期预算和行动确保当发生以下情况时把相关元素从核心移走：1)它们没有被共享或者增加了不必要的复杂性；2)有明确的业务理由
7．4　小结
7．5　其他可用的模式与反模式
第8章　原则实践：Allaire公司案例分析
8．1　简介
8．1．1　为什么选择Allaire公司
8．1．2　5项组织原则
8．1．3　我们采用的方法
8．1．4　关于结果
8．2　构想--把好的构想变成现实
8．2．1　定义和描述
8．2．2　形成架构构想并保持其生命力的实践方法
8．2．3　Allaire职员发现的警告信号
8．3　节奏--保持节拍
8．3．1　定义和描述
8．3．2　帮助一个架构组织保持同步的实践方法
8．3．3　Allair职员发现的警告信号
8．4　预见--预测、验证与调整
8．4．1　定义和描述
8．4．2　保持架构"与未来磨合"的实践方法
8．4．3　Allaire职员发现的警告信号
8．5　协作--生命线
8．5．1　定义和描述
8．5．2　支持协作的实践方法
8．5．3　Allaire职员发现的警告信号
8．6　简化--找到要素
8．6．1　定义和描述
8．6．2 支持简化的实践方法
8．6．3　Allaire职员发现的警告信号
8．7　小结
第9章　案例分析：用VRAPS建立和实现基准
9．1　概述
9．2　基准测试提供了一个框架
9．2．1　调查模板
9．2．2　组织背景与环境模板
9．2．3　架构概况与投资回报率模板
9．2．4　原则模板
9．2．5　实践方法模板
9．3　我们如何进行基准测试
9．3．1　获得一个可行的构想
9．3．2　进行访谈
9．4　基准测试结果与体会
9．4．1　原则共鸣
9．4．2　原则关系
9．4．3　几点体会
9．5　小结
附录A　快速参考表：原则、准则、反
模式与模式
附录B　反模式和模式一览
参考文献
索引