从企业会计资料的编制，到传统的财务分析，如净利润、净资产、ROE（净 资产回报率）等财务指标，人们更多的都是从股权投资人的角度出发去汇总资料和分析企业。这也符合人们一般的思维逻辑，因为股东毕竟是企业的所有者和控制 人。但企业实际运用的资金规模与股东投资的数量并不完全对等，企业经营的本质是运用所有投入资本去获取收益，然后对收益按照不同资金的类型进行分配，股东 的资金以及股东获得的收益都只不过是其中的一个重要组成部分。想要了解企业真正的经营绩效，就必须复原企业所运用资金的真实规模以及归属于这些资金的收益 状况。估值分析必须回到企业创造收益的源头，无论是对于投资还是收益，企业的归于企业，股东的归于股东。

一般情况下，除股东投入的资金外，企业运用的资金还包括债权投资，在财务报表上表现为付息债务。以及少数股东投资，即企业合并报表子公司中其他股东的投资数额。股东权益、付息债务以及少数股东权益构成了企业运用的全部资金，称为企业的投资资本（IC）。企业运用投资资本于正常的生产经营就形成了各项资产要素，包括固定资产、无形资产、营运资本等。因此在具体估值分析中，投资资本既可以从资本来源的角度，也可以从资本应用的角度来计算，两种方法的结论完全相同。

需要特别注意的是，一定要区分投资资本和总资产的差别，这是两个经常被混淆的概念。投资资本指所有投资人投入的资金总和，这些资金都是意图分享企业经营回 报的。投资资本与总资产的核心差别在于投资资本中不包括无息流动负债，因此投资资本等于从总资产或者负债和所有者权益的基础上扣除无息流动负债后的余额。 无息流动负债在资产负债表中主要表现为应付帐款、应付工资、其他应付等，在具体操作中可以通过流动负债总额扣除其中的付息流动负债，包括短期借款和一年到 期的长期负债来计算。这种差别的原因在于，虽然无息流动负债也是企业对其他方资金的一种占用，但这部分资金并不来自于投资人，这种资金占用只是企业正常经 营活动中的一个必要环节。流动资产与无息流动负债的差额显示了企业需要投入的用于流转的资金数额，称为营运资本。也就是说，总资产增加的一个可能原因是企 业更多的占用了其他方的资金，而投资资本的增加则一定意味着投资人追加了新的投资。

确定了企业运用资金的规模，接下来就需要分析企业运用这些资金所取得的绩效。在本系列的第三篇《清扫财务报表》中曾经介绍过EBIT的概念，即息税前盈利，它衡量的是企业所有投资人所获得的税前利润，扣除在此口径下应缴纳的所得税便形成了所有投资人所获得的税后利润，即NOPLAT，称为息前税后营业利润。就如同净利润是和净资产对应的概念，NOPLAT是一个和投资资本对应的概念，它反映了投资资本的税后收益。

NOPLAT也 可以从利润分配的角度去理解和计算。既然是所有投资人所获得的税后收益，它自然也就等于各类投资人所获得收益的总和。股东获得的是净利润，少数股东获得了 少数股东损益，债权投资人获得的是利息收入，对企业而言是财务费用。由于财务费用对企业有抵扣所得税的功能，所以企业的真实债权成本是扣除税收抵扣部分的 财务费用，也称为税收调整后的财务费用。因此从利润分配角度计算的NOPLAT就等于净利润、少数股东损益和税收调整后的财务费用之和。

通过以上分析，可以清晰的梳理出一个企业的整体脉络（见图），即三类投资人以不同的方式共同投资于一个企业，资本总和构成了企业的投资资本（IC），所有投资资本获得的收益为NOPLAT，并对三类投资人进行分配。投资资本衡量了企业所运用的经济资源的规模，NOPLAT则反映了企业真正的经营绩效。虽然新会计准则要求将少数股东权益和少数股东损益分别在所有者权益和净利润科目内披露，但这仅仅是披露方式的变化，对上述分析没有任何实质性的影响。

图：企业资本来源及收益分配

通过投资资本和NOPLAT，可以计算出ROIC，即NOPLAT/投资资本，它反映了企业的投资资本收益率。在估值分析中，ROIC比ROE更 经常使用，因为它反映的是企业完全的经营效率，在不同企业之间的比较也更为合理。对于投资、规模、产量、收入等完全相同的两个企业，如果二者之间的唯一差 别就在于它们的资本结构，即一个企业有银行借款，而另一个企业全部是股东投资。对双方的管理层来说，都在运用相同规模的资金，获得了相同的销售收入，并发 生着相同的生产经营成本，二者的生产经营没有任何差别，两个企业具有完全相同的ROIC。而由于银行借款及产生的财务费用会使运用财务杠杆的企业净利润较低，而正常情况下，它的ROE会较高。不难看出，净利润、ROE等以股东为核心的财务指标无法区分企业的生产经营绩效和财务杠杆的运用绩效，而这两种绩效的影响因素和可能的改善路径则完全不同。想要对企业的价值有更深入细致的分析，就必须对上述因素进行分解。

投资资本、NOPLAT以及ROIC，还原了企业真正的资金运用、收益水平和收益率，有利于分析人员更清晰的把握企业真实的运营状况，同时，对ROIC指标的分解还可以拆析出推动企业价值增长的核心驱动要素，以利于企业做出生产经营方面的改进和调整。

作者，郑伟征，发表于《中国证券报》企业估值专栏

长期以来，人们在投资活动的实践中总结出了十多种常用的估值方法，其中既有我们熟悉的PE法，也有目前在国内还没有得到普遍应用的EV/EBITDA法、PEG法等等。既有有着严格金融理论作为基础的DCF法， 也有实践中进行粗略估算的简便方法。各种估值方法之间并没有绝对的好坏之分，每种方法的产生都基于特定的投资思维，思维方式的差异决定着各类方法的使用条 件、发挥领域、内在局限以及方法使用者对相应估值结论的应用和解释。因此理解方法背后的投资思维是理解不同估值方法进而合理应用这些方法的前提。按照思维 方式，可以将估值方法大体分为四类：即可比法、现金流贴现法、行业粗算法以及账面值法。

其中，可比法可能是大家最熟悉和最常用的一类估值方法，也称为相对估价法。正如其名称所揭示的那样，可比法最基本的投资思维是寻找参照物，即可比公司。然 后通过市场已经对参照物形成的价格水平来判断目标投资应该具有的价格区间。目标投资与参照物之间的比对关系通过价格与核心要素的比例来体现，不同可比方法 之间的区别只是在于对核心要素的不同选择。

以PE法为例，其内含假设是预期净利润是股票价格的核心驱动要素，因而也就产生了PE的概念，即股票价格与预期净利润的比例，类似的公司将被认定具有类似的PE水平。例如当分析员运用PE法确定平煤天安（601666）的股票价值时，首先要寻找与该公司质地类似的投资。通过对行业类别、企业规模、煤炭储量等各种指标的对比，确定西煤煤电（000983）和国阳新能（600348）作为目标投资的价值参照物，也就是认为平煤天安应该具有和这两家公司近似的估值水平。即通过这两家公司的PE水平可以确定平煤天安的合理PE， 乘以平煤天安的预测下一年净利润就可以计算出对其股权的估值结果。显然，参照物是理解和使用可比法的关键，参照物的选择、参照物本身的估值合理性等都直接 影响着可比法的使用效果。如果选择的参照物缺乏参照意义，或者核心要素不能体现参照物与目标投资之间的比对关系，或者参照物本身的价格并不合理，那么可比 法的使用也就失去了其本来的效能。

与可比法相比，现金流量贴现法基于更为严密的金融理论，其具体应用也比可比法要复杂很多。现金流量贴现法的基本投资思维是直接估算投资的未来收益与风险水 平，通过对二者的权衡来判断投资的价值。其中自由现金流量代表了对公司未来收益水平的估计，而贴现率则反映了对投资潜在风险水平的判断，投资存续期间的所 有收益按照风险水平折算的现值就是该项投资当前的投资价值。和其他估值方法相比，现金流量贴现法最严格地遵循了价值评估的基本理念，因此也是理论上最严密 的估值方法。

对现金流的贴现很容易理解，也很容易计算。如果一个公司第五年能产生100万的公司自由现金流，该现金流的潜在风险水平为10％，则该部分收益对公司当前价值的贡献就100万按照10％贴现五年，为62万 元。所以现金流贴现法的应用重点更在于对自由现金流量以及贴现率的考察，对二者的计算过程更强调对投资产生收益的内在逻辑以及潜在风险的理解和分析。对于 可比法和现金流量贴现法我们还将在本系列的其他专题中深入探讨。除这两种方法之外，行业粗算法和账面值法也在一些特殊情况下被应用于企业估值。

在投资银行领域，当人们需要在最短的时间内对某项投资的价值区间做出一个粗略估计的时候，经常运用到的方法就是行业粗算法。所谓行业粗算就是根据行业内特 有经济技术指标对企业价值进行粗略估算的方法。例如，对火力发电企业来说，装机容量一般标志着企业的规模和收入水平，因此人们通常使用这一指标对行业内企 业的价值进行粗算。假设行业内普遍认可的价格与装机容量的比例是4500元/千瓦，那么一个装机容量为10万千瓦的电厂其价值估计应该在4.5亿 元左右。互联网行业通常采用的以点击率估算企业价值，以及石油行业以储量估算企业价值的方法都属于行业粗算法。行业粗算法的思维逻辑是行业中具有一个压倒 一切的核心价值决定要素，该要素能基本确定该投资的价值区间。正是这样的投资思维也决定了这种方法只适用于简单的初步计算，以上例来说，电厂的煤耗、煤炭 成本、电价水平都是影响该电厂价值的重要因素，在这方面行业粗算法就无能为力了。此外，值得注意的是，行业粗算法估算的结论都是企业价值，而想要得到权益 价值还需要对债权进行调整。

最后一类估值方法是账面值法，也就是使用资产的账面价值作为其价格的参照。一般来说，资产的账面价值基本上按照资产的历史成本扣减以该历史成本折算的损耗 来确定。虽然这种方法在国有资产体系内还仍作为一个通行的标准使用，但由于资产的价值并不取决于历史，而是取决于未来的收益，因此在具体的估值实践中账面 值法的使用范围非常狭小，只是在上述方法均失效的情况下才使用，或者作为其他方法估值结果的一个辅助参照指标。

本篇发表于《中国证券报》企业估值专栏

　　就像人们对自然、经济等诸多领域 内在规律的认识不断深入一样，在市场经济存续的上百年中，人们对投资规律的认识也在不断加深和成熟，并逐渐形成了一套完善的对投资价值进行评估的方法，就 是我们一般所说的价值评估方法。鉴于投资本质的一致性，估值方法在市场经济环境下也具有普遍的适用性。作为新兴的市场经济国家，中国投资活动的规模越来越 庞大，投资的复杂性不断提高，引入国际成熟的价值评估方法正当其时。

　　在实践中，各种投资估值方法在专 业投资管理机构中的使用已经非常普遍，但由于缺乏对估值方法背后各种理念和思想的深入理解，估值方法的错误使用也随处可见。从目前的状况来看，估值方法在 中国的应用时常陷入两个极端，一端蒙盖着高深莫测的面纱，神秘而遥远，似乎只有某些大师才可能洞悉和掌握。一端是随意的滥用，似乎所谓估值就是如此简单， 可以直接放之四海而解决所有问题。所有这些都严重地损害着价值评估方法在中国的普及和应用。实际上，与其他所有的理论和方法一样，价值评估的每一种方法都 有其特定的适用范围和使用条件，既没有那么高深，也没有那么随意，它是投资分析人员对话的基础和工具。随着中国资本市场的成熟和开放，投资语言的一致性对 于投资分析人员的国内沟通和国际交流都越来越重要。同一个世界运用的本就应该是同一套方法，各种方法对应的是对投资价值的理解和具体的应用准则。

　　所有估值方法的核心思想都是对投 资收益和投资风险进行度量和比较，从而确定投资的价值以及影响投资价值的主要因素，以起到对投资决策的指导作用。在人们具体的投资决策中也总是在自觉的追 求着二者的平衡。面对收益稳定且风险较小的水电投资时，较低的回报水平就足以让人趋之若鹜，而当人们投资于制造业等风险相对较高的行业时，人们要求的回报 也水涨船高。因此高收益并不一定意味着高价值，这还取决于获取这个收益所承担的风险。因此无论采用哪种价值评估方法，它都必然要包含两个方面：对未来收益 进行估计和对面临的风险进行判断，这也是我们理解投资估值方法的基点。

　　然而无论是收益还是风险，都是未 来的事情，对于未来，任何人都没有先知先觉的能力，所以虽然各种估值方法的运用经常以复杂数学模型的形式出现，但这些都不能改变估计的本质，在这种复杂形 式的背后是分析人员对于影响价值的各种参数的主观判断，不同的人对于同一项投资采用同样的方法也会有不同的价值判断，同一个人在不同的环境下对同一项投资 的判断也会发生改变。因此，价值评估无论怎样以客观的形式出现，其结论都必然是主观的。正确的方法是合理价值判断的基础，但还远不是它的全部。估值方法从 它的全部意义上来说也只能是我们对投资价值进行评估的工具，方法本身不可能取代判断成为我们投资的全部依靠。

　　估值方法的意义不仅可以将我们的 各种假设最终形成一个可供判断的价值估计，它更为核心的作用是对投资的深入分析。完整而严密的评估过程可以协助我们分析和了解投资为什么拥有这样的价值、 驱动投资价值的最为核心的因素是什么、改变哪些因素将提升投资的价值等一系列重要问题。对于一个企业，是否应该增加债务比例、运营的重点是扩大销售规模还 是降低生产成本、应该实施多元化投资战略还是将非主营业务的资产进行出售、是应该更新生产设备还是让原有的设备继续发挥作用，所有这些都没有一个排他性的 绝对正确答案，对与错都在运用估值方法而进行的价值分析的过程中。由于估值结论会随着假设的变化而不断调整，因此比结论更为重要的是运用这种方法的分析过 程，只有通过这个过程我们才能更深入的理解投资以及投资创造价值的内在逻辑。

    本篇发表于《中国证券报》企业估值专栏

本文引自http://news.csdn.net/n/20061221/99706.html

目前，针对oracle数据库的远程复制、容灾主要有以下几种技术或解决方案：

（1）基于存储层的容灾复制方案

这种技术的复制机制是通过基于SAN的存储局域网进行复制，复制针对每个IO进行，复制的数 据量比较大;系统可以实现数据的同步或异步两种方式的复制.对大数据量的系统来说有很大的优势（每天日志量在60G以上）,但是对主机、操作系统、数据库 版本等要求一致，且对络环境的要求比较高。

目标系统不需要有主机，只要有存储设备就可以，如果需要目标系统可读，需要额外的配置和设备，比较麻烦。

（2）基于逻辑卷的容灾复制方案

这种技术的机制是通过基于TCP/IP的网络环境进行复制，由操作系统进程捕捉逻辑卷的变化 进行复制。其特点与基于存储设备的复制方案比较类似，也可以选择同步或异步两种方式，对主机的软、硬件环境的一致性要求也比较高，对大数据量的应用比较有 优势。其目标系统如果要实现可读，需要创建第三方镜像。个人认为这种技术和上面提到的基于存储的复制技术比较适合于超大数据量的系统，或者是应用系统的容 灾复制。

（3）基于oracle redo log的逻辑复制方式

使用这种方式的主要有一些第三方的软件，以及oracle自己的DATAGUARD 中的logical Standby。目前，国外已经有了很多比较成熟的产品及成功案例，国内也有类似的产品， 但在产品的成熟程度和成功案例上跟国外还有一定的差距。

这类产品的原理基本相同，其工作过程可以分为以下几个流程：

使用oracle以外的独立进程，捕捉redo log file 的信息，将其翻译成sql语句，再通过网络传输到目标端数据库，在目标端数据库执行同样的sql。如果其进程赶不上oracle日志切换，也可以捕捉归档 日志中的内容。也有的产品在源端以事务为单位，当一个事务完成后，再把它传输到目标端。所有的产品一般都是以表为单位进行复制，同时也支持大部分DDL的 复制（主要在oracle9i环境中）。

这种技术的技术特点和优势主要有以下几点：

目标端数据库一直是一个可以访问的数据库；

能保证两端数据库的事务一致性；

因为使用oracle以外的进程进行捕捉，且其优先级低于oracle进程，所以对源系统数据库的性能影响很小；

基于其实现原理及多个队列文件的使用，复制环境可以提供网络失败、数据库失败、主机失败的容错能力；

因为这类软件复制的只是sql语句或事务，所以他可以完全支持异构环境的复制，硬件的型号，oracle的版本，操作系统的种类、版本等都没有要求。

这种方式还可以支持多种复制方式，比如数据集中、分发、对等复制、或者多层测的复制等。

由于传输的内容只是redolog 或archive log中的一部分，所以对网络资源的占用很小，可以实现不同城市之间的远程复制。

基于redolog的逻辑复制产品有很多的优势，但跟上面提到过的其他方案比较起来，也有一些缺点：

数据库的吞吐量太大时，其实据会有较大的延迟，当数据库每天的日量达到60G或更大时，这种方案的可行性交差；

实施的过程可能会有一些停机时间，来进行数据的同步和配置的激活；

复制环境建立起来以后，对数据库结构上的一些修改需要按照规定的操作流程进行，有一定的维护成本。

不过目前这类产品的发展很快，上面的这些问题，在大部分产品的最新版本中都有很大的改进。

引自http://news.csdn.net/n/20061227/100014.html

数据存储备份技术一般包含硬件技术及软件技术等，硬件技术主要是磁带机技术，软件技术主要是通用和专用备份软件技术等。

　　磁带机技术:

　　无论是硬盘技术，还是光盘技术，都不适合用来进行数据存储备份，只有磁带机技术才真正适合数据存储备份领域。事实上，磁带机技术长期以来一直是首选的唯一的数据存储备份技术，因为磁带介质不仅能提供高容量、高可靠性以及可管理性，而且价格比光盘、磁盘媒体便宜很多。

　　作为一种备份设备，磁带机技术也在不断发展。当前市场上的磁带机，按其记录方式来分，可归纳为二大类:一类是数据流磁带机，另一类是螺旋扫描磁带机。

　　数据流技术起源于模拟音频记录技术，很类似于录音机磁带的原理。它是通过单个或多个静态的磁头与高速运动的磁带接触来记录数据。这种技术的缺点 在于对磁带的张力要求很高，耐用性较差。数据流磁带机按磁带的宽度分为QIC(Quarter-Inch-Cartridge，即1/4英寸)和1/2英 寸两种。1/2英寸磁带机是多磁头读写，其数据传输率较高，容量较大。1/4英寸磁带机是单磁头读写，每记录一轨后，都要通过跳轨来做反向记录，记录和检 索速度都比较慢。

　　螺旋扫描技术起源于模拟视频记录技术，很类似于录像机磁带原理。它和数据流技术正相反，磁带是绕在磁鼓上，磁带非常缓慢地移动，磁鼓则高速转 动，在磁鼓两侧的磁头也高速扫描磁带进行记录。当它在一定时间内没有收到移动磁带的命令，就会放松磁带并停止转动磁鼓，以防止不必要的介质磨损和避免介质 长期处于张力状态。所以，该技术具有高可靠性、高速度、高容量的特点。

　　IDC的调查报告表明，目前比较流行的磁带机技术有DC2000/TraVan磁带机、QICDC6000磁带机、8mm磁带机、DLT磁带机、DAT磁带机及Mammoth磁带机等。下面分别给予简单介绍。

　　QIC磁带

　　这是一种带宽为1/4英寸，配有带盒的盒式磁带，也叫1/4英寸磁带。它有两种规格，即DC6000和DC2000/Travan。其中 DC6000磁带的驱动器是5.25英寸，它使用非常简单的驱动装置进行纵向记录，但是数据磁带结构却非常复杂并且价格昂贵。在容量1GB以上的市场中， 它无法与4mm与8mm磁带竞争。DC2000/Travan磁带的驱动器只有3.5英寸，驱动器价格低，一般不具备硬件数据压缩功能与即写即读功能，而 且使用的介质造价也较高。这种产品对性能要求不高的桌面计算机用户可能较合适，但用户不多。

　　DLT技术

　　DLT(Digital Linear Tape-数字线性磁带)技术源于1/2英寸磁带机。1/2英寸磁带机技术出现很早，主要用于数据的实 时采集，如程控交换机上话务信息的记录，地震设备的震动信号记录等等。DLT磁带由DEC和Quantum公司联合开发。由于磁带体积庞大，DCT磁带机 全部是5.25英寸全高格式。DLT产品由于高容量，主要定位于中、高级的服务器市场与磁带库系统。DLT磁带每盒容量高达35GB，单位容量成本较低。

　　4mm技术

　　4mmDAT又称数字音频磁带技术(Digital Audio Tape)。早期的DAT技术主要应用于声音的记录，后来随着这种技术的不断 完善，又被应用在数据存储领域里。4mm的DAT经历了DDS-1、DDS-2和DDS-3三种技术阶段，容量跨度在1GB-12GB。4mmDAT由于 小巧和适当的容量，在前几年发展很快，在小型网络中应用较多。目前惠普已经推出了采用DDS-4标准、容量为40GB的磁带机。

　　由于该磁带存储系统采用了螺旋扫描技术，使得该磁带具有很高的存储容量。DAT磁带系统一般都采用了即写即读和压缩技术，既提高了系统的可靠性 和数据传输率，又提高了存储容量。DAT磁带和驱动器的生产厂商较多，用户有较大的选择机会，是一种很有前途的数据存储备份产品。

　　8mm技术

　　基于螺旋扫描记录技术的8mm产品由Exabyte公司开发。由于8mm技术本身适合于大容量存储，在计算机数据比较少的早期，其应用面不是很 广，主要与大中小型计算机配套。随着计算机网络中数据量呈几何级数的增长，8mm技术越来越体现出其优势，8mm产品的出货量这几年的快速增长也佐证了这 一点。8mm技术有着广阔的向上发展空间。并且，每一种新的、高端的8mm产品，都向下兼容低端产品，保护了用户原有的投资。

　　未来磁带存储新技术LTO

　　LTO(Linear Tape Open—线性磁带开放协议)技术是一种结合了线性多通道双向磁带格式的磁带存储新技术，其优点主要是将服务 系统、硬件数据压缩、优化磁道面、高效纠错技术和提高磁带容量性能等结合于一体。由于LTO技术是一种“开放格式”技术，这就意味着用户将可拥有多项产品 和多规格存储介质，尤其开放性可带来更多的发明创新，减少新技术开发风险，从而达到使产品价格下降和用户受益的目的，另外还可提高产品的兼容性和延续性。 LTO第四代标准的容量为800G，传输速度为80MB/s～160MB/s，这是目前任何一种磁带机都无法比拟的。开发LTO的主要原因有以下几点:一 是建立一个开放的磁带机产品标准;二是不断改进磁带机产品的可靠性;三是增强产品的可扩展性，适应数据量激增的现实需求;四是减少备份的时间，提高产品的 性能。

　　目前，LTO技术有两种存储格式，即高速开放磁带格式Ultrium和快速访问开放磁带格式Accelis，它们可分别满足不同用户对LTO存 储系统的要求，其中Ultrium磁带格式除了具有高可靠性的LTO技术外，还具有大容量的特点，既可单独操作，也可适应自动操作环境，非常适合备份、存 储和归档应用。Accelis磁带格式则侧重于快速数据存储，Accelis磁带格式能够很好地适用于自动操作环境，可处理广泛的在线数据和恢复应用。

备份软件技术

　　备份软件技术在整个数据存储备份过程中具有相当的重要性，因为它不仅关系到是否支持磁带的各种先进功能，而且在很大程度上决定着备份的效率。有 人认为，最好的备份软件就是操作系统所提供的备份功能，诸如Unix的tar/cpio、WindowsNT的WindowsBackup、 Netware的Sbackup等。其实不然，因为这些操作系统仅能提供一些基本的备份功能，缺乏专业备份软件的高速度与高性能，目前比较流行的专业备份 软件有CA的ARCserve2000、VERITAS的BackupExce以及Legato的Networker等。

大家知道，磁带机对数据传输速度有一定要求，若数据传输率偏低，磁带机就无法连续运转。而专业备份软件因能通过优化数据传输率即可以自 动以较高的传输率进行数据传输，这不仅能缩短备份时间，提高数据存储备份速度，而且对磁带机设备本身也有好处。另外，专业备份软件还支持新磁带机技术，如 HP的TapeAlert技术，差不多所有主流专业备份软件均提供支持。

　　DAS、NAS和SAN存储模式

　　DAS(Direct Attached Storage—直接连接存储)是指将存储设备通过SCSI接口或光纤通道直接连接到一台计算机上。 DAS的适用环境为:1)服务器在地理分布上很分散，通过SAN或NAS在它们之间进行互连非常困难时(商店或银行的分支便是一个典型的例子);2)存储 系统必须被直接连接到应用服务器(如Microsoft Cluster Server或某些数据库使用的“原始分区”)上时;3)包括许多数据库应用和 应用服务器在内的应用，它们需要直接连接到存储器上，群件应用和一些邮件服务也包括在内。

　　当服务器在地理上比较分散，很难通过远程连接进行互连时，直接连接存储是比较好的解决方案，甚至可能是唯一的解决方案。利用直接连接存储的另一个原因也可能是企业决定继续保留已有的传输速率并不很高的网络系统。

　　NAS和SAN的出现响应了三种重要的发展趋势:网络正成为主要的信息处理模式;需要存储的数据大量增加;数据作为取得竞争优势的战略性资产其重要性在增加。

　　NAS(Network Attached Storage—网络连接存储)即将存储设备通过标准的网络拓扑结构(例如以太网)，连接到一群计 算机上。NAS是部件级的存储方法，它的重点在于帮助工作组和部门级机构解决迅速增加存储容量的需求。需要共享大型CAD文档的工程小组就是典型的例子。

　　NAS产品包括存储器件(例如硬盘驱动器阵列、CD或DVD驱动器、磁带驱动器或可移动的存储介质)和集成在一起的简易服务器，可用于实现涉及 文件存取及管理的所有功能。简易服务器经优化设计，可以完成一系列简化的功能，例如文档存储及服务、电子邮件、互联网缓存等等。集成在NAS设备中的简易 服务器可以将有关存储的功能与应用服务器执行的其他功能分隔开。

　　这种方法从两方面改善了数据的可用性。第一，即使相应的应用服务器不再工作了，仍然可以读出数据。第二，简易服务器本身不会崩溃，因为它避免了引起服务器崩溃的首要原因，即应用软件引起的问题。

　　NAS产品具有几个引人注意的优点。首先，NAS产品是真正即插即用的产品。NAS设备一般支持多计算机平台，用户通过网络支持协议可进入相同 的文档，因而NAS设备无需改造即可用于混合Unix/Windows NT局域网内。其次，NAS设备的物理位置同样是灵活的。它们可放置在工作组内， 靠近数据中心的应用服务器，或者也可放在其他地点，通过物理链路与网络连接起来。无需应用服务器的干预，NAS设备允许用户在网络上存取数据，这样既可减 小CPU的开销，也能显著改善网络的性能。

　　NAS没有解决与文件服务器相关的一个关键性问题，即备份过程中的带宽消耗。与将备份数据流从LAN中转移出去的存储区域网(SAN)不同， NAS仍使用网络进行备份和恢复。NAS 的一个缺点是它将存储事务由并行SCSI连接转移到了网络上。这就是说LAN除了必须处理正常的最终用户传输流 外，还必须处理包括备份操作的存储磁盘请求。

　　SAN(存储区域网络)通过光纤通道连接到一群计算机上。在该网络中提供了多主机连接，但并非通过标准的网络拓扑。

　　SAN则专注于企业级存储的特有问题。当前企业存储方案所遇到问题的两个根源是:数据与应用系统紧密结合所产生的结构性限制，以及目前小型计算 机系统接口(SCSI)标准的限制。大多数分析都认为SAN是未来企业级的存储方案，这是因为SAN便于集成，能改善数据可用性及网络性能，而且还可以减 轻管理作业。

　　SAN解决方案的优点有以下几个方面:

　　SAN提供了一种与现有LAN连接的简易方法，并且通过同一物理通道支持广泛使用的SCSI和IP协议。SAN不受现今主流的、基于SCSI存储结构的布局限制。特别重要的是，随着存储容量的爆炸性增长，SAN允许企业独立地增加它们的存储容量。

　　SAN的结构允许任何服务器连接到任何存储阵列，这样不管数据置放在那里，服务器都可直接存取所需的数据。因为采用了光纤接口，SAN还具有更高的带宽。

　　因为SAN解决方案是从基本功能剥离出存储功能，所以运行备份操作就无需考虑它们对网络总体性能的影响。SAN方案也使得管理及集中控制实现简 化，特别是对于全部存储设备都集群在一起的时候。最后一点，光纤接口提供了10公里的连接长度，这使得实现物理上分离的、不在机房的存储变得非常容易。

　　SAN主要用于存储量大的工作环境，如ISP、银行等，但现在由于需求量不大、成本高、标准尚未确定等问题影响了SAN的市场，不过，随着这些用户业务量的增大，SAN也有着广泛的应用前景。

引自http://news.csdn.net/n/20061218/99581.html

数据仓库是存储数据的一种组织形式，它从传统数据库中获得原始数据，先按辅助决策的主题要求形成当前基本数 据层，再按综合决策的要求形成综合数据层(又可分为轻度综合层和高度综合层)。随着时间的推移，由时间控制机制将当前基本数据层转为历史数据层。可见数据 仓库中逻辑结构数据由3层到4层数据组成，它们均由元数据(Meta Data) 组织而成。数据仓库中数据的物理存储形式有多维数据库组织形式(空间超立方体形式)和基于关系数据库组织形式(由关系型事实表和维表组成)。

　　数据仓库系统(DWS)由数据仓库、仓库管理和分析工具三部分组成。

　　源数据：数据仓库的数据来源于多个数据源，包括企业内部数据、市场调查报告及各种文档之类的外部数据。

　　仓库管理: 在确定数据仓库信息需求后，首先进行数据建模，然后确定从源数据到数据仓库的数据抽取、清理和转换过程，最后划分维数及确定数据仓库的物理存储结构。元数据是数据仓库的核心，它用于存储数据模型和定义数据结构、转换规划、仓库结构、控制信息等。

　　数据仓库: 包括对数据的安全、归档、备份、维护、恢复等工作，这些工作需要利用数据库管理系统(DBMS)的功能。

　　分析工具用于完成实际决策问题所需的各种查询检索工具、多维数据的OLAP分析工具、数据开采DM工具等，以实现决策支持系统的各种要求。

　　数据仓库应用是一个典型的C/S结构。其客户端的工作包括客户交互、格式化查询及结果和报表生成等。服 务器端完成各种辅助决策的SQL查询、复杂的计算和各类综合功能等。现在，一种越来越普遍的形式是三层结构，即在客户与服务器之间增加一个多维数据分析服 务器。OLAP服务器能加强和规范决策支持的服务工作，集中和简化原客户端和DW服务器的部分工作，降低系统数据传输量，因此工作效率更高。

什么是联机分析处理（OLAP）

联机分析处理 (OLAP) 的概念最早是由关系数据库之父E.F.Codd于1993年提出的，他同时提出了关于OLAP的12条准则。OLAP的提出引起了很大的反响，OLAP作为一类产品同联机事务处理 (OLTP) 明显区分开来。

当今的数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支 持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。下表列出了OLTP与OLAP之间的比较。

OLAP是使分析人员、管理人员或执行人员能够从多角度对信息进行快速、一致、交互地存取,从而获得对数据的更深入了解的一类软件技术。OLAP的目标是满足决策支持或者满足在多维环境下特定的查询和报表需求,它的技术核心是"维"这个概念。

“维”是人们观察客观世界的角度,是一种高层次的类型划分。“维”一般包含着层次关系,这种层次关系有时会相当复杂。通过把一个实体的多项重要的属性定义为多个维(dimension)，使用户能对不同维上的数据进行比较。因此OLAP也可以说是多维数据分析工具的集合。

OLAP的基本多维分析操作有钻取（roll up和drill down）、切片（slice）和切块（dice）、以及旋转（pivot）、drill across、drill through等。

· 钻取是改变维的层次，变换分析的粒度。它包括向上钻取（roll up）和向下钻取（drill down）。roll up是在某一维上将低层次的细节数据概括到高层次的汇总数据，或者减少维数；而drill down则相反，它从汇总数据深入到细节数据进行观察或增加新维。
·切片和切块是在一部分维上选定值后，关心度量数据在剩余维上的分布。如果剩余的维只有两个，则是切片；如果有三个，则是切块。
·旋转是变换维的方向，即在表格中重新安排维的放置（例如行列互换）。

OLAP有多种实现方法，根据存储数据的方式不同可以分为ROLAP、MOLAP、HOLAP。

ROLAP 表示基于关系数据库的OLAP实现（Relational OLAP）。以关系数据库为核心,以关系型结构进行多维数据的表示和存储。ROLAP将多维数据库的多维结构划分为两类表:一类是事实表,用来存储数据和 维关键字;另一类是维表,即对每个维至少使用一个表来存放维的层次、成员类别等维的描述信息。维表和事实表通过主关键字和外关键字联系在一起,形成了"星 型模式"。对于层次复杂的维,为避免冗余数据占用过大的存储空间,可以使用多个表来描述,这种星型模式的扩展称为"雪花模式"。

MOLAP 表示基于多维数据组织的OLAP实现（Multidimensional OLAP）。以多维数据组织方式为核心,也就是说,MOLAP使用多维数组存储数据。多维数据在存储中将形成"立方块（Cube）"的结构,在MOLAP 中对"立方块"的"旋转"、"切块"、"切片"是产生多维数据报表的主要技术。

HOLAP表示基于混合数据组织的OLAP实现（Hybrid OLAP）。如低层是关系型的，高层是多维矩阵型的。这种方式具有更好的灵活性。

还有其他的一些实现OLAP的方法，如提供一个专用的SQL Server，对某些存储模式（如星型、雪片型）提供对SQL查询的特殊支持。

OLAP 工具是针对特定问题的联机数据访问与分析。它通过多维的方式对数据进行分析、查询和报表。维是人们观察数据的特定角度。例如，一个企业在考虑产品的销售情 况时，通常从时间、地区和产品的不同角度来深入观察产品的销售情况。这里的时间、地区和产品就是维。而这些维的不同组合和所考察的度量指标构成的多维数组 则是OLAP分析的基础，可形式化表示为（维1，维2，……，维n，度量指标），如（地区、时间、产品、销售额）。多维分析是指对以多维形式组织起来的数 据采取切片（Slice）、切块（Dice）、钻取（Drill-down和Roll-up）、旋转（Pivot）等各种分析动作，以求剖析数据，使用户 能从多个角度、多侧面地观察数据库中的数据，从而深入理解包含在数据中的信息。

根据综合性数据的组织方式的不同，目前常见的OLAP主要有基于多维数据库的MOLAP及基于关系数据库的ROLAP两种。MOLAP是以多维的方 式组织和存储数据，ROLAP则利用现有的关系数据库技术来模拟多维数据。在数据仓库应用中，OLAP应用一般是数据仓库应用的前端工具，同时OLAP工 具还可以同数据挖掘工具、统计分析工具配合使用，增强决策分析功能。

引子：
    "这个项目的架构是什么？"
   对方爽快的回答："Spring+Struts+Hibernate。"
   嗯，这位很可能不是架构师......

一、核心竞争力

架构设计的理论、模式与技术
    架构师们从试验与挫折中获得架构设计的技能，但其中大量的原理、模式和技巧，都经历了一个重复发现的过程。
    其实，各路神仙在这个领域虽则没有捣鼓出大热的畅销书来，但前篇的架构师书单，也足够为我们作一个系统的知识整理。
    痛苦回首，发现自己的再发现式积累还是太慢、太片面，大多局限于GOF23、Java EE架构模式、RUP4+1视图等方面。

有序的以方法为驱动源的任务执行 
 
    匠级的架构师多有一套自己的方法论、过程论，每回设计都是熟练而有序的执行。
    其中架构师的小过程可以参考书单反复试验，独家秘制。
    而与开发团队配合的大过程，以RUP为基础的剪裁被描述得最为详细，可执行度最高的。

领域知识

    技术人员一般抗拒学习软件开发以外的东西，但架构师却非如此不可，因为架构师的职责就是将业务需求转化为系统设计。那又如何快速成为新领域的专家呢？精通快速业务建模吗？
    BTW.G9写过一篇很有意思的〈商业软件编程很无聊？〉

大型项目的经验

    中国有多少架构师，不在于有多少人通过了什么考试培训，而在于中国大型项目的数量。
    问：你这个项目的架构是什么？一口回答：Spring+Struts+Hibernate。这位很可能就不是架构师了，因为这仅仅是技术Stack，项目规模不大时Spring+Struts+Hibernate才会成为架构的重点。

    除了亲自担任大型项目的架构师，如果了解这些项目为了满足怎样的功能与非功能需求而把架构设计成这样子也一样的。所以，尽量多读一下公司项目的设计文档，愉快的接受其他项目组架构评审会的邀请。

二、基本能力

完整的软件开发生命周期经验

    这个不用说了，幸好中国的架构师什么脏活累活都做过，甚至跟着市场人员跑去做演示这些国外架构师不一定有的经验我们都有了，差别只在于一些理论知识--RUP + CMMI3 + 敏捷原则的细节掌握程度。

精通一两种主流开发语言、保持当下架构的开发体验

    国内的架构师到了三十岁以后很多就往理论上跑，而国外的架构师则在往上发展的同时保持下面的编程体验，所以国内多水王，而国外则多大师。
    水王的设计一般会层次过高，与实现之间有断层，与开发人员沟通困难，自己哗啦啦编个验证原型的日子更是一去不返。更痛苦的是，人过三十之后学习能力下降，手艺一旦放下了想重新上手还很难:(

    但是，也不必要挽起袖子每月编码若干行，很可能你的"亲自出手"因为时间安排不来反而拖了大家的进度，但一定要保持一个体验。

宏观上的，广度优先的了解当前主流的技术与产品

     架构师如果连Tuxedo与IBM MQ都分不清，一句"这里搞个异步调用的middleware，有commercial support的"，同样是层次太高了。架构师对各大公司的完整产品线和著名的开源项目应该有宏观上的了解，最好在Wiki里编个索引。
     但同时也要抵制成为某项技术专家如Oracle启动参数优化专家的诱惑，技术细节掌握到业务职责需要的程度就刚好了。除非如Spring Framework进一步了解能带来天大好处。

与业务域开发域人员沟通的能力及其他领导能力
 
   IT 架构师处在客户和开发人员之间，必须能够使用各种媒体（代码、模型、文档、PowerPoint以及谈话和讲座），与技术和非技术的干系人进行沟通。另外，架构师好歹也是个半大不小的官，其他领导必要的能力就不列了。
   
    参考了IBM DW中国上的两篇文章：

• 软件构架师的特点
• 观点与展望，第 3 部分: 什么是最有价值的 IT 体系结构技能，如何学习？

三、镜子做好了，自己先照一下

• 要把书单啃完；
• 要熟悉NGOSS、3G、IMS这些业务知识；
• 要把公司几百个项目的设计文档抽好的看一遍；
• 要跟随公司最新一波RUP+CMMI3行情；
• 要重修C++；
• 要完整了解一遍IBM、BEA们的产品线；
• 要从那些写得好的架构PPT中偷师...

在本月的专栏中，IBM 有洞察力的专家给出了他们对 IT 架构师在目前及将来所面临的问题的观点与展望。本月，他们将考虑以下问题：“我如何将组织的业务需求转换为 IT 要求，以便在系统体系结构中满足这些需求？"

引言

注意：有关观点与展望 专栏的一般性介绍，请参阅第 1 部分。

作为 IT 架构师，您可能经常会发现自己处于进退维谷的境地，前有您的业务目标，后有您的 IT 系统。这两方面都具有规模大、不易改变和灵活性差的特点。制定业务目标的人员和开发系统的人员不一定了解彼此的工作内容和成果。似乎是这样，业务人员使用 一种语言来表达他们希望实现的业务目标，而开发人员则使用另一种语言来表述技术要求。

而这就是我们为了实现高效率而需要着手处理的问题：理解这两种语言并执行必要的转换，以便 IT 能反映业务的需求，并能在适当的时候对业务目标进行更改，使其与 IT 的能力相适应。这并不是一个容易完成的工作，但这正是您能够获得很大利益的原因。

由于这部分工作可能会非常困难而棘手，因此，我们向 IBM 体系结构专家队伍寻求指导。本月我们邀请这些专家分享他们用来将业务需求表述为明晰简洁的技术要求的方法，以便 IT 团队能成功地实现。

我们在此提供的内容谈不上全面。本文的全部内容都是在讨论如何将业务需求转换为技术要求，但关于这个主题还有很多可说。每位 IT 架构师对此问题的答案的关注点都或多或少有自己的特别之处，没有任何答案能满足所有人的愿望。不过，我们的专家将为您指明有用的方向，以抛砖引玉，我们相 信这可以帮助您找到本月的问题的最恰当答案。

再次感谢我们的供稿编辑 Holt Adams，您将在下面读到他对本月讨论的问题的看法。

欢迎每月阅读 developerWorks IT 体系结构方面的精彩内容：如何将业务需求转换为 IT 要求这一主题是本月要讨论的话题。

我们也欢迎您就本专栏未来的发展方向给出您的意见和建议。您有需要我们的专家团队回答的问题吗？请将您的问题发布到我们的 IT 体系结构讨论论坛。或者，通过以下邮件地址与我联系：pdreyfus@us.ibm.com。

Paul Dreyfus，编辑
developerWorks SOA and Web services
pdreyfus@us.ibm.com

另：为了显得没有偏袒，让讨论自然地展开，我们本月按照姓名的字母降序对供稿人的回答进行排列。（仔细阅读过第一期专栏的读者会发现该期的供稿人是按照从 A 到 Z 的顺序排列的。）

回页首

一个词：用例（哦，两个字）

用电影毕业生 (The Graduate) 中的方式来说，我只想对你说一个词：用例。（哦，那是两个字。）很多年来，我们都将用例用于对应用程序进行建模。现在，在面向服务的体系结构 (SOA) 中，我们也使用这个概念来对业务进行建模。

在 Alistair Cockburn 的 Writing Effective Use Cases 一书中，他将用例定义为“系统干系人之间就系统的行为达成的协定”。用例必须适合所定义的系统范围，能够代表此情况下使用系统的主要参与者的观点，且能够在一致的抽象层次上表示参与者的系统使用情况。

例如，股票交易 Web 站点的一个用例是“购买股票”，允许用户通过此站点购买股票。该用例描述了客户进行何种操作以及站点如何响应，而暂时忽略了站点将如何实际实现此行为。

在业务用例中，参与者是干系人，而系统则是业务本身。 ——Bobby Woolf

可以将用例用于对服务进行建模；我将此称为服务用例。当用例描述服务时，参与者就是服务使用者，而系统则为服务提供者。与任何用例一样，此时的重点是服务提供者提供何种行为，而不是如何实现该行为。（有关服务用例的更多信息，请参阅我的 developerWorks 文章“通过服务模拟来简化 SOA 开发”。）

还可以将用例用于对业务进行建模。在业务用例中，参与者是干系人——业务用户（如客户或员工，甚至股东或政府监管人员），而系统则是业务本身（生产 产品并将其销售给客户的公司）。您的业务如何开展？客户希望您的业务如何开展，他们愿意为何种服务或产品付费？员工需要业务如何开展才能完成各自的工作？ 关键在于：这些干系人如何与公司进行交互？这些都是业务用例。

获得了业务用例后，则可以随后将其链接起来，以形成业务流程——公司可以执行的过程。这些流程本身就是业务用例，而复杂的业务用例可以被视为业务流程。简单地讲，这些流程显示了公司要做什么以及如何做。如前面所述，流程以及每个流程中的步骤都对服务进行建模。

通过用例将公司（或公司的一部分）建模为由服务组成的业务流程后，随后的目标就是尽可能多地实现流程和服务的自动化。（无法实现自动化的就是需要人 工完成的任务。）实现这种自动化的应用程序（实现流程和服务）是采用面向服务的体系结构的应用程序。而您现在正在进行 SOA 实践。

回页首

记录流程

当 我坐下来和客户讨论新程序或开发工作时，我会立即了解业务干系人是否出席，或是否派了代表出席。然后，我会希望得到记录良好的业务流程和数据要求。除非相 关工作是一片“处女地”（即之前从没有进行过此类工作），否则一定会对新应用程序或功能支持的原有的业务流程和将来的业务流程有良好的理解。不管采用哪一 种方式，如果客户不了解业务，架构师有效定义系统要求的几率都很小。

我个人非常赞同开发业务场景来记录业务流程。业务场景允许您在整个业务问题的上下文中标识系统要求。The Open Group 提供了一本非常出色的的小册子，用于帮助了解和开发业务场景，书名为 Manager's Guide to Business Scenarios。

如果客户不了解业务，架构师有效定义系统要求的几率都很小。 ——Andras Szakal

确定了将来的业务需求后，如果能维护一份功能和非功能行式项目要求的列表，也很有好处。您可以使用电子表格来维护此列表，但如果想要尽量保持要求的 可跟踪性和根据优先级或类别管理各种要求，则这种方法就显得不合适。我极力赞同使用工具来管理要求；为了达成此目的，我建议使用 IBM Rational® RequisitePro®。

通过使用根据业务场景确定的初始要求集，我们就可以开始定义系统行为的过程了。 为此，您可以召开联合应用程序开发（Joint application development，JAD）会议，以便根据一系列初始行式项目要求来充实将来的系统。通过 JAD 会议，架构师可以与干系人一起确定期望的系统行为，并以此为基础记录用例和场景。通过对用例和场景进行细化，可以帮助定义最终的一系列功能和非功能要求。

回页首

从一开始就使用 RequisitePro

Rational RequisitePro 是一个没有得到足够重视的 Rational 产品，该产品用于收集、记录和细化需求和其他业务概念。它允许业务用户在 Word 文档中编写声明，然后将其捕获到数据库中，并将这些声明与用户定义的其他属性相关联。这些声明可以描述需求、策略、用户角色、干系人以及与业务相关的任何 其他内容。

使用迭代需求细化流程时，可以在相关声明之间建立联系。例如，需求“Portlet 显示 X、Y 和 Z 客户信息”，可以与另一项需求“角色 A、B 和 C 应接收所有必要的客户信息”联系起来。在这种情况下，第一项需求是第二项需求的细化。这样就对一般需求和详细需求之间的关系进行了建模。

"当更改这项业务需求时，为了与其相匹配，必须对模型或实现的哪些方面进行相应的更改？" ——Mark Linehan

在我个人看来，您应该在建模阶段一开始就使用 RequisitePro。RequisitePro 中管理的声明可成为建模工具（如 IBM WebSphere® Business Integration Modeler、Rational Sofware Architect (RSA) 或 Rational Software Modeler (RSM)） 的输入。事实上，Rational Sofware Architect 和 Rational Software Modeler 都提供了将 RequisitePro 需求显式地链接到用例和其他建模元素的功能。您还可以将需求链接到 Java™ Java 2 Platform Enterprise Edition (J2EE) 和其他类似的实现构件。通过此功能，您可以获得各种问题的答案，如“当更改此项业务需求时，为了与其相匹配，必须对模型或实现的哪些方面进行相应的更 改？”

最后，在读过了 Simon Johnston 所提出的观点后，我希望补充一些内容：

我最近组织了一次理解“策略”概念的工作，了解什么是策略，以及它应该如何适应 IBM 的系列工具。通过这项工作，得出了以下定义：

• 策略 是在一定业务领域内以实现特定业务目标为目的的声明。此定义与说明和其他相关材料中强调的业务意图是一致的。
• 声明 是以某种人类语言表述的语句。因此策略与 RequisitePro 的适应性非常好；就某种意义而言，策略就是一种需求。

策略是通过一个细化流程制定的，该流程以高级策略声明为基础进行，而这些高级策略声明通常不能直接实现；这些高级声明将通过迭代方式细化为更为详细 的策略。然后，可以通过使用我前面描述的 RequisitePro 功能将完全细化的策略与实现工作联系起来。Simon 所说的“连续体”与策略生命周期这个观点是一致的。

Calvin Powers 完成了一个基于 Web 的相对不错的演示文档，演示了可以如何将 RequisitePro 用于捕获和细化业务策略。请访问 IBM Business and Technology Solutions Resource Library，并在 Demos 部分查找“Policy Provisioning using IBM Rational RequisitePro and IBM Workplace Business Controls and Reporting”。

回页首

正确功能的正确解决方案

我很喜欢 Kerrie Holley 对本月问题的重新表述：“我如何从业务意图转到已实现的价值或 IT 解决方案？”开发和设计解决方案的体系结构时需要考虑的最重要的事项之一就是所需的对应功能和容量级别。如果我所做的只是将价格信息发布到网上，我可以到 最近的小学里找个人来编写 HTML。不过，如果我是 Wal-Mart，而我要做的是尝试采用多种语言跨越国界扩展我的供应链，并确保可以全天候地访问，那么我的功能和容量就必须更为可靠。

经验丰富的专业人员可以帮助客户将业务需求转换为业务意图。业务意图更为模糊，但更与“基本需求”和“投资回报”一致。确定了业务意图之后，就可以通过创新且可重复的 IT 解决方案获得实现的价值。

和 Kerrie 一样，我相信业务需求和 IT 功能存在重叠。正是由于这个模糊不清的界线使得体系结构设计成为了一个困难而费时的过程。不管是采用瀑布式还是迭代方法（我们喜欢后者），规划和需求分析 阶段始终都很单调乏味。客户很少知道他们需要什么（尽管很多人知道他们希望得到什么）。经验丰富的专业人员有责任帮助客户将业务需求转换为 IT 功能。

如果我所做的只是将价格信息发布到网上，我可以到最近的小学里找个人来编写 HTML。不过，如果我要做的是尝试采用多种语言跨越国界扩展我的供应链，并确保可以全天候地访问，那么我的功能和容量就必须更为可靠。 ——Calvin Lawrence

这并不能通过只使用良好的工具和方法来实现，因为每个项目都是独特的。方法和技术是指导方法，而工具则用于帮助实现这些方法的自动化。虽然很多项目 都具有共同之处，但他们彼此完全一样的情况却很少。假设它们彼此相同就是假设两个完全不同的业务彼此完全相同（虽然有一定的相似性）。我过去曾和 Home Depot 及 Lowe's 进行过大量合作。尽管这两家公司相似，但他们都会告诉您各自的业务具有独特性。而他们都将这些不同之处视为他们的竞争优势。很多时候，文化、地域和地理位 置对业务需求的影响决定着所建议的 IT 解决方案。政府法律法规和标准可能要求技术人员根据部署解决方案的场合对相同的业务需求采用不同的方法来设计解决方案。

捕获和交付构件的技术——用例、场景文档、Rational Unified Process (RUP)——应当在参与的客户中一致地实现。如果在项目进行中，客户改变了主意（业务需求）和决定，例如系统不需要 24x7 的可用性，而只需要 8x7 的可用性即可，因为他们不希望承担 24x7 解决方案所带来的高成本，您仍然可以很好地使用这些构件。

回页首

捕获最佳实践的模式解决方案

当我看到这个问题时，我的第一个念头是我没有资格回答这个问题，因为我不是与客户接触的架构师。不过，我通过一些咨询活动与客户接触过。我所用的技术并非基于任何正式的方法，而是基于对技术和产品的深入了解。我同意 Holt Adams 所说的“从需求进行转换来选择要用于构造解决方案的技术或产品可能成为一个挑战。”不过帮助却是唾手可得的。

我的团队和我已经开始研究一项用于将设计模式链接起来的技术，我们将这些技术称为模式解决方案。我们的目的是为了使用 Rational Software Architect 中全面的模式框架来捕获针对重复出现的问题的最佳实践。通过这个方法，我们可以采用可重复的方式更有效地将需求转换为技术。我们的目标是构建一个围绕可重 复模式社区。我们希望形成一个像 Amazon.com 一样的社区，人们可以在其中对各种模式进行评论，并为他们喜欢的模式投票。请使用 Pattern Solutions discussion forum 告诉我们您对此主意及我们的实现的看法。

回页首

急需：通用技术

我也同意 Kerrie 对原来的问题中提出的转换的真正目的的描述（我如何从业务意图转到已实现的价值或 IT 解决方案？）：其目的是通过 IT 提供支持业务意图的功能来实现业务的价值。让我们来详细地了解一下此概念。

首先，我们必须关注业务价值。IT 的目的不是使用不断发展的新技术来持续更新我们的技能，而是为业务价值作出贡献。

这句话的另一个重要方面就是 IT 不再仅是开发独立应用程序了。相反，我们提供了可组合到一起实现业务流程的各个功能。SOA 的承诺之一是，我们通过它可以在业务组织和 IT 组织（在其中通过使用服务实现业务流程）之间提供一个相互都能理解的语言机制。

最后，我们需要讨论一下 Kerrie 使用的一个有意思的术语：即业务意图。请注意，他没有使用要求、需求 或用例。业务具有意图。当然，用例或 WebSphere Business Integration Modeler 模型可以帮助了解当前的情况和清楚地说明此意图。但此类工具有一定风险，可能会过早地根据 Modeler 假定的解决方案表述问题。

IT 的目的不是使用不断发展的新技术来持续更新我们的技能，而是为业务价值作出贡献。 ——Simon Johnston

前段时间，曾进行过一次关于描述需求的连续体的 Rational 管理内部讨论，涉及的范围包括从描述业务策略的需求到人员或计算机系统在执行任务时的操作。此连续体包括远景声明、业务目标、关键性能指标 (KPI)、业务流程描述/业务用例（这两个术语可交换使用）、非功能要求，诸如此类。此讨论持续了很长时间，也非常激烈，但却并不一定是因为对此概念存 在异议，而是因为存在很多术语问题——该如何称呼这些“东西”。

虽然我们在需求连续体实践中已经取得了成功，但我仍然和 Kerrie 一样认为不可能采用工具解决此问题。该连续体并不是旨在说明我们必须在需求处理方面使用单一的工具，也不是要指出可以使用唯一的方法来描述各种需求之间的 转换。不过，我们的确需要一种方法，以据此对所有这些“东西”进行管理。我们需要一个全局视图，以帮助我们了解在从一个需求级别到另一个需求级别的转换期 间所做的决策和假设。

另一点与数据相关，但更多地属于业务级别和 IT 级别所给出的声明间的抽象差距。例如，一个业务用户通常会声明某个特定任务的需求——它需要是“安全的”。但这对架构师意味着什么呢？我们有经验的 IT 架构师询问这是否意味着该任务必须保密地执行，还是必须具有防篡改功能或者要求强加密机制或更短暂的内容。业务用户愣了一下，然后有些结巴地说“全-全- 全部”。然后，我们讨论如果支持该安全性的所有内容，以在已知且显式信任的边界内将一段简单的数据从一个服务发送到另一个服务，则所需的基础设施的成本是 多少，在充分理解之后，业务用户指出他们需要的是确保没有未经授权的用户能够看到他们不应该看到的数据。因此，当我们分析业务用户的需求说明时，我们不能 因为他们不懂技术而让他们强行接受某些东西。相反，我们需要获得将这些意图的声明转换为 IT 级别的具体要求的机制。

而这直接意味着我们的确需要更多地利用 RequisitePro，Mark 说从一开始就需要使用这个工具的意见是非常正确的。我们不仅需要能够在 RequisitePro 中捕获业务意图，而且必须利用 RequisitePro 和 Rational Software Architect 之间的联系来跟踪模型，以对业务意图进行反馈。不过，在此消息中存在一个断层，因为 WebSphere Business Integration Modeler 尚未与 RequisitePro 实现集成。这可以通过以下方法得到处理：在 Rational Software Architect 中打开 WebSphere Business Integration Modeler 模型，并将业务模型的 Rational Software Architect 视图与 RequisitePro 相链接。

最近，我对 Rational 业务驱动的开发技术验证进行了更改，以准确地反映以下观点：需要在该过程中尽早引入 RequisitePro，以在开发任何模型——业务模型或 IT 模型——描述解决方案之前捕获真正的意图（如果您愿意，可以将其称为问题）。Don 说明了需求和设计模型为什么经常被视为项目的障碍，而不是价值。在我看来，如果没有链接到一起，一系列需求声明和漂亮的模型仍然是二流构件——而且可能是障碍。

正是通过这个使用 RequisitePro 链接和管理的构件集，开发团队才能了解其在项目中所处的位置，并能作为整体 IT 控制流程的一部分进行项目组合管理决策。

回页首

管理不确定性和易变性

我同意 Don Ferguson 的意见和看法，他已经进行了很好的阐述，我将不对此进行复述，而要增加一些新的东西。2005 年 11 月的 CIO 杂志中也有一篇关于将业务需求转换为 IT 要求的文章“Fixing the Requirements Mess”。我也希望能不重复这其中的内容。

本月的问题也可以表述为：“我如何从业务意图转到已实现的价值或 IT 解决方案？”

业务需求和 IT 要求有很大部分都是重合的；即，对于某些人而言业务需求 指的是“我已更改的或新的业务流程是什么样的？”而对其他人而言，则指的是“我如何借助对应的关键成功因素实现一系列业务目标？”还有些人觉得，这可能只意味着为一系列业务干系人提供功能，如新设备或新页面，或者仅是新的自动化业务规则执行而已。

由于这是一个与人相关的问题，将组织的业务需求转换为 IT 要求的挑战并不能仅靠使用工具或方法得以解决。 ——Kerrie Holley

非常重要的事实是，术语IT 要求 隐含着一个问题：业务需求和 IT 要求之间是否存在差别？这可能会引出一通长篇大论，但我的观点是，缺乏术语以及用来讨论这个问题的共同语言本身就是一个问题。

我们的挑战是业务需求和要求通常仅得到了部分理解，而且通常具有易变性。很多开发方法都在通过引入迭代开发、工具以及其他技术来适应这个不确定性和 易变性。但这些方法仅解决了这个问题的一部分，因为这个不确定性和易变性仅是此问题的一部分而已。在假定特定方法是最优的方法之前，要求流程必须了解要进 行的项目的类型。

项目类型因大小、范围、组织关心的重点、文化、对解决方案的认识、当前环境以及其他因素的不同而有所差异。各种项目类型要求我们对每个项目采用不同 的方式来处理将组织的需求转换为 IT 要求的问题。不同的类型项目要求在开发方法、工具以及应如何管理要求方面采取不同的处理方式。

由于这是一个与人相关的问题，将组织的业务需求转换为 IT 要求的挑战并不能仅靠使用工具或方法得以解决。认为可以通过改善工具或创建新开发流程、方法或技术来完全地解决此问题的想法是错误的。

管理很多项目的需求流程需要我们具有确定应在软件中包含哪些东西不包含哪些东西的方法。此过程要求结合使用各种协作技能、辅助技能、工具、技术和方法。

经验丰富的专业人员知道将组织的业务需求转换为 IT 要求的过程中必须根据一系列因素进行调整。这些因素包括：

• 对业务需求了解多少？
• 对 IT 要求了解多少？
• 最终的解决方案的概貌如何？

这些因素在项目进行期间会不断地发生变化。

这正是采用敏捷编程、IBM Global Services (GS) 方法、Rational Unified Process (RUP) 或其他流程的技术人员不能盲目认为其采用的方法就是正确的方法的众多原因之一。没有“万能”方法；这些都是工具。有见识的专业人员必须选择何时以及如何使用正确的工具，并使这些工具与正在开发的项目类型和场景相匹配。

例如，GS 方法在帮助清楚地阐述一些要求必须适应的大环境（如系统上下文、用例、基础结构、安全）方面非常不错。此方法可帮助建立分类，以便我们在讨论 IT 要求 和业务需求 时知道各自明确的对象。

我的 IBM 同事 John Cameron 在一篇关于在启动项目时经常遇到的不确定性分类的文章中谈到了这其中的一些方面。他认为，此不确定性的程度以及我们对解决方案的认识程度在如何将组织的业务需求转换为 IT 要求方面扮演着重要的角色。John 的分析在图 1 中得到了描述，图中根据我们对需求以及项目的了解情况用一个简单的矩阵对项目进行了分类。

图 1. John Cameron 所做的不确定性分类

回页首

“Outside-in”设计

这是个很好的问题，我希望给出而且也能给出一个很好的回答。我想，解决此问题的最重要方法就是在开发流程和开发规则的过程中保持耐心。

很多项目并不能在需要的时候获得前端需求文档与分析以及业务建模。有时候，似乎会存在不利于提高编码效率的未说明的假设。正式的一流需求处理、流程 建模和构件建模可能非常费时，但同时也能确保开发过程的结果能完美地满足业务需求。需求文档和建模工作应定义开发工作输出的测试用例。如果团队无法将需求 转换为测试用例，团队就没有理解这些需求。

开发也需要进行迭代。我们从 Eclipse 开发和其他项目了解到，我们的开发工作每四到六周就需要生产出可以使用的过渡性版本。该版本应该提供给业务干系人使用，并验证项目是否满足了业务需求。每 个过渡性版本阶段均应以一组得到一致认可的并且该版本将满足的需求和用例/场景作为出发点。

需求文档和建模工作应定义开发工作输出的测试用例。如果团队无法将需求转换为测试用例，团队就没有理解这些需求。 ——Don Ferguson

最后，我们已经开始在 IBM Software Group 内试用一个称为“Outside-in-in design”的概念。在此方法中，我们依赖于以下原则：

• 进行正式的用户建模，包括角色和用户概念对象
• 为与概念对象交互的角色定义一组用例
• 提供用例/场景的低精度和高精度可视模拟（有时简单得像纸上的铅笔画一样。通过这种方式，解决方案的用户可以提供早期评估和反馈。）
• 构建过渡性版本

此过程不是瀑布型的，而是迭代过程。（此方法可帮助提供项目的持续细化，以确保其向提高业务需求和要求的满足程度方向发展。）

回页首

使用一点技巧进行迭代和增量改进

这 是大部分业务和 IT 专业人员的圣杯。多年来，各种方法、技术、工具和技巧层出不穷——最后都会通过信息技术不带偏见且不断发展的大门退出历史舞台。但我们不断的求知欲望会让 我们再次尝试不同的方式，或许采用头脑风暴的方式……嗯，在尝试不同方法的时候可能会就得到给出的 P=?NP 问题的答案！

对于此问题没有完全标准的答案，以下是我对将干系人需求转换为 IT 解决方案的问题的一些看法：

缺乏用于建立共同环境的一致的术语

通常，业务管理人员所使用的语言与 IT 架构师的语言是不同的。业务分析人员/咨询人员在尝试缩小这个差距，但他们通常会加入自己的业务领越的数据和解释，从而使情况变得更为混乱。更为雪上加霜 的是，由于近年来工作和角色的流动性，大多数人会将以前所担任的角色的术语环境和包袱带到新岗位来。我经常在客户会议和需求研讨会上看到术语混淆的情况。

因此，主要需求之一是为在解决方案的业务和技术上下文中使用的所有术语（名词、动词、形容词等）建立清楚、一致、连贯且简洁的（我称为 4C，即 clear、consistent、coherent 和 crisp）定义和语义。这样就为管理人员、分析人员和架构师进行有效的对话建立了基础。是的，为了对术语和模式进行标准化，的确存在跨行业部门——横向 和纵向——的协作活动，但这大部分都在早期阶段进行。我对架构师的建议是这样的：不要对术语的含义想当然，要勇于举手要求澄清。

当转到最佳技术角度时的低效率（或能力缺乏）

可以直接将这个问题简单地描述为锤子-钉子综合症。即，如果您是锤子，所有事项都是钉子。此处，人力元素是一个阻碍因素——这源于我们多年的认知条件作用、我们了解的问题分析和综合模式以及我们习惯的技术领域（通常是我们最具专业知识的领域）。

例如：以数据为中心的架构师将需求集看作是由实体和关系组成的。以状态机为中心的架构师则将其可视化为一系列的状态、转换和动作。以流程为中心的架 构师将需求组织成经过组合的任务和活动。以对象为中心的架构师则将其视为多态类、接口及其关系。现在，我们有以服务为中心的架构师，他们将需求集当作组合 服务组成的拼板。如此等等。每个观点都有其优点和缺点，而架构师务必对每个不同的业务需求或功能应用恰当的视角，这非常重要。显然，决定哪个是“正确的” 视角可以看作相当主观的问题，非常有争议。不过，应用正确的方法可以采用最有效、最典雅且最令人满意的方式实现要求。切换视角有些困难，而尝试完成此工作 甚至是主题专家 (SME) 讨论的最大的话题。为每个视角配备一个 SME 可能会使得体系结构设计过程争议不断，可能会带来大的反复，并且可能出现“分析瘫痪”。

需求验证、优先排序和可跟踪性方面的问题

务必对业务需求进行评审，并与干系人一起进行分析，以合成真正的业务需求。有各种技术（用例、场景）、概念和相关工具用于捕获此工作的结果。但这个 领域不是艺术，并不能靠模仿来掌握，您只能通过全心投入加以适应才能获得相关的专业知识。对每个需求进行了评审后，务必要与干系人就技术看法和一系列解决 方案选择（以及成本效益分析）进行沟通。这个步骤可帮助从技术角度验证需求，也进一步使其与未声明的业务需求保持一致。在验证选项时，请通过讨论来确定各 种不同需求的优先级，并在需求间建立交叉依赖关系。这些需求的依赖关系有助于创建可跟踪性，而且在出现更改请求时扮演着重要的角色。同样，这也不完全是技 术问题。RequisitePro 之类的工具允许您包含一个请求管理模板（基于 RUP 或任何自定义方法），此功能可实现很多方面的自动化，如可跟踪性、需求的状态和构建之间的转换等等。

多年来，各种方法、技术、工具和技巧层出不穷——最后都会通过信息技术不带偏见且不断发展的大门退出历史舞台。 ——Sanjay Bose

还有其他几个问题，如改变业务优先级、更改操作环境、政治与文化壁垒、技能差距和很多其他问题——都可能妨碍解决方案对需求的满足。我和人合作撰写了一篇 IBM Systems Journal 文章“Impact of SOA on Enterprise Systems, Organizational Structures, and Individuals”，谈了一些对其中一些问题的看法。

最后，正如我在最近接受 IDevNews 采访所说的，将业务需求转换为 IT 系统体系结构的一种不错的方法就是采用迭代增量的方式进行（借用了数学上的渐近法）。

回页首

所有需求并非全部同样重要

成熟的组织了解所有需求并非都同样重要。大多数需求本身对体系结构并没有影响；相反，它们与实现有关。某些需求要比其他需求重要很多，只要了解了这个区别，您就能作出更好的决定，以分配资源满足高优先级的需求。直到系统部署完成之后，需求收集才结束。可执行系统的出现会改变干系人看待问题的方式。

这些评论的一个非常重要的隐含意义——正如 Don Ferguson 所指出的——就是成熟的组织会执行迭代增量的流程，这些流程的主要构件都是可执行的。这样就强行让开发团队有规律地开展工作，新需求可以在开发过程中不断地发现，旧需求会重新确定优先级（有时会将其丢弃），而最重要的，每个需求都会针对实际情况而不是文档进行度量。

回页首

了解真正的需求

我 观察到的一点就是，业务部门在了解自己的需求方面并不在行，而 IT 部门如果假设业务部门能够很好地了解自己的需求，则犯了一个很大的错误。就像病人去看医生，要求得到科学的治疗一样，业务部门通常以所需的解决方案来表述 自己的需求，而不是他们希望实现的业务成果。在我实际遇到的客户中，业务团队会说“我们需要新的保险索赔系统。”不过，他们真正需要的却是将他们在处理索 赔方面的效率提高 X% 或降低成本 Y% ，或者其他类似的说法。新的索赔系统可能提供也可能不提供这个改进，但如果实际需求未知，则几乎可以肯定不会提供这种改进。

就像病人去看医生，要求得到科学的治疗一样，业务部门通常以所需的解决方案来表述自己的需求，而不是他们希望实现的业务成果。 ——Kurt Bittner

由于不清楚真正的需求，需要将更多的精力放在帮助由业务人员和 IT 人员组成的扩大团队了解真正的需求。通常需要专家级辅助人员来帮助指导讨论并消除争议。我完全同意 Kerrie 所说的，最大的挑战是“人员问题”，这个问题是由业务和 IT 之间的价值认识不一致及目标不同、不同文化和组织间执行不同目标的奖励结构不同而引起的。即使世界上最好的工具也不能克服这个问题，而且，实际上还有可能 会使得情况更糟。强大的工具放在不能胜任的工匠手中只会导致材料报废的速度更快。

有时候，回避人为因素，而尝试使用技术解决问题会更为简单一些。人员和组织不喜欢变化，而大部分改进都要求进行大幅度更改，如果不能满足这个要求，通常会导致组织无法缓和所遭遇的文化/价值隔阂问题。

回页首

使用表述良好的需求武装业务分析人员

可以对业务需求进行捕获、解释并转换为将为业务提供支持的功能和非功能 IT 要求。

业务需求是通过对业务流程、业务目标、业务实体类型和决策过程的业务模型的分析捕获的。业务需求应或可以通过一组关键性能指标进行度量，以便提供有关实现要求和满足业务需求方面的成功程度的反馈。

它们是通过一个对变化进行划分、分解、细化、映射和分析的过程（面向变化的分析和设计）解释的。划分是将业务域分解为域组成类型或功能区域。这表示 结构划分。业务的分解是对如何将流程分解为子流程和用例的解释。分解过程将创建一个分层结构，而细化过程则将这个分层结构细化为一组可操作的面向目标的交 互序列。

（业务）流程建模对了解业务如何工作非常重要。有些人更喜欢采取用例建模或业务用例的方式。就最终目的而言，此过程就是记录面向目标的业务活动的动态或流方面的特征。 ——Ali Arsanjani

将业务需求映射为 IT 要求的过程需要能证明给定业务要求是可跟踪的，而且受到一组互补的 IT 功能的支持（这些 IT 功能由非功能方面提供支持）。此映射通常通过目标-服务建模完成。我们将逐个研究各个变化，并表示流程、域/功能领域和规则间的共同之处。

将需求转换为 IT 服务的过程可以通过组合使用以下互补的技术来完成：

• 域分解（包括流程分解、功能区域分析和面向变化的分析）
• 目标-服务建模
• 分析现有资产（包括现有系统、打包的应用程序和任何我们可以利用的资产，如标准、框架、各个领域的专用语言等等）

此过程的关键在于在给定时间框架内标识难点和业务相关的驱动因素，更改将存在于此框架外，因而需要应用面向变化的分析。我们将随后以这些重要的出发点为基础，将我们的理解细化为可操作的 IT 要求，可以通过组合功能和非功能要求来满足这些 IT 要求。

简单项目的需求管理在范围和深度方面与一系列业务或企业与价值链都有所不同。我们曾说过，业务需求通常是一个时间点的剪影，可能会发生彻底的变化。 业务功能的区分通常不会随着时间而发生彻底变化，而会更加细化。基本功能最后将成为最终解决方案的一部分，但任何情况下都应由 IT 系统加以支持。

每个领域也都在其中嵌入了可以用于表述该领域的问题的语言。了解这个基础语义对于了解需求背后的意图（从而提供满足这些意图的需求）十分关键。

对于 SOA 或基于组件的方法，我建议使用面向服务的建模方法，这个方法在我的 developerWorks 文章“基于服务的建模和架构”有介绍。

（业务）流程建模对了解业务如何工作非常重要。有些人更喜欢采取用例建模或业务用例的方式。就最终目的而言，此过程就是记录面向目标的业务活动的动态或流方面的特征。

业务需求的实现是通过实现一系列基础 IT 功能和非功能要求而达成的。能以声明的方式表达这些要求——使用业务域提供的服务的语法和语义——非常重要。通过这个功能，业务分析人员可以参与到软件开发生命周期中来。

回页首

没有捷径，立即动手，不要等待

IT 架构师在项目的生命周期的初始阶段扮演的主要角色之一是捕获关于干系人的需求的信息。IT 架构师必须听取客户和干系人的看法，理解他们的业务需求，并系统地以增量方式形成 IT 解决方案的结构更为详细的结构。这个过程通常不仅是靠通过经验积累就能完成的，而且必须为一种有所控制的方法。

生活中的两个事实也可应用到 IT 解决方案的开发中：

几乎没有真正的捷径。
最好现在就动手，而不要等待。

我和客户一起工作时，我常常发现在构建 IT 解决方案中为软件开发项目记录的需求级别非常少。这种定义缺乏的原因是由于将业务需求细化为可操作的 IT 要求是一项很困难的工作，需要经验丰富的人员（这就是为什么 IT 架构师是极其宝贵的资源的一个原因）。将业务需求细化为 IT 要求是一项艰巨的任务，需要将精力放在细节上，而且是一个迭代的过程。

此处要指出的是，您必须花大量的时间来详细说明您的解决方案的需求。统计数据表明，在前期花的时间越多，在开发过程的后期阶段花的时间就越少，从而 可以缩短开发周期。如果无法足够详细（以便能通过技术加以实现）而清晰地将干系人的需求用书面形式表述出来，您就没有完成捕获项目要求的任务。

有很多方法可用于将业务需求细化为较高抽象级要求，然后再将此类要求细化为技术 IT 要求。建模是从干系人捕获初始功能要求集的一个主要方法。通过创建用例、建模过程流和形成统一建模语言（Unified Modeling Language，UML）交互关系图，您可以开始将业务要求细化为更为详细的定义，系统必须支持或启用所定义的这些功能。在复杂环境中会使用包括以下内 容的更为复杂的方法：

• 组件业务建模 (Component Business Modeling)
• 面向服务的模型体系结构

这些方法可以确保 IT 要求与业务目标一致，从而让公司能够真正实现 SOA 的价值主张。

如果无法足够详细（以便能通过技术加以实现）而清晰地将干系人的需求用书面形式表述出来，则您就没有完成捕获项目要求的任务。 ——Holt Adams

从需求进行转换来选择要用于构造解决方案的技术或产品可能成为一个挑战。架构师从过去项目中获得的经验将影响这些决策，但架构师还必须忠实地对每个 要求（对满足需求极为重要的 IT 功能）进行评估。确定了 IT 功能后，架构师可以将这些功能映射为体系结构组件（然后映射到技术和产品），从而以增量的方式向他们的解决方案结构添加更为详细的定义。在开发解决方案的 体系结构时，架构师应该利用工具的功能类捕获和管理要求，对业务组织、需求和流程进行建模，细化并将要求映射到 IT 功能，并标识体系结构组件和技术/产品。

回页首

关于专家

Bobby Woolf

Bobby Woolf 是一位 IBM Software Services for WebSphere 顾问，负责帮助客户成功实现 WebSphere 产品。他与人合著了 Enterprise Integration Patterns 和 The Design Patterns Smalltalk Companion。请参阅 developerWorks 上 Bobby 的博客，以了解更多信息。

Andras Robert Szakal

Andras Robert Szakal 是 IBM Federal Software Group 的首席架构师，同时也是杰出工程师和高级认证 IT 架构师。他还是 The Open Group 理事会成员。

Mark Linehan

Mark Linehan 是 IBM Software Group Emerging Technologies 部门的高级技术人员。在过去几年中，他一直致力于业务规则技术方面的工作。以前，Mark 曾开发过基于加密技术的通信协议，并设计和开发过各种通信软件。

Calvin Lawrence

Calvin Lawrence 是 IBM Software Group Emerging Technology 团队的一位执行架构师。他的职责范围包括通过关键策略活动的支持来推广战略 IBM 体系结构、技术和产品，和使用 IBM 技术确保客户实现成功。他是 IBM Software Group Worldwide Technical Leadership Council 的前主席。

Christina Lau

Christina Lau 是 On Demand Development 团队的一名架构师。她目前参与的项目包括创建 Pattern Solutions using Rational Software Architect 和试用业务创新和优化功能。Christina 是一位高级技术人员，同时也是 IBM Academy of Technology 的成员。她还是新书 Introduction to IBM Rational Application Developer 的合著者。

Simon Johnston

Simon Johnston 是 IBM Rational Software 的一位高级技术人员。他曾参与过 Rational Software 的大量与标准相关的活动，目前在 IBM 从事 XML、Web 服务和建模。请访问 developerWorks 上 Simon 的博客。

Kerrie Holley

Kerrie Holley 是 IBM 的 Services Oriented Architecture and Web Services Center of Excellence 的首席技术官。他擅长的领域包括软件工程、体系结构以及将业务需求转换为以网络为中心的分布式解决方案的设计。

Donald F. Ferguson

Donald Ferguson 是 IBM 的 200,000 技术雇员中的 53 个 IBM 名士（IBM 最高的技术职位）之一。Don 还是 IBM Software Group 的首席架构师。Don 是 SWG Architecture Board 的主席，该委员会监督 WebSphere、DB2® Information Management、Lotus®、Tivoli® 和 Rational® 产品的体系结构和集成。Don 原来曾担任过 WebSphere 系列产品的首席架构师。他于 1985 年加入 IBM Research。他的兴趣爱好包括带他的孩子们、和他们玩耍、分布式系统、简化应用程序开发、系统管理、Web 服务、事务处理、性能以及空手道。请访问他的博客：Middleware and tools。

Sanjay Bose

Sanjay Bose 供职于 IBM Software Strategy 部门，负责 Enterprise Integration Design Center，该中心对 IBM Software 投资组合需求进行标识，并通过参与企业客户和 IBM Software 产品开发实验室的工作来开发解决方案组件和资产。他有超过 12 年的 IT 行业从业经验，主要涉及创建产品体系结构、设计和细化技术策略以及使用分布式技术设计企业应用程序系统。他擅长的领域包括 SOA、Enterprise Service Bus (ESB)、Web 服务、Java™ 2 Platform Enterprise Edition (J2EE) 和电子商务技术。他与人合著了 SOA Compass 一书，并在 IBM developerWorks and Systems Journal 上发表了一些文章。他目前在宾夕法尼亚州匹兹堡居住和工作，业余时间他喜欢参加哲学讲座、读书、看到电影和玩 Sony PlayStation。请参阅他的博客：SOA, ESB, and beyond。

Grady Booch

Grady 是 IBM 的名士，曾参与过全球几乎能想象得到的所有领域的很多复杂的以软件为中心的系统，在其中担任架构师或体系结构顾问。Grady 编写过六本畅销书，发表了数百篇关于软件工程的文章，其中包括在上个世纪 80 年代早期发布的数篇论文，后来从这些论文中发展出来了面向对象的设计的术语和实践。请访问他的博客：Software architecture, software engineering, and Renaissance Jazz。

Kurt Bittner

Kurt Bittner 从事 IBM Rational 软件的产品策略工作。二十三年来，他一直在尝试寻找更好的方法来帮助团队开发软件。他曾是早期 RUP® 开发团队的一员，曾负责过很多行业的开发团队的工作。不进行软件开发工作时，他喜欢的休闲活动是攀爬冰瀑。Kurt 和 Ian Spence 合作编写了 Use Case Modeling（Addison-Wesley，2003 年）和 Managing Iterative Software Development（Addison-Wesley，2006 年即将出版）。

Ali Arsanjani

Ali Arsanjani 博士是 IBM Global Services 的 SOA and Web Services Center of Excellence 的首席架构师，主要负责收集和制定 SOA 和 Web 服务的建模、分析、设计和实现方面的最佳实践。他是内部 IBM 全球 SOA and Web Services Community of Practice（拥有 4000 名成员）的负责人，是 SOA 的面向服务的建模和体系结构（Service-Oriented Modeling and Architecture，SOMA）方法的主要作者之一。他目前的工作重点是支持建模 (SOMA)、评估、策略与计划、管理、体系结构和实现的 SOA 工具，以及其在 IBM 内部和外部的实际应用。请访问他的博客：Best Practices in Service-Oriented Architecture。

Holt Adams

Holt Adams 是 IBM Software Group Emerging Technology 团队的执行 IT 架构师，目前在支持 IBM 的 jStart 计划和 Customer Innovation Team。作为解决方案顾问 IT 架构师，他的工作职责包括将客户的业务需求和信息技术相结合，以将其包含到 IBM 产品中，或设计为新产品。在 jStart 计划和其他服务相关工作中任职期间，他涉及的技术领域包括无线/普及计算、Internet 基础结构、Java/J2EE、XML、Web 服务/SOA、富 Internet 应用程序及 LAMP (Linux、Apache、MySQL、PHP、Perl 和 Python) 技术。他也是本月 Insight and Outlook 专栏的供稿编辑。

了解 IBM 有洞察力的专家和领先技术开拓者对 IT 架构师在目前及将来面临的问题的评述，了解他们的观点与展望。本月，他们将对以下问题进行讨论：为什么应该考虑 SOA？何时应当选择 SOA，何时又不应该选择 SOA？

欢迎阅读观点与展望专栏

欢迎阅读第一期观点与展望，IBM 技术专家将在此 developerWorks 专栏中就 IT 架构师需要及时解决以完成其工作的问题提供指导。每个月，我们都将拜访 IBM 内部架构师社区（包括最知名的有洞察力的人、标准组织的投稿人、我们产品团队的架构师和每天与客户接触的顾问），邀请他们与大家分享他们对目前 IT 和软件架构师面临的最重要问题的看法。

无论您是跨越全球的大型团队的架构师，还是刚刚开始学习 IT 体系结构技术与实践的新手，他们的回答都将给您提供帮助，为您带来灵感并促进您的积极参与。这些观点和看法并不一定十分全面。有关此处涉及的主题的更多指导信息，可以参考 developerWorks Architecture area 的另一部分：IT Architecture resource round-up。另外，如果您有具体问题需要询问专家，或希望发表讨论，则请访问 developerWorks IT 体系结构讨论论坛。

回页首

引言

面向服务的体系结构 (SOA) 已成为了一项事实标准， 用于开发基于组件的应用程序，可使用标准接口通过网络（Internet 或其他网络）访问这些应用程序。至少 IBM 高级管理人员和很多其他供应商、分析师、顾问和软件开发人员都这么说。他们还将告诉您，整个行业都在逐步采用 SOA，如果您尚未开始 SOA 开发，将很快跟不上时代的步伐了。

赞誉之词。但这些看法是否真的很有吸引力，能让您开始着手您自己的 SOA 吗？让我们来看看一位参加 Open Group 主办的 SOA 大会的架构师的问题。在 IBM Global Services 副总裁 Michael Liebow 的主题发言后 的提问期间，这位架构师问道：“SOA 是不是我们需要知道的唯一体系结构？（顺便提一下，Liebow 先生的回答是“是的”）在稍后，另一位架构师大声问道：“SOA 和我们多年前就知道的组件体系结构很相似。如果我们采用了它，是否意味着我们又多添了一个技术竖井（另一个开发死胡同），从而需要进行更多的集成？”（而 这次，会议参加者——包括平台供应商、企业 IT 架构师、顾问、系统集成商和其他人员——回答的是“不是。”）

这就提出了我们本月要向我们的专家询问的问题。如果您和 IBM 最近接触的很多架构师一样，那么您可能正在评估甚至采用 SOA 的过程中。但您可能仍在怀疑这是否是体系结构样式的必由之路，新东西很快由更为流行的东西取代，或者，这个体系结构是否真的适用。

我们的专家对此问题的回答包含了很多您之前听到的说法：SOA 促进了可重用性，提供了接口和实现之间的抽象级别以最小化依赖关系，将业务需求与 IT 功能结合，从而可以为您提供用于将业务需求转换为编程服务来实现流程自动化的机制，以及当前竞争激烈且快速变化的业务环境中所必需的灵活性，等等。另外， 这些专家还根据他们与 IBM 内外开发先驱合作的实践经验提供了一些新颖的看法，将帮助您了解 SOA 在何时如何（甚至为什么）适合在您的 IT 体系结构和开发计划中使用。

在此对本月的专栏供稿编辑 Holt Adams 表示感谢。Holt 是 IBM Software Group 团队一位经验丰富的 IT 架构师，就您将要读到的内容为内部 IBM 社区提供了指导。他还提供了他自己对这个问题的回答“何时采用 SOA，何时不采用 SOA。”

好了，不再多说，下面就请了解一下我们的专家的观点吧。（有关回答问题的专家的更多信息，请参阅本专栏最后的关于专家。）我们邀请您就 SOA 提出您的看法。您可以访问我们的 IT 体系结构讨论论坛，或通过以下地址给我发电子邮件：pdreyfus@us.ibm.com。

Paul Dreyfus，编辑
developerWorks SOA and Web services

回页首

何时采用 SOA，何时不采用 SOA

IBM 的目标之一是在其产品内开发和采用开放标准。通过这样做，就能在您公司的 IT 基础结构中实现 SOA 的价值主张。SOA 能够优化业务需求与 IT 的一致性，能够将业务流程活动从服务实现中分离出来，还能够降低操作成本。只有在不固定供应商的情况下才能真正实现这些功能，此时面向 SOA 实现的技术可以无缝集成（考虑：“开放标准”），以构造全面的端到端解决方案。

不可轻易决定实现 SOA。这与改变生活方式有些类似，因为开发和操作团队遵循的 IT 控制模式将完全不同。 ——Holt Adams

当考虑了策略业务目标和活动时，理论上的 SOA 概念非常具有吸引力，更加容易得到支持。不过，不可轻易决定要实现 SOA。这与改变生活方式有些类似，因为开发和操作团队遵循的 IT 控制模式将完全不同。我提倡进行业务驱动开发。此过程涉及到将业务需求细化为 IT 要求，然后将 IT 要求细化为 IT 功能，以确定满足这些需求所需的技术。根据我过去四年开发基于 Web 服务的解决方案和更为成熟的基于 SOA 的解决方案的经验，以下这些相关因素通常会让我建议采用面向服务的体系结构：

• 集成成本持续增长，而并未因为可提供真正投资回报 (ROI) 的新业务机会而得到缓解。
• 兼并和收购是您公司扩大市场份额和获得新发展机会的业务模式的核心。
• 解决方案要求对来自异构系统和编程模型的业务功能进行集成。
• 业务的生存依赖于根据市场变化快速调整或即时响应竞争威胁的能力。
• 全球经济的影响要求您的公司事半功倍地开展业务，而且有必要依赖业务合作伙伴提供非核心业务功能。
• 就提高收益而言，与业务合作伙伴协作的效率对您的公司十分关键。
• 您公司业务资产的价值在减少，因为不能对其进行评估，以在最初用途之外的其他地方使用。
• 您公司员工的效率出现了问题，因为他们的大部分时间并没有花在提供公司业务模型的核心功能和服务上。
• 您公司的业务充满了机会型的业务工作。
• 您公司从头开始开发新应用程序。（我认为 SOA 应当作为定位将来的新应用程序的缺省体系结构样式，业务条件有其他限制时除外。）

在理想情况下，您和您的业务合作伙伴间没有预算限制、计划期限、技能差距和优先级差异，我想，此时完全可以说每个人都会采用 SOA，或者至少会考虑采用 SOA。不过，我们的选择实际上经常受到过去的决策的影响和限制（例如，技术投资、编程模型采用、服务的合同协定等）。因此，我们并不能总是自由地采用看 起来能满足某个业务需求或技术要求的最佳选项。以下的注意事项会让我不建议采用面向服务的体系结构或说明现在实现 SOA 的边际收益：

• 您公司只将小部分 IT 预算用于集成活动。
• 您公司的大部分流程都是手动的或以文档为中心的，自动化的机会几乎为零。
• 您公司的大部分应用程序开发都使用相同的编程模型。
• 您公司的操作由一个或两个客户关系管理 (CRM) 和企业资源规划 (ERP) 应用程序管理，几乎没有集成要求。
• 您公司的现有技能库与实现支持 SOA 的基础结构所需的技能库之间存在重大差异。
• 未发现可从 SOA 提供的功能受益的业务需求或机会。
• 新业务服务的可用性将对现有的收益流带来负面影响。
• 您公司依赖的业务合作伙伴对公司间流程的自动化采用了不同的优先级。
• 您公司的主要业务的开展涉及到海量且同步性和实时性要求非常高的事务。

前面的列表只是一个示例，用以说明 SOA 是否是您公司最佳选择的原因。当然，每个合同或项目都具有唯一的要求，因此关于何时采用 SOA 的决策取决于您公司的业务状况。SOA 的价值主张十分诱人，但选择何时让您的公司采用 SOA 必须考虑业务环境的实际情况。采用 SOA 不一定要跨一大步，而通常是采用循序渐进的方式进行的。首先找到可以利用 SOA 概念和原则的项目，然后使用主要性能指标测定其价值，这是一种让大家受益的好方法。

回页首

将业务与 IT 结合起来

SOA 不仅是一个开发范例。该体系结构用于在业务和 IT 之间构建中间地段，其中包含双方都同意的一组与业务一致的 IT 服务，这些服务结合在一起，以实现组织的业务流程和目标。此范例提供了前所未有的灵活性：它允许将业务流程的结构化组成从为流中每个活动提供功能的服务中 分离出来。它还允许将业务实现与其描述分离开来。进行了此分离后，公司能以增量的方式更改其后端遗留系统，并添加新功能来支持新需求，而不用受到供应商选 择的限制。因此，可以在最小化对业务流程和 IT 系统的影响的前提下对软件包和自定义应用程序进行替换。

将访问功能从其实现分离的下一步工作就是 SOA。而且，除了此功能方面外，我们还可以将非功能方面外部化。例如，我们可以根据建立的业务策略确定哪些人应该可以访问特定的功能。我们还可以定义如何管理希望以灵活的、可重构的方式访问的技术资源。

使用 SOA 技术时，实时或被动系统通常不是进行实现的最佳选择，因为当前的技术不支持将 SOA 用于有大量并发使用情况的实时系统。不过，这些系统的建模也可以从 SOA 提供的分离和独立概念获益。 ——Ali Arsanjani

软件工程发展的下一步就是此体系结构。它使我们从结构化对象转向分布式对象和组件，然后以一组公共服务为中心来将业务和 IT 加以结合（这些服务结合在一起，可以实现组织的流程和目标）。SOA 还允许将公司的部分业务流程向生态系统中的合作伙伴公开。

当需要支持业务灵活性的 IT 灵活性时，就可以使用 SOA。因此，对于两个程序需要进行通信并访问组合业务流程的行业应用程序而言，就非常适合选择 SOA。

使用 SOA 技术时，实时或被动系统通常不是进行实现的最佳选择，因为当前的技术不支持将 SOA 用于有大量并发使用情况的实时系统。不过，这些系统的建模也可以从 SOA 提供的分离和独立概念获益。

SOA 非常适合用于消除冗余及将业务与未紧密耦合到特定服务实现的 IT 功能相结合。它可以允许服务使用者选择后备服务提供者（不仅基于功能进行选择——我需要类似的功能，但不要此版本的服务中的额外依赖项，还可以基于设计及 运行时策略和 Web 服务管理功能进行选择）。

企业体系结构基于 SOA 的公司具有稳定的基础，能从现有系统概念地抽象业务功能。它们还具有允许随着新软件包、系统和资产的提供和新需求的出现以增量的方式进行业务驱动的 IT 转换的基础。

回页首

一个重要但略显不足的机制

在 企业范围中，大量的创新都出现在以下两个方面：企业边缘和企业之间。在边缘上，我们可以看到在中间件之上的框架投入了很多精力（独立于领域的框架，如 Ajax，以及特定于领域的框架，以特定行业为中心进行结合），也投入了很多精力进行与设备相关的工作 [ 典型的移动设备和具有无线频率识别（Radio Frequency Identification，RFID）标记的设备 ]。而在企业之间，我们可以看到系统（遗留系统和新系统）的系统的形成。

在边缘，服务提供超越基础技术的行为。而在企业之间，服务提供了各种系统间语义丰富的强大通信方式。 ——Grady Booch

在此类以 Web 为中心的系统中，服务已被证实为这两个方面的重要机制。在边缘，服务提供超越基础技术的行为。而在企业之间，服务提供了各种系统间语义丰富的强大通信方式。

虽然这样说，但在系统的构造中，服务是一个重要却略显不足的机制。这样说有些过于简单化，但总的说来，服务对于高频率或非常小粒度的连接而言，并不非常适合。而且，服务当然不是唯一适合各个系统的体系结构的分解机制。

回页首

SOA、Web 服务与优势保持

SOA 是一个使用得有些过量的首字母缩写，被从高级管理人员到开人员等各方面的人用（滥用）来传达多种（有时候是不一致的）语义。在我看来，面向服务的体系结构 是一个框架，用于将业务流程和支持技术基础结构作为标准化且管理良好的组件——服务——进行集成，可以对服务进行组合、重用和调整以满足不断变化的业务优 先级。

SOA 新手认为 SOA 和 Web 服务是等效的。可能存在不使用任何 Web 服务，而使用现有 IT 资产（从大型机事务到基于对象的系统）的基于 SOA 的有效解决方案。而且，我曾经看到过几个从部门级别发展出来的不是有效 SOA 应用程序的 Web 服务实现。这些 Web 服务岛通常并不完全遵循所有的核心 SOA 原则和特征——它们可能不是松散耦合、未抽象、不可重用、未组件化或不是独立于平台和协议的，最重要的是，它们可能不提供真正的业务价值。

由于 Web 服务提供了一个 Level 字段，供基础结构和应用程序供应商进行创新和互操作，很多规范、概要、术语都使得这一混淆扩大化了。Web 服务仅是一个标准和技术的集合（还有很多其他技术支持选项），用以实现基于 SOA 的解决方案。

在快速发展的全球经济环境中，企业要保持竞争优势，必须保持足够的灵活性。通过使用 SOA 原则将 IT 基础结构与核心企业流程结合，可以提供和保持这个优势。因此，理解和采用 SOA 所面临的问题不是如何或为什么，而是什么时候？基于 SOA 的企业解决方案已被证实能简化业务操作、提高效率、降低成本及消除冗余。

我们正处在对解决方案生命周期的每个方面进行改革的浪尖上，而 SOA 则是关键的催化剂。不过，从长远来看，如果我们不谨慎的话，这个抽象和易用性可能会使 IT 架构师或开发人员和计算机科学与技术的根本基础脱离联系。 ——Sanjay Bose

不过，为了获得这些好处，必须正确地应用 SOA。必须具有相应企业范围内的远景和转换路线图，必须有业务执行人员的财务支持和承诺，并由有经验的架构师以增量迭代的方式进行部署。这些增量步骤应 该首先针对关键业务问题进行，最终的解决方案应该能提供业务价值。这样可以帮助保持和促进使用 SOA 进行端到端企业转换。在采用 SOA 的过程中，SOA 将不断遇到各种重大的挑战，其中包括政治和文化的多样性。

从纯技术角度而言，SOA 平台（包括工具和运行时）也在经历着巨大的转变。开发工具环境包含大量的建模工具、行业根深蒂固的场景、重用模式、方案和丰富的可视表示和控件以及模拟技 术。运行时也同样在不断发展，从而提供增强的服务质量、声明性的和基于策略的管理和吸引人的管理和监视 Dashboard（针对 IT 事件和业务事件），并使用具有自我修复功能的自动工具进行检测。我们正处在对解决方案生命周期的每个方面进行改革的浪尖上，而 SOA 则是关键的催化剂。不过，从长远来看，如果我们不谨慎的话，这个抽象和易用性可能会使 IT 架构师或开发人员和计算机科学与技术的根本基础脱离联系。

[ 编者注：有关此主题的更多观点，可以参考 Sanjay Bose 最近与人合著的新书 SOA Compass:Business Value, Planning, and Enterprise Roadmap（此书是 IBM Press 和 Prentice-Hall 联合出版的 developerWorks 系列丛书之一）。

回页首

模型驱动的开发和虚拟企业

您 可能已经选择使用 SOA 了。大部分中型和大型企业都在其应用程序设计中应用了 SOA 元素。结构良好的 CICS® 和 IMS™ 程序通常符合 SOA 的要求。很多公司已构建了由消息驱动的应用程序组成的分布式系统。会话 Enterprise JavaBean 就是“类 SOA 的”。很多 ISV 系统都采用类似于服务的构造；例如 SAP IDocs。SOA 将结构良好的分布式系统的指南系统化，是结构化编程、模型对象 (OO) 的概念的子集和消息驱动的处理的自然发展。

在很短的时间内，我们行业的运行时互操作性和开发工具间的互操作性就达到了前所未有的水平。这个互操作性降低了迁移到 SOA 的成本，从而更容易获得其带来的好处。 ——Don Ferguson

Web 服务是一组用于构建 SOA 解决方案的标准。基础结构供应商 (IBM、BEA、Microsoft) 和应用程序供应商 (SAP、Oracle) 正像采用任何软件技术一样迅速地采用 Web 服务。在很短的时间内，我们行业的运行时互操作性 [简单对象访问协议（Simple Object Access Protocol，SOAP）、HTTP、WS-Security、WS-ReliableMessaging] 和开发工具间的互操作性 [Web 服务描述语言（Services Description Language，WSDL）、WS-Policy、Business Process Execution Language for Web Services (BPEL4WS) ] 就达到了前所未有的水平。这个互操作性降低了迁移到 SOA 的成本，从而更容易获得其带来的好处。

都有什么好处呢？此处将不详细讨论全部或任何单个好处。我将简要地提一下两个好处：

• SOA 支持模型驱动的开发和从业务透视图进行解决方案监视。我们通过使用 WebSphere® Business Modeler 产生一个允许分析人员和业务专业人员进行推断和设计他们的业务流程的工具，从而有了很大进步。SOA 操作是流程中的任务或步骤的自然呈现，而组合服务的实现（BPEL4WS，业务状态机）则是流程的自然表示。根据简单业务规则（使用 WebSphere Process Server 启用），WS-Policy 和服务实现这两种方法都是业务策略的自然表示。
• Web 服务支持“虚拟企业”。MQ 和 Common Object Request Broker Architecture (CORBA) 等以前的技术主要针对企业内计算进行了优化。Web 服务协议和 WSDL 在 Internet 和内部网络中均可工作。这样就能使用以前用于企业内部应用程集成的相同模型来在 Internet 上实现简单的、快速开发的机会型 B2B 了。

回页首

控制问题

SOA 与已在 IT 行业存在了 30 年甚至更长时间的其他软件模块化流程相似。SOA 所不同的硬件和网络已足够成熟，可以支持这项基于标准的技术。从任何方面而言，SOA 都不是过去行业内的风行的热潮技术，但包含了广泛的行业标准和支持。

SOA 为企业提供了一个机会，以标识其核心能力和决定是否将这些核心能力作为服务向其行业和业务合作伙伴提供。另一方面的事实是；企业可以对作为其核心基础结构 （不是核心能力）一部分的流程和应用程序进行标识，然后确定进行购买。请注意，其中一些服务（提供的或购买的）可能仅为业务流程。企业架构师可以牵头开展 相应的工作，以发现企业中具有公共功能集的业务流程和 IT 流程。可以将执行功能打包为外部依赖性很小的组件，并作为服务提供。这就使得业务流程创建者或应用程序开发人员的工作得到简化，以将精力放在能满足股东的 业务动力的唯一功能上。

让 SOA 正常工作在很大程度上不是技术问题。让 SOA 正常工作是一个业务控制和 IT 控制问题。 ——David K. Jackson

让 SOA 正常工作在很大程度上不是技术问题。让 SOA 正常工作是一个业务控制和 IT 控制问题。技术专家可以根据很多存在的成功模式构造一个 SOA 实现。然后让企业使用这些服务，而不再自己进行创建，这是另一个问题。恰当的体系结构控制将对其服务可供新应用程序使用的项目进行标识。要使得 SOA 投资最终能物有所值，唯一的办法就是让高级管理人员承诺控制预算，或采取某种方式保证业务线能不受干扰。IT 架构师还需要向执行股东报告业务从其 SOA 投资和投入方面获得的价值。

为了让 SOA 与业务合作伙伴协作，需要涉及企业已经建立的关系。现在，很少（如果有）客户在其建立的合同关系之外为合作伙伴提供或购买服务。服务级别协议和争议解决的 相关事项要求配备封闭的协作系统。有关信任和安全的结构化信息系统发展组织（Organization for the Advancement of Structured Information Systems，OASIS）标准在过去两年中取得了长足的发展，但在等式的法律和业务一边，仍然更倾向于和企业已经了解的伙伴开展此类业务。

回页首

这里没有神话

关于为什么应该考虑 SOA 有三个简单的理由：

1. 这是目前最热门的领域之一；不要落后于时代的步伐。

2. 工具、基础结构和标准经过组合，可为整个 SOA 生命周期提供全面支持。了解我们的端到端编程模型。按照其中提供的详细步骤开展工作，亲身体验成功。

3. 如果您和我们一样不断地追求事半功倍，那么 SOA 可以为您提供帮助。寻找您可以再次利用的东西；不要所有东西都自己从头做起。寻找现有服务，对其进行调整，并加以使用。然后对其中一些服务进行共享。帮助 创建一个生态系统，以便在将来能更快地装配更多有意义的解决方案。

可以通过常识来看这个问题。如果您的项目处于十分关键的位置，而您的团队必须投入大量精力学习工具和 API，SOA 就有可能是错误的选择。如果可以在小项目中试用 SOA，则是不错的选择。 ——Christina Lau

开始采用 SOA 与采用任何其他技术或体系结构没有什么区别。可以通过常识来看这个问题。如果您的项目处于十分关键的位置，而您的团队必须投入大量精力学习工具和 API，它就有可能是错误的选择。如果可以在小项目中试用 SOA，则是不错的选择；利用这个经验，可以帮助您定义和扩展到下一个更大的项目。循序渐进，这里没有神话。

回页首

只是业务而已

SOA 的支持者不断不畏余力地宣传 SOA 的主要技术优势：松散绑定，能够通过组件封装可重用业务功能，最后（但没有像通常那样刻意强调）还能提供更好的集成。

包括我自己也是 SOA 的支持者之一，但我不断在问自己一个问题：客户真的对这种技术推论感兴趣吗？

在过去两年，我一直在与希望获得 SOA 产生的价值主张的客户全面合作。在与客户沟通时，我经常发现客户认为，有很多其他体系结构能提供比我所提到的更多的技术价值。有些客户可能一厢情愿地得出 结论，认为非常有经验的架构师和开发团队可以通过使用传统企业应用程序集成 (EAI) 体系结构获得很大价值。很多客户会争辩说，这些方法经过验证，实现风险并没有直接采用 SOA 进行设计的风险大。

虽然我们不知道其解决方案到底是什么样的，但应当客观地看待每一个问题。请同时根据技术指标和业务指标来确定是否采用 SOA。 ——Calvin Lawrence

这个观点可能会让架构师认识到在有些情况下，SOA 是错误的选择，或者，至少不是最好的选择。SOA 的技术可行性是否是选择其作为解决一系列业务问题的体系结构方法的原因？我会说不是：很多业务及 IT 相关的问题（例如缺乏有力的企业控制模型和策略）将减慢或阻碍任何构思良好的技术 SOA 活动的实现。

在最近一次为期三天的 SOA 研讨会上，一位汽车行业的首席技术官 (CTO) 告诉我下面的话：“我对 SOA 看法是‘只是业务而已’。”他告诉我他采用 SOA 的原因在于：

• 提高他和他的团队实现新产品和流程或更改现有项目的速度
• 降低实现和拥有成本
• 通过外包业务元素或从固定定价改为可变定价（根据业务量），从而支持灵活的定价模型
• 简化合并和收购所需的集成工作
• 实现更好的 IT 使用率和投资回报

这位 CTO 和他的团队仅关心如何使用其现有的技能（而不必放弃其现有的基础结构）在预算内按时达成这些目标。他们已经在其现有 EAI 基础结构中进行了大量投资。

这位特别的 CTO 的话与很多其他人的说法都不一样。他们只关心关键之处：我如何为股东提供回报？

当然，作为一个有经验的架构师（微笑），我知道一些解决此问题的体系结构备选方案：

1. 扩展其现有的 EAI 基础结构
2. 计划采用更多的事件驱动体系结构（完全分离的、发布/订阅，等等）
3. 或许可采用 SOA

由于这是一个 SOA 研讨会，而客户为此付费，因此我最初准备选择第三个选项。实际上，对于这个情况，我使用了一点 EAI，一点事件驱动和很多 SOA 方面的东西。SOA 允许在必要时包含 EAI 和事件驱动方法。

对于高速发展的汽车行业，为了保持竞争优势和按时在预算内提供产品，企业必须具有灵活性。这个客户的难点集中在对其业务流程进行管理和合并。正如我 的同事在此讨论中指出的，将 IT 基础结构与核心业务流程结合，对于达成目标十分关键。SOA 相关的原则已被证明可以简化业务操作，能减少与实际代码关系很小而集中在人机交互和人员活动上的冗余项。在资金有限的业务环境中，几乎没有客户能为解决特 定的业务问题无限制地投入资金，而有时间并愿意对其控制流程进行修整的客户则更少了。这样做听起来不错，但却不会实际这样做。

关键在于对现有基础结构、流程和现有控制模型加以利用和扩展。通过恰当地使用现有 SOA 原则，可以对整个设计和实现流程进行管理，如：

1. 标识问题。
2. 标识组成业务并是难点所在的流程。
3. 对这些流程进行建模，以对其进行简化。
4. 标识现有服务，并编写表示这些流程的其他服务。
5. 将这些服务部署到可提供运行时功能且操作效率高的环境中。
6. 监视这些服务和流程，以获得更高的效率。

那么，网络呢？虽然我们不知道其解决方案到底是什么样的，但应当客观地看待每一个问题。请同时根据技术指标和业务指标来确定是否采用 SOA。如果合适，就使用它。如果不合适，就不用它。SOA 概念和原则将始终可以通过某种方式应用到您的体系结构中。

回页首

康庄大道

我们现在都应该知道了整个行业对 SOA 的 ROI 和采用的赞颂之词——松散耦合、重用更好、推向市场的时间更短、易于集成以及互操作性更好。不过，务必了解，我们目前对 SOA 的关注只是实现即插即用企业（或者说是按需企业）的历程中重要的一步而已。

随着我们进入下一个十年，我们将开始着手大幅度减少将来自不同 IT 供应商的产品或组件组合成可行的有价值的端到端解决方案所需的工作量。供应商提供的业务组件将不依赖于基础结构，可以在各种平台上执行。因此，软件开发人 员会将更多的精力放在有效集成供应商组件和确保有效的互操作性上。

IT 业务操作部门所属的人员将是业务和企业体系结构专业人士。无论您是如何定义业务或企业架构师的：为了实现这个远景，整个行业将需要更多的具有 IT 和企业体系结构背景的人士。 ——Andras Szakal

客户的 IT 操作部门将主要负责选择最适合业务需求的运行时平台；即提供恰当部署和管理业务组件所需的必要服务质量和运行时支持的平台。

相反，IT 业务操作部门将主要关注如何通过定义业务组件（将由其对应的操作人员部署和管理）中包含业务规则实现组织的业务策略。这将通过 WebSphere Business Process Server 之类的业务流程管理系统完成。

IT 业务操作部门所属的人员将是业务和企业体系结构专业人士。无论您是如何定义业务或企业架构师的：为了实现这个远景，整个行业将需要更多的具有 IT 和企业体系结构背景的人士。

虽然这个远景可能十分诱人，仍然存在很大的风险，在进入组件天堂之前，我们必须小心地减小这些风险。在开始进行实现模型服务的体系结构的任务时，最 重要的减小风险方法可能就是要求有强有力的管理良好的控制流程和策略。只有通过强有力的企业服务控制策略才能够避免更改管理问题、服务间的语义不匹配和系 统功能结合方面出现的难于调试的问题。IT 部门可以通过制定的控制策略来减少风险，这些控制策略由执行监督团队（其中包括 CIO、CTO 和业务线执行官）提出并加以支持。

回页首

改善信息

当然，您已经对 SOA 有所了解了。您也知道 Web 服务、业务流程的重要性、模型驱动的体系结构和所有这些让人诚惶诚恐的 WS-* 标准。

但或许您是一名信息人员。您需要负责组织的信息的完整性和对其进行分析。您关心表示业务状态的数据库的性能和稳定性。正如您所知的，真正重要的部分。因此，您可能会问：“为什么我应该关心 SOA？”

SOA 表示的不仅是服务提供者和使用者的协定，而且也是信息提供者和使用者间的协定 ——Dan Wolfson

作为信息人员，我很关心 SOA。我之所以关心 SOA，是因为 SOA 具有直接和间接影响信息管理系统的能力——事实上可以影响信息本身。为了获得成功，我们需要在业务服务所涉及的信息的上下文中对其进行考虑。我们需要知道 检索到的信息是准确的。被更新的信息经过了验证。交换的信息的意义对于服务提供者和使用者都是一样的。如果忽略了这些事情，服务的价值和可重用性就会减 少。

直接来说，使用 SOA 时，我们需要在提供者和使用者之间形成一个信息协定，以便让各方知晓信息意义的内涵，并且仍然支持异构系统——换句话说，我们必须假定世界是杂乱无章的， 必须对其进行整理，以提高信息的价值，了解不同的结构和意义之间的关系，并在可能的情况下就公共对象达成一致。

将信息作为服务公开还将让我们配备额外的信息服务器拓扑来容纳增加的信息负载。它还会要求我们建立可以对信息访问进行虚拟的点（这样用户就无需知道 信息的真正位置以及其组织方式）。它还引入了一些方法，允许我们有效地对这些信息进行组合——通过集合或联合。如果没有建立更多的公共机制或引入经过改进 的清除机制，则我们稍后很可能被迫投入巨额的额外资金和资源进行清除，从而导致将来的灵活性下降。

可以采用很多办法实现信息协定。其中一个变得越来越重要的就是主数据管理 (MDM) 领域。MDM 系统可为业务应用程序或服务提供经过清除、整合且特定于域的信息。最常见的 MDM 系统是作为客户和产品信息的信息集线器使用的系统。每个集线器都作为中心点使用，可以在此对信息进行添加、更新、审核、清除、搜索和查询。集线器放置于可 以将更改传播到相关数据库或可以生产相关服务的事件的位置。MDM 系统可以是事务型的（在操作业务流程的主线中更新），也可以是引用型的（提供业务流程所引用的信息的一致来源）。但最重要的是，我们可以将 MDM 系统看作其本身提供了一个一致的服务集，以供在各种业务流程内使用和进行重用。

通过 MDM 等方法显式地实现信息提供者和使用者之间的协定，可以帮助我们实现 SOA 所承诺的灵活业务流程和服务可重用性，并同时为我们提供提高所管理信息的质量的机会。

回页首

适合与不适合的场合，以及需要注意的地方

SOA 是一种组织化的方法，用于应用到由面向服务和分布式对象计算组合而成的应用程序体系结构中。让我们来将这个定义分为几部分进行分析。应用程序体系结构 是应用程序各部分的宽泛组织，通常作为层实现。体系结构指定包含哪些部分以及它们如何一起工作。面向服务将功能封装为服务——宽泛的可重用任务，可以在没 有任何前一上下文（除承载服务的系统的当前域状态外）的情况下运行。服务的上下文是作为从调用方传递的参数提供的，和函数调用的参数非常相似。分布式对象 以特定方式运行在独立进程中，通过这种方式，一个进程中的对象可以调用另一个进程中的对象上的方法。

服务支持对访问通过宽泛任务的经过良好定义的 API 公开的已良好封装的功能，从而可以通过低频率的调用实现功能的高重用性。SOA 或许是所有方法中最好的一个。 ——Bobby Woolf

SOA 向分布式对象添加面向服务，从而可以在进程之间调用服务。它是一种用于设计应用程序体系结构的方法，以便应用程序的各个部分可以在不同的进程中运行，而且 还允许不同的应用程序共享和重用正在运行的部分。它是分布式对象计算的演变，用以在多个对立方之间获得更好的平衡：需要访问彼此功能的应用程序；需要封装 自己功能的应用程序；需要限制在其应用程序编程接口 (API) 中描述的对外公开的功能的应用程序；需要限制分布式调用的交互应用程序。服务支持访问通过各种任务定义良好的 API 公开的封装良好的功能，从而可以通过低频率的调用实现功能的高重用性。SOA 或许是所有方法中最好的一个。

以下给出了一些简单的技巧，用以确定何时采用 SOA 和何时不应采用 SOA 以及需要提高警惕的情况。

首先，适合采用 SOA 的情况：

• 当数据分布程度非常高时，使用 SOA。将操作数据的代码放置在与数据较近的位置，然后将其包装为服务，以供在任何地方进行访问。
• 希望功能具有高可用性时，使用 SOA。将功能作为服务部署在多个冗余的提供程序中，以在其中一些不可使用时，可以使用其他的对等服务。
• 当应用程序的各个部分需要独立开发、维护和更新时，使用 SOA。只要保持各个部分之间的接口，每个团队（如两个不同的 B2B 公司）就可以使用其喜爱的技术按照自己的计划实现各自的部分。
• 当多个应用程序需要重用功能和数据时，使用 SOA。共享的代码仅重用功能；服务则允许各个独立应用程序重用一组共享的企业数据，而无需将数据分发给所有应用程序。

以下是不适合使用 SOA 的情况：

• 当希望开发尽可能简单时，不要使用 SOA。使用一种语言实现，在单个线程中运行，且没有远程访问问题的应用程序复杂性较低一些，因此构建和调试更为方便。
• 当希望操作环境尽可能简单时，不要使用 SOA。要对松散耦合、事件驱动的分布式应用程序进行故障排除要困难得多，要求对应用程序实现细节和操作环境配置细节及其当前状态有全面的了解。
• 当网络不可靠或网速慢时，不要使用 SOA。服务组件运行于独立的计算机上，通过网络进行通信，因此，其速度和可靠性依赖于这些计算机及连接这些计算机的网络。
  （注：分布式冗余服务可以帮助减少硬件不可靠和网络延迟的影响。）
• 进行原型设计时，不要使用 SOA。原型开发应该简单，而 SOA 并不简单。

对于何时需要提高警惕的问题，坦白地说，随时都要提高警惕才行。以下是一些需要谨慎行事的具体情况：

• 当服务接口不确定时，使用 SOA 需小心。服务接口允许使用者和提供者独立地进行更改，但接口本身必须稳定。SOA 中的接口变化比在单个应用程序（特别是非分布式应用程序）中复杂得多，因为有很多在其他情况下不相关的开发团队必须就接口的更改进行合作。
• 当安全性极为重要时，使用 SOA 需小心。每个服务都是一个新的易受攻击的点，必须保证其安全性。可以轻易访问服务的人越多（如在公共 Internet 上的服务），可以尝试攻击该服务的人就越多。
• 当性能极为重要时，使用 SOA 需小心。进程之间的每个服务调用都比进程内的方法慢得多。
• 希望功能具有高可用性时，使用 SOA 需小心。正如所指出的，冗余服务可以提高可靠性；但同时，活动部分越多出现故障的可能性就大。SOA 应用程序只与其服务一样可靠。

这些列表根本不足以包含所有方面，但我希望这能让您更好地了解什么是 SOA 以及适合使用 SOA 的情况。如果您需要这方面的专业帮助，请访问 IBM Software Services for WebSphere，在其中可以找到各种参考资料。

祝您好运！

回页首

关于专家

Holt Adams

Holt Adams 是 IBM Software Group Emerging Technology 团队的执行 IT 架构师，目前在支持 IBM 的 jStart 计划和 Customer Innovation Team。作为解决方案顾问 IT 架构师，他的工作职责包括将客户的业务需求和信息技术相结合，以将其包含到 IBM 产品中，或设计为新产品。在 jStart 计划和其他服务相关工作中任职期间，他涉及的技术领域包括无线/普及计算、Internet 基础结构、Java/J2EE、XML、Web 服务/SOA、Rich Internet 应用程序及 LAMP 技术。他也是本月观点与展望专栏的供稿编辑。

Ali Arsanjani

Ali Arsanjani 博士是 IBM Global Services 的 SOA and Web Services Center of Excellence 的首席架构师，主要负责收集和制定 SOA 和 Web 服务的建模、分析、设计和实现方面的最佳实践。他是内部的 IBM 全球 SOA and Web Services Community of Practice（4000 名成员）的负责人，是 SOA 的面向服务的建模和体系结构（Service-Oriented Modeling and Architecture，SOMA）方法的主要作者之一。他目前的工作重点是支持建模 (SOMA)、评估、策略与计划、管理、体系结构和实现的 SOA 工具，以及其在 IBM 内部和外部的实际应用。请访问他的博客：Best Practices in Service-Oriented Architecture。

Grady Booch

Grady 是 IBM Fellow，曾参与过全球几乎能想象得到的所有领域的很多复杂的以软件为中心的系统，在其中担任架构师或体系结构顾问。Grady 编写过六本畅销书，发表了数百篇关于软件工程的文章，其中包括在上个世纪 80 年代早期发布的数篇论文，后来从这些论文中发展出来了面向对象的设计的术语和实践。请访问他的博客：Software architecture, software engineering, and Renaissance Jazz。

Sanjay Bose

Sanjay Bose 供职于 IBM Software Strategy 部门，负责 Enterprise Integration Design Center，该中心对 IBM Software 投资组合需求进行标识，并通过参与企业客户和 IBM Software 产品开发实验室的工作来开发解决方案组件和资产。他有超过 12 年的 IT 行业从业经验，主要涉及创建产品体系结构、设计和细化技术策略以及使用分布式技术设计企业应用程序系统。他擅长的领域包括 SOA、Enterprise Service Bus (ESB)、Web 服务、Java™ 2 Platform Enterprise Edition (J2EE) 和电子商务技术。他与人合著了 SOA Compass 一书，并在 IBM developerWorks and Systems Journal 上发表了一些文章。他目前在宾夕法尼亚州匹兹堡居住和工作，业余时间他喜欢参加哲学讲座、读书、看电影和玩 Sony PlayStation。请访问他的博客：SOA, ESB, and beyond。

Donald F. Ferguson

Donald Ferguson 是 IBM 的 200,000 位技术雇员中的 53 个 IBM 名士（IBM 最高的技术职位）之一。Don 还是 IBM Software Group 的首席架构师。Don 是 SWG Architecture Board 的主席，该委员会监督 WebSphere、DB2®、Lotus®、Tivoli® 和 Rational® 产品的体系结构和集成。Don 原来曾担任过 WebSphere 系列产品的首席架构师。他于 1985 年加入 IBM Research。他的兴趣爱好包括带他的孩子们、和他们玩耍、分布式系统、简化应用程序开发、系统管理、Web 服务、事务处理、表演以及空手道。请访问他的博客：Middleware and tools。

David K. Jackson

David K. Jackson 是 IBM Americas Software Sales 的一位顾问 IT 架构师，是常驻 New York Technical Exploration Center 的 IT 架构师。同时，他还是 Open Group Architecture Forum 的副主席。The Open Group 是一个 IT 行业标准组织，是 X-open 和 Open Software Foundation 合并而成的。Open Group Architecture Forum 已制定并发布了唯一的行业标准企业体系结构开发方法。Open Group 还于 2005 年建立了一个 IT 架构师认证计划，对 IT 行业中的 IT 架构师的含义进行了定义。

Calvin Lawrence

Calvin Lawrence 是 IBM Software Group Emerging Technology 团队的一位执行架构师。他的职责范围包括通过关键策略活动的支持来推广战略 IBM 体系结构、技术和产品，和使用 IBM 技术确保客户实现成功。他是 IBM Software Group Worldwide Technical Leadership Council 的前主席。

Christina Lau

Christina Lau 是 On Demand Development 团队的一名架构师。她目前参与的项目包括创建 Pattern Solutions using Rational Software Architect 和试用业务创新和优化功能。Christina 一位高级技术人员，同时也是 IBM Academy of Technology 的成员。她还是新书 Introduction to IBM Rational Application Developer 的合著者。

Andras Robert Szakal

Andras Robert Szakal 是 IBM Federal Software Group 的首席架构师，同时也是杰出工程师和高级认证 IT 架构师。他还是 The Open Group 理事会成员。

Dan Wolfson

Dan Wolfson 在 IBM Software Group 中担任 Master Data Management 产品的首席架构师。Dan 是 IBM 杰出工程师，曾与 IBM 内的涉及业务集成、原数据和信息集成方面的团队展开过广泛的合作。Dan 在研究商业分布式计算方面具有 20 多年的经验，曾涉猎事务和面向对象的系统、编程语言、消息传递和数据系统等。

Bobby Woolf

Bobby Woolf 是一名 IBM Software Services for WebSphere 顾问，负责帮助客户使用 WebSphere 实现成功。他与人合著了 Enterprise Integration Patterns 和 The Design Patterns Smalltalk Companion。请访问 developerWorks 上 Bobby 的博客，以了解更多信息。

IBM 专家将提供各自的个人观点，以推动 IT 体系结构实践方面的发展，从而帮助您更好地担当架构师这一职责。

引言：IT 体系结构不像电视节目

注意：有关观点与展望 专栏的全面的信息，请参阅以前的部分：

• “第 1 部分：选择 SOA 的原因和时机”
• “第 2 部分：如何将业务需求转转换为 IT 要求？”

我希望能有电视节目展示 IT 架构师的生活。但您知道在电视上的样子。人们都很了不起，通常长得很好看，手边有所有需要的东西，他们都异常的聪明——而且所有部分都非常轻易地就整合到 一起了。您可能看着这样的节目，而忘记了他们的实际工作有多困难。暂时逃避一下现实。而且，每周您都有机会假装这就是真实的生活。

我们都知道，和生活一样，IT 体系结构并不是这样的。（真是的，撰写这个专栏甚至也不那样简单，只是纯粹说说才很简单。）需要进行培训，需要努力工作，需要使用技能技巧，会犯很多错误，而且需要很多的耐心。当然，说需要一定天分也未尝不可。

知道了成为一个成功的 IT 架构师需要投入多少工作后，我们就想知道哪些因素对成为一个不错的架构师起决定性作用。因此，我们向专家组提出了这样的问题：“什么技能对 IT 架构师最有价值，架构师如何学习这些技能？”

可以在很多地方找到成为好的架构师所需的技能列表——书上、培训课程、大学、有关体系结构的其他网站上等等。例如，IBM 的内部专业提高网站就提出以下几点 IT 架构师的理想特征：

• 设计体系结构的技能和经验
• 有序的以方法为驱动源的任务执行
• 完整生命周期经验
• 行业部门经验
• 领导能力
• 很强的沟通和专业技能

和可能看到的很多其他列表类似，这个列表相当泛泛，可能并不如您所期望的那样有可操作性。而这正是我们询问前面的问题的原因所在：帮助您确定一个明确的方向。

我们希望对此问题的讨论能为您提供帮助。我们鼓励您在 IT 体系结构讨论论坛发表您对这些观点的看法。如果您有任何问题希望我们的专家进行答复，请与我联系。充分利用专家资源——他们非常乐意为您提供帮助，非常愿意能推动 IT 体系结构方面的实践。

Paul Dreyfus，编辑
developerWorks SOA and Web services
pdreyfus@us.ibm.com

另，为了避免对我们的排序方式的意见，我们已根据专家的名字按字母顺序对专栏进行了排序。不过，请一定阅读全文；您肯定不希望漏掉 Walker Royce 的连珠妙语。

回页首

权衡各个相互冲突的需求

架构师必须 学习权衡各个相互冲突的需求的技能。在调和体系结构的各个组成部分时，我们必须对各个看起来截然相反的事项进行权衡，如下面这些事项：

• "“我需要一个全新的体系结构来支持一个新业务需求；所有项目必须在 2 年内完成，而我们希望您能在 1 年内完成下一个项目。”"
• "资金有限，但我们希望能提供所有功能。"
• 分析瘫痪与“直接编码”
• 灵活方法与复杂方法
• 用户期望与技术可实际提供的功能
• 业务与 IT
• 您的工作负担和享受生活
• 管理活动（时间计划、支出）与“真正的”项目工作

无论从技术角度出发，还是就业务角度而言，我们都需要对经常冲突的各种考虑和各个侧面进行权衡。在看起来似乎无法解决的情况下进行正确的权衡是架构师成功的关键。

这经常意味着要首先确定有哪些约束，理解这些约束为何存在冲突，并确定如何在问题空间对这些考虑进行权衡，从而解决所面临的问题。

回页首

了解各个相关部分以及它们彼此如何结合

我 还记得我第一次感觉像个架构师时的情况。他们要求我开发一个新的应用程序，突然我发现这个应用程序并不是一个单体，而是由多个专门化的部分组成的，其中的 每个部分都在专门的服务器上运行，所有部分一起协作，形成一个应用程序。数据由数据库服务器承载和提供，长时间运行的流程在工作流服务器中执行，遗留集成 会通过消息传递服务器进行操作，而自定义代码在应用服务器上运行，负责将所有这些部分粘合到一起。

这就是体系结构：专门化的彼此不同的部分一起协作，形成完整的应用程序。IT 架构师知道如何将问题划分为专门化的各个部分，并使其作为整体一起协同工作。

那么，什么是对 IT 架构师最具价值的技能呢？就是要了解这些不同类型的服务器以及其提供来帮助解决问题的不同功能，并要了解如何将它们一起使用来开发和部署应用程序。成为一 个引擎方面的专家也非常诱人，如数据架构设计人员、规则专家、J2EE 开发人员。团队也需要这样的人员，但他们不是架构师。IT 架构师至少对所有这些方法都有所了解，了解哪个引擎适合用于执行应用程序中的何种任务，知道如何将应用程序分解成各个专门化的部分以及如何使这些部分一起 工作。

实际上，这是 IT 软件 架构师。真正的 IT 架构师不仅需要了解软件，也要了解以下内容——甚至可能还要包括其他方面的东西：

• 硬件：服务器计算机、网络路由器、延迟、防火墙、操作系统等等
• 安全性：标识管理、访问控制、保密性、认可等等
• 资源规划：内存使用、带宽、负载、负载平衡、故障转移、高可用性等等

需要学习很多内容，但软件方面无疑可以作为一个很好的起点开始学习。

如何学习这些技能呢？您需要逐个学习各个部分，并学习如何将其作为整体结合使用。首先要学习如何实现各个部分，如何使用每种类型的引擎。不知道工作流到底是什么？获取 WebSphere Integration Developer 并实现 HelloWorld 业务流程执行语言（Business Process Execution Language，BPEL）流程。不了解消息传递？阅读 developerWorks 上介绍如何使用服务集成总线的简单示例的文章。学习了每种服务器的细节知识后，请将这些细节放在一边，而将精力放在每种引擎所能完成的任务的全局状况上。 消息传递、规则、工作流、数据和自定义代码——这些都彼此不同，但差异在哪里呢？了解了这一点后，您将能够把应用程序划分为多个部分，从而利用每种引擎的 独特功能。

此时您就成为了一名 IT 架构师。

回页首

快速学习

您所应具有的唯一最有价值的技能？

快速学习新事物的能力。这一点适用于我们这个不断发展的行业的很多角色，而不仅是 IT 架构师。

那么，如何学习这个技能呢？

我是在读大学时学到这项技能的。从那以后，我们忘记了在那里学习过的很多东西，包括 Lisp、微分方程等。但我保留了快速学习这一技能。

回页首

沟通和推动力

无 论何时问我 IT 架构师的工作是怎样的——这个问题与他们的最重要技能直接相关——我都会将其与建筑设计师相比较。IT 架构师处在客户（CEO、LOB 执行人员）和构建人员（IT 开发/交付），能够向客户说明技术可能性和向构建人员说明客户的需求。这意味着 IT 架构师必须能够在这两个领域进行清楚的表述、说明，并在这两方面都提出中肯的意见。

显然，对这个职位而言，沟通和推动力是其关键的技能。IT 架构师使用他们的经验和直观推断来将暂时的定义欠佳的问题空间简化为能够构建和交付的内容，并同时始终以客户的需求为工作的核心。

回页首

沟通和倾听

毫无疑问：沟通的能力。成功的架构师必须能够清楚、明了、简洁地对体系结构决策进行描述、演绎和申辩。高效的架构师还必须能够使用各种媒体（包括代码、模 型、文档、PowerPoint 演示文档以及谈话和讲座）与各方面的技术和非技术干系人进行沟通——包括代码编写人员和其他开发人员，甚至最终用户、会计师和行政官员。另外，真正高效的 架构师不仅善于表述概念，同时也是相当出色的听众，能够按照预期计划完成讨论任务。

如何学习这项技能？练习，练习，再练习。

回页首

进行连接

在我看来，IT 架构师所具有的最有价值的技能是将各个部分连接起来的能力。为了将分散或看起来不相关的组件（问题）联系起来，以形成一个完整的系统。可以从完整的系统派生出在实效和策略方面都有意义且可行的解决办法。

这就是将架构师与专业人员区分开的一项技能：通过全局性的视图，可以更全面地看待整个系统并了解其他一些注意事项，从而帮助您确定哪些是重要内容， 哪些是干扰信息。此技能也能在不同角色身上和不同情况下发挥作用，不受技术、行业和职务级别的影响。具有这种能力的技术架构师可以帮助在业务和技术之间建 立联系。

如何获得此技能：体验学习。接触架构师工作的解决方案的子项目或子组件，不断询问自己这些问题：“为什么这个重要？”和“我的这一部分解决方案与什么相关？”尝试了解各个部分如何形成更大的完整程序。从外向内了解各个部分。

一种称为思维导图的创造性思考技术异常有帮助。——Jenny Choy

如何学习此技能：我发现，对于尝试学习和进行全局思维实践的人来说，一种称为思维导图的创造性思考技术异常有用。（思维导图是由 Tony Buzan 于 20 世纪 60 年代末提出的，用以帮助人们开发大脑潜能。）这项技术可帮助您捕获和组织各个想法（或组件），能在单页中体现各个组件的多层次分解和组件的相关关系。由于 与某个主题相关的所有内容的全貌都呈现在单个页面上，这就训练大脑在相关上下文中看待所有事项，并允许对有兴趣的主体进行进一步分解，且同时保持对全局情 况的了解。

回页首

对可能遇到的问题进行预先估计

我 认为 IT 架构师必须具有的最重要技能是能够对在复杂环境中对可能出现的性能和吞吐问题进行事先估计，并进行恰当的决策来避免这些问题。这项技能与了解此类问题的分 类、诊断根源和进行相应决策来解决这些问题的能力直接相关。只有一个真正的老师：实际处理具有代表性的各个实际（即“生产”）系统的各种问题。我不认为只 具有应用程序开发经验而没有实际操作经验的人具有成为高效的架构师所需的经验。

很多工程方面的造诣依赖于理解和分析故障以了解根源的实践。而这个技能正是我所要讨论的技能——系统地对故障和性能问题进行分析，然后对问题进行细化，以确定根源。IT 架构师首先需要能够对潜在的吞吐问题进行预先估计，并设计恰当的解决方案来防止发生此类问题。

回页首

基本学习：学习如何进行学习

我希望能给出一个更为简单的问题，但为了成为成功的架构师，您需要具有出色的基本学习 技能。我对基本学习的定义是，学习如何高效地进行学习。目前，成功的架构师需要具有大量的技能，要不断地对旧技能进行更新并能快速地掌握新技能。如果不能 获得和应用新技能，将可能缩短架构师的职业生涯。但出色的基本学习技能将为架构师提供不断扩展的灵活技能库——可根据需要进行灵活调整。这就让架构师能够 完成其工作的复杂要求，非常专业地处理各个方面，如：

• 理解和列出各个问题/解决方案的相关事项
• 分析新场景和复杂场景
• 分析和确定解决方案要求的范围
• 对解决方案元素进行可视化和概念化工作
• 对解决方案模型和模式进行合成
• 应用（学习）各种新技术和最佳实践
• 评估和区分解决方案概念/设计/提案
• 研究备选选项
• 与业务和技术干系人进行有效沟通

除了通过固有的基本学习能力外，还可以通过一些其他方式来获得此技能：

1. 良好的学校教育，特别是大学阶段的教育，在此阶段的课程涉及范围非常广泛，课程的密集型较强，同学之间的竞争也较为激烈。我在 Mumbai 的 IIT (Indian Institute of Technology) 进行大学本科的学习期间学习的很多精华课程的细节都已经遗忘了，但这段经历提升了我的出色的基本学习技能。那些考试前的十一个小时的填鸭式学习也对此有所 贡献。 ;-)
2. 通过多年担任各种角色和承担各种职责积累的专业经验和实践。在进行工作时，总是尝试进入对自己有所挑战的区域。这些区域将提升和加强您的基本学习 技能。我最初是在一家《财富》10 强金融机构（非常诱人！）担任分析师，随后从事了多年的技术咨询工作（从芯片设计、内核/OS 编程到 UI 框架等多个领域）。然后，我加入了一家刚刚创立的公司，在其中帮助定义产品体系结构。（在这种新创建的公司里可以真正学到如何担当多面手！）现在我已在 IBM 担任过多个具有独特挑战的角色。

回页首

深入研究，同时眼观全局

我认为架构师所需的最重要技能是能够深入钻研可能会带来较大好处的特定技术问题，并同时能够考虑到更大的组织目标和体系结构。

例如，在分析 Web 应用程序的性能时，如果所耗的大部分时间（如 90%）都花在数据库服务器上的密集型数据库搜索、查询和数据聚合上了，则通过调整 Web 表示层的算法并不会带来太多改善。关键是能够处理查询性能问题（如果您是专家）或找到能够及时解决问题的专家。进行此类推理要求具有分析技能，能考虑更大 范围内的情况和进行恰当的折衷，并同时对特定技术领域进行深入分析。

那么如何学习这项技能呢？通过实际接触多个项目、向同事学习以及了解和利用体系结构模式和最佳实践。

回页首

合成正确的解决方案

一个好的架构师能够合成正确的解决方案（或判断候选解决方案或现有解决方案的宏观质量），却无需了解实现的所有精确细节。

有能力的架构师是天生的，而不是培训出来的。有潜质的人可以进行培养，但如果您天生就不能领悟多维的“美丽”，您可以永远也学不会。因此，一个更好的问题是，如何能确定那些天生就具有架构师能力的人并培养他们的相关技能呢？

这方面我也不确定。

回页首

关于专家

Ali Arsanjani

Ali Arsanjani 博士是 IBM Global Services 的 SOA and Web Services Center of Excellence 的首席架构师，主要负责收集和制定 SOA 和 Web 服务的建模、分析、设计和实现方面的最佳实践。他是内部的 IBM 全球 SOA and Web Services Community of Practice（拥有 4,000 名成员）的负责人，是 SOA 的面向服务的建模和体系结构（Service-Oriented Modeling and Architecture，SOMA）方法的主要作者之一。他目前的工作重点是支持建模 (SOMA)、评估、策略与计划、管理、体系结构和实现的 SOA 工具，以及其在 IBM 内部和外部的实际应用。请访问他的博客：Best Practices in Service-Oriented Architecture。

Bobby Woolf

Bobby Woolf 是一名 IBM Software Services for WebSphere 咨询师，负责帮助客户使用 WebSphere 实现成功。他与人合著了 Enterprise Integration Patterns 和 The Design Patterns Smalltalk Companion。请参阅 developerWorks 上 Bobby 的博客，以了解更多信息。

Christina Lau

Christina Lau 是 On Demand Development 团队的一名架构师。她目前参与的项目包括创建 Pattern Solutions using Rational Software Architect 和试用业务创新和优化功能。Christina 一位高级技术人员，同时也是 IBM Academy of Technology 的成员。她还是新书《Introduction to IBM Rational Application Developer》的合著者。

David K. Jackson

David K. Jackson 是 IBM Americas Software Sales 的一位咨询 IT 架构师，是常驻 New York Technical Exploration Center 的 IT 架构师。同时，他还是 Open Group Architecture Forum 的副主席。The Open Group 是一个 IT 行业标准组织，是 X-open 和 Open Software Foundation 合并而成的。The Open Group Architecture Forum 已制定并发布了唯一的行业标准企业体系结构开发方法。The Open Group 还于 2005 年建立了一个 IT 架构师认证计划，对 IT 行业中的 IT 架构师的含义进行了定义。

Grady Booch

Grady 是 IBM Fellow，曾参与过全球几乎能想象得到的所有领域的很多复杂的以软件为中心的系统，在其中担任架构师或体系结构顾问。Grady 编写过六本畅销书，发表了数百篇关于软件工程的文章，其中包括在上个世纪 80 年代早期发布的数篇论文，后来从这些论文中发展出来了面向对象的设计的术语和实践。请访问他的博客 Software architecture, software engineering, and Renaissance jazz。

Jenny Choy

IBM 杰出工程师 Jenny Choy 是 IBM Canada Ltd 的 Business Consulting Services 内 Application Services 的 Transformation Engineering 负责人。她同时也是 IBM Academy of Technology 的成员和认证 IT 架构师。

Kurt Bittner

Kurt Bittner 从事 IBM® Rational 软件的产品策略工作。他 23 年来一直在从事帮助各个团队更好地开发软件方面的工作。他曾是早期 Rational Unified Process (RUP)® 开发团队的一员，负责过很多行业的开发团队的工作。不进行软件开发工作时，他喜欢的休闲活动是攀爬冰瀑。Kurt 和 Ian Spence 合作编写了 Use Case Modeling（Addison-Wesley，2003 年）和 Managing Iterative Software Development（Addison-Wesley，2006 年即将出版）。

Sanjay Bose

Sanjay Bose 供职于 IBM Software Strategy 部门，负责 Enterprise Integration Design Center，该中心对 IBM Software 投资组合需求进行标识，并通过参与企业客户和 IBM Software 产品开发实验室的工作来开发解决方案组件和资产。他有超过 12 年的 IT 行业从业经验，主要涉及创建产品体系结构、设计和细化技术策略以及使用分布式技术设计企业应用程序系统。他擅长的领域包括 SOA、Enterprise Service Bus (ESB)、Web 服务、Java™ 2 Platform, Enterprise Edition (J2EE) 和电子商务技术。他与人合著了《SOA Compass》一书，并在 IBM developerWorks and Systems Journal 上发表了一些文章。他目前在宾夕法尼亚州匹兹堡居住和工作，业余时间他喜欢参加哲学讲座、读书、看到电影和玩 Sony PlayStation。请参阅他的博客：SOA, ESB, and beyond。

Sridhar Iyengar

杰出工程师 Sridhar Iyengar 负责 IBM Rational Software 开发团队的技术策略。他是 OMG Architecture 委员会和董事会的成员，对模型驱动的体系结构标准的发展进行指导。

Walker Royce

Walker Royce 是 Rational Software 团队的老牌成员，目前担任 IBM Software Services Rational 的副总裁。他是《Software Project Management, A Unified Framework》 （Addison Wesley Longman，1998 年）的作者，同时也是 Rational Unified Process 中继承的管理理念的主要倡导者。在加入 Rational 前，Walker 在 TRW Electronics and Defense 从事了 16 年软件开发工作，并获得了 Chairman's Award for Innovation。

参考资料 学习

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
  
  
• 了解关于 developerWorks 技术活动和网络广播的最新消息。
  
  

• 使用 IBM 试用软件开发您的下一个项目，可直接从 developerWorks 下载这些试用软件。
  
  

• 参与 developerWorks 博客，从而参加到 developerWorks 社区中来。

关于作者

		此内容是由 developerWorks 编辑团队为您带来的。如有建议或问题，请通过以下邮件地址与编辑团队联系：dwinfo@us.ibm.com。

In order for such innovations and organizations to survive, the software they depend on must provide the required capability, be of sufficient quality, be available when promised, and be delivered at an acceptable price.

All these characteristics are influenced by the architecture of the software, the subject of this article. My focus here is on "software-intensive systems," which the IEEE defines as follows:

A software-intensive system is any system where software contributes essential influences to the design, construction, deployment, and evolution of the system as a whole. [from IEEE 1471. See the "Architecture defined" section below.]

In this article, the term "architecture," when unqualified, is synonymous with the term "software architecture." Although this article focuses on software-intensive systems, it is important to remember that a software-intensive system still needs hardware in order to execute and that certain qualities, such as reliability or performance, are achieved through a combination of software and hardware. The hardware aspect of the total solution cannot therefore be ignored. This is discussed in more detail later in this article.

Architecture defined

There is no shortage of definitions when it comes to "architecture." There are even Websites that maintain collections of definitions.¹ The definition used in this article is that taken from IEEE Std 1472000, the IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, referred to as IEEE 1471.² This definition follows, with key characteristics bolded.

Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [IEEE 1471]

This standard also defines the following terms related to this definition:

A system is a collection of components organized to accomplish a specific function or set of functions. The term system encompasses individual applications, systems in the traditional sense, subsystems, systems of systems, product lines, product families, whole enterprises, and other aggregations of interest. A system exists to fulfill one or more missions in its environment. [IEEE 1471]

The environment, or context, determines the setting and circumstances of developmental, operational, political, and other influences upon that system. [IEEE 1471]

A mission is a use or operation for which a system is intended by one or more stakeholders to meet some set of objectives. [IEEE 1471]

A stakeholder is an individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system. [IEEE 1471]

As we can see, the term "component" is used throughout these definitions. However, most definitions of architecture do not define the term "component," and IEEE 1471 is no exception, as it leaves it deliberately vague to cover the many interpretations in the industry. A component may be logical or physical, technology-independent or technology-specific, large-grained or small-grained. For the purposes of this article, I use the definition of component from the UML 2.0 specification; and I use the term fairly loosely in order to encompass the variety of architectural elements that we may encounter, including objects, technology components (such as an Enterprise JavaBean), services, program modules, legacy systems, packaged applications, and so on. Here is the UML 2.0 definition for "component":

[A component is] a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. A component defines its behavior in terms of provided and required interfaces. As such, a component serves as a type, whose conformance is defined by these provided and required interfaces (encompassing both their static as well as dynamic semantics).³

The definitions provided here cover a number of different concepts, which are discussed in more detail later in this article. Although there is no generally agreed definition of "architecture" in the industry, it is worth considering some other definitions so that similarities between them can be observed. Consider the following definitions where, again, I've bolded some of the key characteristics.

An architecture is the set of significant decisions about the organization of a software system, the selection of structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these elements into progressively larger subsystems, and the architectural style that guides this organization -- these elements and their interfaces, their collaborations, and their composition. [Kruchten]⁴

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. [Bass et al.]⁵

[Architecture is] the organizational structure and associated behavior of a system. An architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts. Parts that interact through interfaces include classes, components and subsystems. [UML 1.5]⁶

The software architecture of a system or a collection of systems consists of all the important design decisions about the software structures and the interactions between those structures that comprise the systems. The design decisions support a desired set of qualities that the system should support to be successful. The design decisions provide a conceptual basis for system development, support, and maintenance. [McGovern]⁷

Although the definitions are somewhat different, we can see a large degree of commonality. For example, most definitions indicate that an architecture is concerned with both structure and behavior, is concerned with significant decisions only, may conform to an architectural style, is influenced by its stakeholders and its environment, and embodies decisions based on rationale. All of these themes, and others, are discussed below.

An architecture defines structure

If you were to ask anyone to describe "architecture" to you, nine times out of ten, they'll make some reference to structure. This is quite often in relation to a building or some other civil engineering structure, such as a bridge. Although other characteristics of these items exist, such as behavior, fitness-for-purpose, and even aesthetics, it is the structural characteristic that is the most familiar and the most-often mentioned.

It should not surprise you then that if you ask someone to describe the architecture of a software system he's working on, you'll probably be shown a diagram that shows the structural aspects of the system -- whether these aspects are architectural layers, components, or distribution nodes. Structure is indeed an essential characteristic of an architecture. The structural aspects of an architecture manifest themselves in many ways, and most definitions of architecture are deliberately vague as a result. A structural element can be a subsystem, a process, a library, a database, a computational node, a legacy system, an off-the-shelf product, and so on.

Many definitions of architecture also acknowledge not only the structural elements themselves, but also the composition of structural elements, their relationships (and any connectors needed to support these relationships), their interfaces, and their partitioning. Again, each of these elements can be provided in a variety of ways. For example, a connector could be a socket, be synchronous or asynchronous, be associated with a particular protocol, and so on.

An example of some structural elements is shown in Figure 1. This figure shows a UML class diagram containing some structural elements that represent an order processing system. Here we see three classes -- OrderEntry, CustomerManagement, and AccountManagement. The OrderEntry class is shown as depending on the CustomerManagement class and also the AccountManagement class.

Figure 1: UML class diagram showing structural elements

An architecture defines behavior

As well as defining structural elements, an architecture defines the interactions between these structural elements. It is these interactions that provide the desired system behavior. Figure 2 shows a UML sequence diagram showing a number of interactions that, together, allow the system to support the creation of an order in an order processing system. Here we see five interactions. First, a Sales Clerk actor creates an order using an instance of the OrderEntry class. The OrderEntry instance gets customer details using an instance of the CustomerManagement class. The OrderEntry instance then uses an instance of the AccountManagement class to create the order, populate the order with order items, and then place the order.

Figure 2: UML sequence diagram showing behavioral elements

It should be noted that Figure 2 is consistent with Figure 1 in that we can derive the dependencies shown in Figure 1 from the interactions defined in Figure 2. For example, an instance of OrderEntry depends on an instance of CustomerManagement during its execution, as shown by the interactions in Figure 2. This dependency is reflected in a dependency relationship between the corresponding OrderEntry and CustomerManagement classes, as shown in Figure 1.

An architecture focuses on significant elements

While an architecture defines structure and behavior, it is not concerned with defining all of the structure and all of the behavior. It is only concerned with those elements that are deemed to be significant. Significant elements are those that have a long and lasting effect, such as the major structural elements, those elements associated with essential behavior, and those elements that address significant qualities such as reliability and scalability. In general, the architecture is not concerned with the fine-grained details of these elements. Architectural significance can also be phrased as economical significance, since the primary driver for considering certain elements over others is the cost of creation and cost of change.

Since an architecture focuses on significant elements only, it provides us with a particular perspective of the system under consideration -- the perspective that is most relevant to the architect.⁸ In this sense, an architecture is an abstraction of the system that helps an architect manage complexity.

It is also worth noting that the set of significant elements is not static and may change over time. As a consequence of requirements being refined, risks identified, executable software built, and lessons learned, the set of significant elements may change. However, the relative stability of the architecture in the face of change is, to some extent, the sign of a good architecture, the sign of a well-executed architecting process, and the sign of a good architect. If the architecture needs to be continually revised due to relatively minor changes, then this is not a good sign. However, if the architecture is relatively stable, then the converse is true.

An architecture balances stakeholder needs

An architecture is created to ultimately address a set of stakeholder needs. However, it is often not possible to meet all of the needs expressed. For example, a stakeholder may ask for some functionality within a specified timeframe, but these two needs (functionality and timeframe) are mutually exclusive. Either the scope can be reduced in order to meet the schedule or all of the functionality can be provided within an extended timeframe. Similarly, different stakeholders may express conflicting needs and, again, an appropriate balance must be achieved. Making tradeoffs is therefore an essential aspect of the architecting process, and negotiation, an essential characteristic of the architect.

Just to give you an idea of the task at hand, consider the following needs of a set of stakeholders:

• The end user is concerned with intuitive and correct behavior, performance, reliability, usability, availability, and security.
• The system administrator is concerned with intuitive behavior, administration, and tools to aid monitoring.
• The marketer is concerned with competitive features, time to market, positioning with other products, and cost.
• The customer is concerned with cost, stability, and schedule.
• The developer is concerned with clear requirements, and a simple and consistent design approach.
• The project manager is concerned with predictability in the tracking of the project, schedule, productive use of resources, and budget.
• The maintainer is concerned with a comprehensible, consistent, and documented design approach, and the ease with which modifications can be made.

As we can see from this list, another challenge for the architect is that the stakeholders are not only concerned that the system provides the required functionality. Many of the concerns listed are nonfunctional in nature in that they do not contribute to the functionality of the system (e.g., the concerns regarding costs and scheduling). Such concerns nevertheless represent system qualities or constraints. Nonfunctional requirements are quite often the most significant requirements as far as an architect is concerned.

An architecture embodies decisions based on rationale

An important aspect of an architecture is not just the end result, the architecture itself, but the rationale for why it is the way it is. Thus, an important consideration is to ensure that you document the decisions that have led to this architecture and the rationale for those decisions.

This information is relevant to many stakeholders, especially those who must maintain the system. This information is often valuable to the architect when he or she needs to revisit the rationale behind the decisions that were made, so that they don't end up having to unnecessarily retrace steps. For example, this information is used when the architecture is reviewed and the architect needs to justify the decisions that have been made.

An architecture may conform to an architectural style

Most architectures are derived from systems that share a similar set of concerns. This similarity can be described as an architectural style, which can be thought of as a particular kind of pattern, albeit an often complex and composite pattern (a number of patterns applied together). Like a pattern, an architectural style represents a codification of experience, and it is good practice for architects to look for opportunities to reuse such experience. Examples of architectural styles include a distributed style, a pipe-and-filter style, a data-centered style, a rule-based style, and so on. A given system may exhibit more than one architectural style. As Shaw and Garlan describe it:

[An architectural style] defines a family of systems in terms of a pattern of structural organization. More specifically, an architectural style defines a vocabulary of components and connector types, and a set of constraints on how they can be combined.⁹

And in terms of the UML:

[A pattern is] a common solution to a common problem in a given context.¹⁰

In addition to reusing experience, the application of an architectural style (or a pattern) makes our lives as architects somewhat easier, since a style is normally documented in terms of the rationale for using it (and so there is less thinking to be done) and in terms of its structure and behavior (and so there is less architecture documentation to be produced since we can simply refer to the style instead).

An architecture is influenced by its environment

A system resides in an environment, and this environment influences the architecture. This is sometimes referred to as "architecture in context." In essence, the environment determines the boundaries within which the system must operate, which then influence the architecture. The environmental factors that influence the architecture include the business mission that the architecture will support, the system stakeholders, internal technical constraints (such as the requirement to conform to organizational standards), and external technical constraints (such as the need to interface to an external system or to conform to external regulatory standards).

Conversely, as eloquently described in Bass, Clements, and Kazman,¹¹ the architecture may also influence its environment. Not only does the creation of an architecture change the environment from a technology perspective -- it may, for example, contribute reusable assets to the owning organization -- the creation of the architecture may also change the environment in terms of the skills available within the organization.

When it comes to software-intensive systems, there is a particular aspect of the environment that must always be considered, as discussed earlier in this chapter. In order for software to be useful, it must execute. In order to execute, the software runs on some kind of hardware. The resulting system is therefore a combination of both software and hardware, and it is this combination that allows properties such as reliability and performance to be achieved. Software cannot achieve these properties in isolation of the hardware on which it executes.

IEEE Std 12207-1995, the IEEE Standard for Information Technology -- Software Life Cycle Processes, defines a system differently from the IEEE 1471 system definition noted earlier (which focuses on software-intensive systems), but is in agreement with the definitions found in the systems engineering field:

[A system is] an integrated composite that consists of one or more of the processes, hardware, software, facilities and people, that provides a capability to satisfy a stated need or objective. [IEEE 12207]¹²

[A system is] a set of resources that provide services that are used by an enterprise to carry out a business purpose or mission. System components typically consist of hardware, software, data, and workers¹³.

In the systems engineering field, tradeoffs are made regarding the use of software, hardware, and people. For example, if performance is key, then a decision may be made to implement certain system elements in hardware, rather than software or people. Another example is that in order to provide a usable system to customers, a decision is made to provide a customer interface that is a human being, rather than an interface implemented in software or hardware. More complex scenarios require certain system qualities to be achieved through a combination of software, hardware, and people. (Accordingly, this series of articles makes reference to elements other than software where appropriate.)

It is interesting to note that systems engineering is specifically concerned with treating software and hardware (as well as people) as peers, thus avoiding the pitfall where hardware is treated as a second-class citizen to the software and is simply a vehicle for executing the software, or where software is treated as a second-class citizen with respect to the hardware and is simply a vehicle for making the hardware function as desired.

An architecture influences team structure

An architecture defines coherent groupings of related elements that address a given set of concerns. For example, an architecture for an order processing system may have defined groupings of elements for order entry, account management, customer management, fulfillment, integrations with external systems, persistency, and security.

Each of these groupings may require different skill sets. It therefore makes perfect sense to align software development team structures with the architecture once it has been defined. However, it is often the case that the architecture is influenced by the initial team structure and not vice versa. This is a pitfall that is best avoided, since the result is typically a less-than-ideal architecture. "Conway's Law" states that "If you have four groups working on a compiler, you'll get a 4-pass compiler." In practice, we often unintentionally create architectures that reflect the organization creating the architecture.

However, it is also true to say that this somewhat idealized view is not always practical since, for purely pragmatic reasons, the current team structure and the skills available represent a very real constraint on what is possible and the architect must take this into account.

An architecture is present in every system

It is also worth noting that every system has an architecture, even if this architecture is not formally documented or if the system is extremely simple and, say, consists of a single element. There is usually considerable value in documenting the architecture. Documented architectures tend to be more carefully considered -- and therefore, more effective -- than those that are not, since the process of recording the architecture naturally leads to thoughtful consideration.

Conversely, if an architecture is not documented, then it is difficult (if not impossible) to prove that it meets the stated requirements in terms of addressing qualities such as maintainability, accommodation of best practices, and so on. Architectures that are not documented, which appear to be the majority in existence today, tend to be accidental rather than intentional.

An architecture has a particular scope

There are many kinds of architecture, the best known being the architecture associated with buildings and other civil engineering structures. Even in the field of software engineering, we often come across different forms of architecture. For example, in addition to the concept of software architecture, we may encounter concepts such as enterprise architecture, system architecture, organizational architecture, information architecture, hardware architecture, application architecture, infrastructure architecture, and so on. You will also hear other terms, each of which defines a specific scope of the architecting activities.

Unfortunately, there is no agreement in the industry on the meaning of each of these terms or their relationship to one another, which results in different meanings for the same term (homonyms) and two or more terms meaning the same thing (synonyms). However, the scope of some of these terms can be inferred from Figure 3. As you consider this figure and the discussion that follows, there are almost certainly elements of it that you disagree with or that you use differently within your organization. But that is exactly the point -- to show that these terms do exist in the industry, but that there is no consensus on their meaning.

Figure 3: The scope of different terms

The elements shown in Figure 3 are:

• Software architecture, which is the main focus of this article as defined earlier.
• A hardware architecture, which considers elements such as CPUs, memory, hard disks, peripheral devices such as printers, and the elements used to connect these elements.
• An organizational architecture, which considers elements that are concerned with business processes, organizational structures, roles and responsibilities, and core competencies of the organization.
• An information architecture, which considers the structure by which information is organized.
• Software architecture, hardware architecture, organizational architecture, and information architecture, which are all subsets of the overall system architecture, as discussed earlier in this chapter.
• An enterprise architecture, which is similar to a system architecture in that it, too, considers elements such as hardware, software, and people. However, an enterprise architecture has a stronger link to the business in that it focuses on the attainment of the business objectives and is concerned with items such as business agility and organizational efficiency. An enterprise architecture may cross company boundaries.

As one would expect, there are corresponding forms of architect (for example, software architect, hardware architect, and so on) and architecting (for example, software architecting, hardware architecting, and so on).

Now that we've gotten through these definitions, there are many unanswered questions. What is the difference between an enterprise architecture and a system architecture? Is an enterprise a system? Is an information architecture the same as the data architecture found in some data-intensive software applications? Unfortunately, there is no set of agreed-upon answers to these questions.

For now, you should simply be aware that these different terms exist, but that there is no consistent definition of these terms in the industry and how they relate. The recommendation, therefore, is for you to select the terms relevant to your organization and define them appropriately. You will then achieve some consistency at least and reduce the potential for miscommunication.

Summary

This article has focused on defining the core characteristics of a software architecture. However, there are many questions left unanswered. What is the role of the software architect? What are the key activities that the architect is involved in? What are the benefits of "architecting"? These questions, and others, will be answered in subsequent articles in this series.

Acknowledgements

The contents of this article have been derived from a forthcoming book, provisionally entitled "The Process of Software Architecting." As a result, the content has been commented upon by many individuals that I would like to thank, who are Grady Booch, Dave Braines, Alan Brown, Mark Dickson, Holger Heuss, Kelli Houston, Luan Doan-Minh, Philippe Kruchten, Nick Rozanski, Dave Williams, and Eoin Woods.

Notes

¹ The Software Engineering Institute (SEI) Architecture Website -- architecture definitions, offers a good example. See http://www.sei.cmu.edu/architecture/definitions.html

² IEEE Computer Society, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems: IEEE Std 1472000. 2000.

³ Object Management Group Inc., UML 2.0 Infrastructure Specification: Document number 03-09-15. September 2003.

⁴ Philippe Kruchten, The Rational Unified Process: An Introduction, Third Edition. Addison-Wesley Professional 2003.

⁵ Len Bass, Paul Clements, and Rick Kazman, Software Architecture in Practice, Second Edition. Addison Wesley 2003.

⁶ Object Management Group Inc., OMG Unified Modeling Language Specification Version 1.5, Document number 03-03-01. March 2003.

⁷ James McGovern, et al., A Practical Guide to Enterprise Architecture. Prentice Hall 2004

⁸ A role that will be covered in a subsequent article in this series.

⁹ Mary Shaw and David Garlan, Software Architecture -- Perspectives on an Emerging Discipline. Prentice Hall 1996.

¹⁰ Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User Guide. Addison Wesley 1999.

¹¹ Bass et al., Op. cit.

¹² IEEE Computer Society, IEEE Standard for Information Technology -- Software Life Cycle Processes. IEEE Std 12207-1995.

¹³ Murray Cantor, "Rational Unified Process for Systems Engineering." The Rational Edge, August 2003. http://download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/aug03/f_rupse_mc.pdf

下面是电气及电子工程师协会给“构架师”做的定义：

[构架师是]负责系统构架的人，团队或者组织。 ¹

作为项目的技术主管，构架师的技术需要非常的广泛，这比技术深度更加重要（当然构架师在特定的领域需要一定的技术深度）。

软件构架师是技术主管

首先，软件构架师是技术主管，这意味着除了他要有技术上的技能外，还要有很好的领导才能。构架师的领导能力在团队中和项目质量控制中起着十分重要的作用。

在 团队中，构架师是项目的技术总管，他需要有丰富的知识背景，以便作出技术上的决定。相对于构架师来说，项目经理是来管理项目的资源，时间进度和花费的。使 用电影制作来做类比的话，项目经理就是制片人（他要确定工作被完成了），而构架师是导演（他需要确定工作被正确的完成）。由于他们在项目中所处的位置，构 架师和项目经理是公众人物，在一个团队中，他们是整个项目所涉及的所有人员的联系枢纽。构架师应该为建立软件构架争取投资，并且要明确建立软件构架能给组 织带来的价值。

构架师还要把团队组织在构架周围，并且要积极地投入到计划活动上，因为要把构架转化成为完成任务的先后顺序，这样才能及时地确定在什么位置需要什么技术。有一点需要注意，由于构架师能否成功与团队的整体水平有很大关系，所以构架师应该参与团队新成员录用的面试。

根 据构架师所拥有的能力，他可以同时参与其他团队的工作。构架师需要根据具体的实例情况来做领导决定，并且在决定过程中要展现出足够的自信。一个成功的构架 师是以人为导向的，并且像一个教练一样给他的团队安排工作时间。这对于小组的成员来说是有好处的，他们可以及时得到帮助。这是整个团队的一个巨大财富。

构架师还要把精力放在切实工作的交付上，他是技术方面的推进力量。构架师需要做决定（经常需要在压力下做决定），并且要保证这些决定是经过成员之间的交流的，并且确保它能够执行。

架构师可能是有一个小组来完成的

下面介绍一个人和一个角色的区别。一个人可以扮演很多角色（例如，Mary是一个开发人员，同时也是一个测试人员），同时，一个角色可以有很多的人扮演 （例如，Mary和John都是测试人员）。构架师的角色需要非常广泛的技术，这就为什么构架师的角色经常是很多人同时担当。这样可以使技术知识在小组中 传播开来，每一个人都把他的或者她的经验带到工作中。特别是当某种技术同时被商业部门和技术小组理解的时候，这项技术就会最大程度的传播开来。小组所作的 结果，需要被"平衡。" 贯穿整个文章的术语"构架师"，是指的一个人或者整个小组的成员。

[一个小组]是一些拥有各种技术的人的集合，他们之间有共同需要完成的目标，并且之间相互负责任。 ²

如果一个小组来担当构架师的角色，那么就需要有一个人作为这些构架师的领导，他要拥有整体的前景，并且需要调节构架师小组之间的问题。如果没有这种调节，构架师小组成员之间就会存在危险，他们可能不会建立出一个紧密地构架或者决策不会被成功的完成。

现在有一个新的概念在构架师小组中被提出：为了使成员之间达到共同的目的和目标，团队为构架师小组建立并发布了一个章程。 ³

好 的构架师知道自己的强项和弱点在哪里。无论构架师的角色被一个人还是一个小组担当，他们背后都有"值得信赖的顾问"的支持。他们可以通过和其他构架师协同 工作来弥补自身在某些技术方面的不足。最好的构架通常是被一个构架师小组建立的，而不是一个人。原因很简单，一个小组的力量总要比一个人的知识丰富的多。

构 架师小组的概念有一个缺陷，他们有时被团队中的其他人认为是在"象牙塔"里工作，因为他们的产品经常是很有智慧的但却没有使用价值。这种误解可以从开始就 把它减到最小：1)确保所有的涉众都能积极地协商，2)不断的交流构架和它的价值，3)在执行过程中要有组织策略的意识。

构架师应该理解软件开发过程

构 架师应该对软件开发过程有正确的估计，因为这个过程确保小组中的所有成员使用同等的方式工作。一个好的过程需要定义各个角色的工作承担责任， 产品的建立，不同角色之间的协同工作等等。由于构架师每天的工作都需要和很多小组成员打交道，所以对于他们来说了解工作的职责是非常重要的。在每天的工作 中，开发小组经常要找到构架师，了解该做什么工作以及怎么去做。这就是软件构架师和项目经理之间的细微差别。

软件构架师需要有商业领域的知识

尽管拥有了丰富的软件开发经验，但是我们还期望（或者是要求）构架师拥有一定商业领域的知识。

[一个领域]是在一个范围内工作的从业人员使用一系列特定的概念和术语来表达这个领域内的知识。 ⁴

这 种知识将会使构架师更好的理解系统的需求，并把精力投身于其中，确保系统的需求是合适的——例如，从构架师领域的角度出发，需求是要被准确捕获的。经常会 出现这样的情况，一个特定系列的构架样式可以被应用到与它相联系的一个特定的领域中。如果构架师知道这种映射关系，那么对他的工作将是很大的帮助。

因此，一个好的构架师将会在软件开发和商业领域的知识上面做出权衡。如果一个构架师具有很好的软件开发经验但是不了解商业领域，那么他的解决方案可能不会解决实际的问题，而仅仅只能反映出构架师是多么精通他的专业。

另 外一个构架师需要精通商业领域知识的原因是，构架师要能够预见软件构架随时可能出现的变化。由于软件构架受它被配置的环境的影响非常大，所以对商业领域有 正确理解的构架师，可以从软件构架的角度，对不断变化的情况做出更有远见的决策。例如，如果构架师发觉哪种新的标准在未来很可能成为主流，那么他将会使自 己的软件构架在可用寿命内符合这种标准。

软件构架师应该拥有技术知识

软 件构架的一个特定方面需要有一定的专业知识，因此一个构架师必须具备这个水平的知识才能够胜任他的工作。可是构架师不必成为技术专家，这体现了这篇文章第 一部分的思想——构架师宏观上的决策。因此，构架师只需要了解宏观上的问题，而不必关心细节化的事情。由于技术的变化过于频繁，所以构架师要随时与这些变 化保持同步。

软件构架师应该拥有很好的设计技巧

虽 然软件构架并不仅仅是设计，但是设计无疑是很重要的一个组成部分。构架师应该拥有很好的设计技巧，因为软件的构架包含整个软件的关键性设计决策。这种决定 包括软件主要结构的设计决策，特定部分的选择以及指导的说明文档等等。为了确保系统构架的完整性，上面那些要素都要被特别的应用到设计中，这对整个系统的 成功完成有很大的作用。因此这些要素需要有固定的拥有设计技巧的人来负责——这个人就是构架师。

软件构架师需要拥有很好的程序设计技巧

开 发人员是整个项目开发过程中最重要的一个小组之一，构架师要随时和他们保持联系。毕竟他们要确保软件在最后交付使用的时候能够成功的执行。如果构架师认为 开发人员的工作是十分有价值的，那么他们之间的交流将会很有效用。因此，软件构架师需要拥有一定的程序设计技术，即使不需要他们编写程序。

大 多数成功的构架师，在一些场合中都是核心程序员，这些场合通常是他们的职业方向。即使是技术发展了，有新的程序语言出现，一个好的构架师可以把以前学过的 设计语言的概念和新的语言联系起来，以达到对新语言更加深入的了解。没有这种知识，软件构架师就不能对需要执行的构架的重要元素做出完美的决策，例如执行 的组织和程序标准的采用。这会使的软件构架师和开发人员之间产生沟通上的障碍。

构架师是一个很好的沟通员

和以上提到的几种技术比起来，构架师的沟通能力是最重要的。构架师需要精通所有的沟通手段，特别是需要有一定的语言能力，包括说，写和演讲能力。交流是双向的，所以构架师还需要是一个很好的聆听者与观察者。

小 组成员之间有效的沟通是项目成功的基本条件。为了更好的理解投资人的需求，与他们的沟通显得尤为重要，同时还能够让所有的投资人在软件构架上达成共识。与 项目小组的沟通同时也很重要，因为构架师的职责不单单是把信息传达给小组，同时还要激励他们工作。构架师还要负责把系统的构想传达给小组成员，使得它们让 全组人员了解，而不仅仅是构架师自己理解。

构架师需要做出决策

构 架师不能在自己不了解的环境中做出决策，然而项目的开发周期也没有给他提供充足的时间去探索所有的环境，所以在很大的压力下做的决策不太可能成功。这种环 境是被期望的，成功的构架师非常满意这种环境，而不愿去改变它。因此构架师需要是厚脸皮的，因为他们很可能在项目开发过程中更正自己的决定，并且按原路返 回查找问题。正如Philippe Kruchten所说的：“软件构架师的一生是一个漫长的，在黑暗中不断摸索并不断改进自己的决定的过程”。 ⁵

一个糟糕的决策很可能毁掉一个项目。项目小组中的其他成员会对构架师失去信心，这时项目经理就要参与进来，因为等待构架的完善不会让项目有所进展。最危险的情况是：如果构架师没有把自己的决策文档化，那么小组的其它成员可能会自己制定决策，而这种决定很可能是错误的。

软件构架师需要觉察组织的政策

一 个成功的构架师不会只关心技术问题，他们还会关心组织的权力动向，时刻了解团队的决定权在哪里。这可以保证他们正在和正确的人讨论项目的决策问题。忽略团 队的权力是天真的想法。现实往往是这样的：团队经常会强迫项目小组在规定时间交付系统，这需要构架师正确的评估到这个时间。

软件构架师是一个谈判代表

为 了了解软件构架的很多尺度问题，构架师需要随时和投资人沟通。这种沟通常常需要谈判技巧。例如，构架师需要特别注意的一件事是：最小化项目中可能出现的风 险，因为这直接关系到系统构架的稳定性。由于风险是和需求紧密相连的，所以可以通过移除或者减小这方面的需求来降低风险。因此把这种需求取消，需要构架师 和投资人达成共识的。这就需要构架师是一个有效的谈判人员，来权衡这些问题。

总结

这篇文章介绍了软件构架师的一些工作。这个系列中的下几篇将介绍软件构架过程的特性，以及把软件构架作为IT资产的基础处理的好处。

鸣谢

这篇文章来源于下面这本书，书名暂定为：“软件构架构建的过程”；下面我要感谢为这篇文章中作注释的人 员：Grady Booch，Dave Braines，Alan Brown，Mark Dickson，Luan Doan-Minh，Holger Heuss，Kelli Houston，Philippe Kruchten，Nick Rozanski，Dave Williams以及Eoin Woods。

注释

¹ IEEE 计算机协会, IEEE 推荐的软件密集型系统架构描述的实践：IEEE 标准 1471-2000。

² Jon R. Katzenbach 和 Douglas K. Smith 合著的Wisdom of Teams。 Harvard Business School 出版社1993.

³ Philippe Kruchten, "The Architects -- The Software Architecture Team," Proceedings of the First Working IFIP Conference on Software Architecture (WICSA1). Patrick Donohoe (editor). Kluwer Academic Publishing 1999.

⁴ Grady Booch, James Rumbaugh 和 Ivar Jacobson, The Unified Modeling Language User Guide. Addison Wesley 1999。

⁵ Philippe Kruchten, Op. cit.

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。

关于作者

		Peter Eeles为IBM Rational和IBM Software Group工作，他职业生涯大部分时间从事构架和执行大型分布式系统。在英国，他协助一些组织使用Rational Unified Process 和IBM Software Development Platform。他是"Building J2EE Applications with the Rational Unified Process" (Addison-Wesley, 2002), "Building Business Objects" (John Wiley and Sons, 1998)的合著者之一，并且是"Software Architectures" (Springer-Verlag, 1999)的作者之一。

为了2007年的目标，列了下面待读或重读的书单。
不在书单里的，小部分是我漏掉的，大部分是我觉得对于架构师不太重要，或者不够好的。
奇怪国外真正的好书来来去去也就那么几本，emule加上国内出版社的努力，我们看的东西和老外已差不多，为什么老外看完就那么生猛，我们看完就还是半桶水呢。

一、Software Architecture篇

这个领域没有什么"畅销书"，可能读者中本来就是开发设计人员与项目经理占了多数，真正定位为架构师而且做的也是架构师工作的不多吧。

1.《Software Architect Bootcamp--软件架构师教程》

架构师新手训练营，可惜常以Corba做例子。第2版国内还没有翻译，只好看完中文的第一版再去看电子版了。

2. 《Large-Scale Software Architecture-A Practical Guide using UML--大型软件体系结构：使用UML实践指南》
如果看不惯上一本，可以改以这本作为入行指南。

3. 《The Art of Software Architecture: Design Methods and Techniques--软件体系结构的艺术》

薄薄的一本，架构理论的抽象与提升。



4.《Documenting Software Architectures: Views and Beyond--软件构架编档》

第13届JOLT大奖作品，市面上介绍UML描述架构的书很多，但捕获架构的过程，为什么这样捕获的书籍就少了，所以它拿JOLT。

二、架构模式篇

GOF23属于开发人员的Pattern，架构师同样也有架构师的Pattern。

1. 《Head First Design Patterns》

最好的GOF23经典设计模式讲解。
。

2. 《Patterns of Enterprise Application Architecture--企业应用架构模式》

Martin Fowler经典。



3. 《Analysis Patterns: Reusable Object Models --分析模式》
Martin Fowler作品，但需要刚好有那个经验的人才看得进去。


4. 《Domain-Specific Application Frameworks: Frameworks Experience by Industry--特定领域应用框架：行业的框架体验》
介绍了特定领域特定框架的设计，我自己最喜欢看人家的设计与思考。

三、特定领域模式篇

1. Java EE领域
《Effective Enterprise Java--中文版》

Neward, Ted作品。

《Expert One-on-One J2EE Design and Development--J2EE设计开发编程指南》

Rod Johnson作品，依然使用J2EE的倒霉架构师需读。






2. SOA/ESB领域
《Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions--企业集成模式：设计、构建及部署消息传递解决方案》




3. 网络与后台服务编程领域
《Pattern-Oriented Software Architecture, Patterns for Concurrent and Networked Objects, Volume 2--面向模式的软件体系结构 卷2:用于并发和网络化对象的模式》

《Pattern-Oriented Software Architecture: Patterns for Resource Management, Volume 3--面向模式的软件体系结构卷3：资源管理模式》

著名的POSA2与POSA3。

四、RUP/UML 篇

除了RUP、UML、4+1视图，架构师们还可以遵循很多的设计方式，但UML仍然是架构师们的通用语言，RUP还是架构师职责最清晰的任务执行流程。

1. RUP最好的书其实是那份《RUP－软件开发团队的最佳实践》加上 RUP2003.6.15 中文版自带的架构师视角的文档，还有空可以看看《The Rational Unified Process:An.Introduction.第3版》


2. UML随便看一份电子书也能入门了，语法方面不需要专门买书。但教人如何画好UML的《The Elements of UML Style--UML风格》就很必要，可惜国内没有翻译第2版。

五、闲书篇

1.《Code Complete 2--代码大全2》

一本你教育小弟时的代言人。


2.《The Pragmatic Programmer--程序员修炼之道：从小工到专家》

一本你启发小弟的代言人。



3.《The Art of Unix Programming --UNIX编程艺术》

六、高效读书心得

刚好Head First系列开头都有一段教人如何读书的话，结合自己的经验整理如下：

1.尽量阅读中文版
虽然有人英文很强，有的翻译很差，但AnyWay 中文阅读与理解的时间，略读与快速定位感兴趣内容的速度还是要快一些。

2.即时批注、总结笔记与交流
虽然爱书，但发现最有效的读书方式还是不断的制造脂批本，读书时在重要的文字下划线，把自己的心得写在页旁。
读完后，把上面的划线与批注，用自己的语言重新整理表述。有人喜欢用MindManager，我还是习惯纯文本123。
最好在明天复习一次，或者拿来与人讨论。

3.大量思考或重复记忆
看书最郁闷的事情就是看完之后脑袋空空了。偏重技术的书还好点，虽然看的时候可能很辛苦，但就像学会了骑单车之后，再骑的时候总是会的；而偏重设计与管理的书，最容易的事情就是看的时候很快，看完没什么留下到项目实践中。
所以，我们不能以看小说的速度来看设计书，要寻找思考的机会，思考是最好的记忆。
如果实在没有思考的topic，就只有大量的重复记忆，重复多遍直到无意识的记忆。

4.人体工学
那些见缝插针的时间与地点不是看这个书单的好地方。
环境不要有电视，音乐等强输入源，而微风阳光鸟语等弱输入源则有助活跃大脑。
看书时大量的喝水。
如果发现自己的大脑已经疲累，已经在浮光掠影的翻看，就要休息。
留给大脑消化的时间，看完书不要接着看其他有难度的书或事情。