前言
前言
我们写这本书,是为了阐述一种强大的思想。越来越多的人已经开始有了这种思想,这就是“系统的架构”(architecture of a system)。从电网的架构到移动支付系统的架构,很多领域都出现了系统架构的思维。架构就是系统的DNA,也是形成竞争优势的基础所在。拥有系统架构师这一头衔的专业人士,现在已经超过10万人,此外还有更多的人以其他身份参与架构工作。
对于强大的思想,其边界一般都比较模糊。我们发现许多同事、客户和同学都能够意识到系统架构问题,但他们对这个词的用法有所区别。这个词一般用来区分两个已有的系统,例如“这两种山地自行车的架构不同”。
系统的架构到底是由什么组成的?这个话题通常会引发巨大的争论。在某些领域中,架构用来指代一项能够在抽象层面上区分两类系统的决策,例如“封包交换的架构”(packet-switched architecture)与“电路交换的架构”(circuit-switched architecture)。而在另外一些领域中,这个词则用来在忽略某些小细节的情况下描述整体的实现,例如“我们的软件是用来充当服务架构的”。
我们的目标是阐述架构思维的强大之处,并且使其边界变得更加明晰。架构思维的强大,源自它能够使我们在项目的早期阶段权衡各种架构、展望后续的发展情况,并发现各种约束以及对提升项目价值较为重要的机遇。如果架构把全部细节都包括进去,那么我们就无法在各种粗略的想法之间轻易跳跃,但如果架构中缺少了重要的价值驱动力,那它又显得没有意义。
我们写本书时所持有的理念与Eberhardt Rechtin相同,都认为架构师应该是专才,而非通才。我们想在书中描述系统架构的分析与构建过程,也想展示系统架构的“科学性”。与产品设计规范相比,本书的措辞在某种程度上较为宽松一些,因为我们要处理的系统更加复杂。产品研发人员所重视的是设计问题,而我们要强调的则是系统中的各个部件如何才能凝聚成一个连贯的整体,我们重视的是这个奇妙的涌现过程。
我们把过去的经验融入了本书中。我们有幸参与了许多复杂系统的早期研发工作,这些系统遍布通信、运输、移动广告、财经、机器人、医疗设备等各个领域,其复杂程度也各有不同,从农具到国际空间站,我们都接触过。
此外,书中的案例研究还涉及混合动力车(hybrid car)及商用飞机(commercial aircraft)等其他领域的系统架构师所总结出的一些经验。我们认为,本书必须要能够应对当前系统架构师所面临的各项挑战,因为只有这样,才能推进系统架构的发展。
本书的核心受众有两类人,一类是专业的架构师,另一类是工程学的学生。系统架构这一理念,是相关行业的从业者从实践和尝试中得来的,这些从业者运用自身的智慧,试着总结出一些经验,以应对研发新系统时所面临的挑战。本书的一部分目标读者是进行架构决策的资深专业人士。这些专业人士包括高级技术人员,也包括软件、电子、工业用品、航空、汽车及消费用品等科技产业中的管理人员。
本书的另一部分目标读者是工程学的学生。本书是根据过去15年间我们在麻省理工学院讲授研究生课程时的教学经验而写成的,其中有很多学生后来成了私人企业和政府部门中的佼佼者,对此我们深感荣幸。架构思维不仅可以帮助我们理解系统当前的运作方式,而且对于科技组织的管理来说,这也应该是一项必备的能力。
致谢我们要感谢使本书得以面世的诸位人士。首先,感谢Bill Simmons、Vic Tang、Steve Imrich、Carlos Gorbea和Peter Davison,他们在本书的相关章节中提供了自己的专业意见,并对本书的初稿做了点评。Norman R. Augustine为本书撰写了推荐序,并帮助我们成形系统架构方面的想法,为此我们深表感激。
感谢评审者Chris Magee、Warren Seering、Eun Suk Suh、Carlos Morales、Michael Yukish及Ernst Fricke给我们提供了明确的意见,并帮我们指出了未能传达出关键思想的那些段落。还要感谢很多匿名评审者,他们给出的反馈意见使我们能够对本书加以改进。感谢OPM(Object Process Methodology,对象过程方法)的研发者Dov Dori,他是我们的优秀合作伙伴。
感谢Pat Hale为我们在MIT的教学活动提供支持并对本书初稿给出反馈。感谢MIT系统设计与管理2011班(MIT System Design and Management Class of 2011)的63位同学详细阅读本书的每一章,并给出大量建议。尤其要感谢Erik Garcia、Marwan Hussein、Allen Donnelly、Greg Wilmer、Matt Strother、David Petrucci、Suzanne Livingstone、Michael Livingstone及Kevin Somerville。感谢MIT图书馆的Ellen Finnie Duranceau帮我们明智地选择了出版社。
本书的编写得益于历届的研究生,他们所贡献的内容以各种形式出现在本书中。除了上面提到的那些人之外,还要感谢Morgan Dwyer、Marc Sanchez、Jonathan Battat、Ben Koo、Andreas Hein及Ryan Boas。
感谢Pearson团队的Holly Stark、Rose Kernan、Erin Ault、Scott Disanno及Bram van Kempen为本书的出版所付出的辛勤劳动。
最后,感谢Crawley的妻子Ana、Cameron的妻子Tess,以及Selva的妻子Karen,感谢你们在周末和假期对我们著书工作的理解,使我们不至于把它拖成一本“永远都写不完的书”。
—Edward Crawley Bruce Cameron Daniel Selva马萨诸塞州剑桥市
推 荐 序Norman R. Augustine在医疗健康领域中,有一种趋势特别有前途,这就是生物医学研究与工程实践的结合。我有一位朋友是工程师,他最近告诉我,美国一家知名大学曾经开了这样一个会,工程系与心脏病学科系的教研人员,在会上探讨了这两种学科的结合方式。会议的重点是构建一颗可供人类使用的机械心脏,心脏病学科系的主管刚开始描述人类心脏的各项特征,就有工程师打断他,并问道:“机械心脏必须放在胸腔中吗?有没有可能放在其他更容易够到的地方?例如大腿中?”开会的人以前从来没考虑过这种可能。主管接着描述心脏的特征,但是过了一会儿,又有另一个工程师打断他,并提问:“能不能不要只放一个心脏,而是把三颗或四颗心脏组合成分布式系统?”这个问题,也是大家从未考虑过的。
本书由系统架构领域内三位备受崇敬的领军人物撰写,他们的观点很有见地。书中讨论的就是如何提出并回答上面那样的问题。我在工作中曾经碰到工程、商务、政府等方面的各种系统架构问题,当运用系统架构领域中的一些经验来解决这些问题时,我发现结果会好很多。
然而,单单运用这些经验是不够的。刚开始工作时,我记得自己总是问同事各种问题。当时我们正在“合作”完成一个导弹项目,我问他们为什么要采用某种特定的方式来设计产品的某个部件。有人给出的原因是“这种设计方式重量最轻”,有人说他设计的那一部分雷达横截面(radar cross-section)最小,还有人说自己设计的那个部件成本低、体积小,等等。
这些理由都不错,可是其中缺了一样东西。那就是系统架构师(system architect)。
系统架构师的缺位很常见,但表现方式一般比较微妙。几年前,我曾经参与了近音速运输机(Near-Sonic Transport aircraft)的早期研发工作。一份市场调查表明,乘客想要更快地到达目的地。近音速运输的理念,就是想使速度尽量接近音速(也就是接近1马赫,1马赫≈1225km/h),但又不超过它,以避免超过音速之后所引发的各种问题。然而空气动力学者(我早前的研究领域就是空气动力学)发现:这样做使得飞机在阻力曲线上会进入一个耗油量陡增的区域。
从系统架构的观点来看,我们要解决的问题并不是怎样飞得更快,而是如何缩短乘客从家中到机场、办理登机手续、过安检、上飞机、飞行、落地后取行李并驶往最终目标所需的总时间。把这个问题放在刚才那个情境中考虑,我们就会发现,更基本的问题其实应该是:节省这5分钟或10分钟的飞行时间,究竟能给乘客带来多大的好处?答案是:带不来多大好处。因此,这项近音速运输机计划就提前终止了。如果我们想使乘客更快地到达目的地,那么显然还有其他更好的方案可供探索。这个项目之所以失败,是因为大家没有意识到自己正在处理的是系统架构问题,而不单单是空气动力学或飞机设计方面的问题。
这些年来,我一直在不断地完善自己对“系统”这个词所下的定义。系统是“可以交互的两个或多个元素”,而本书作者又明智地补充了一点,那就是系统的功效必须大于各自元素的功效之和。尽管在概念层面很简单,但是现实世界中的系统相当复杂。实际上,对于由若干元素所构成的(而且这些元素之间都以最简单的方式来交互)系统来说,描述其可能具备的状态数量所用的那个公式非常吓人,有“怪兽公式”之称。此外,很多系统里面还有人的因素在内,如果系统里面还包括人,那么系统架构所面临的困难就会更大,因为人的因素会带来不确定性。我们在现实中遇到的就是这种系统,本书作者要分析和解决的架构问题,也针对的是这种系统。
我曾经分析过这样一个给美国南极站进行补给的系统。与其他系统一样,我需要非常谨慎地设定具体的评估目标。是要缩减在可以预期的状况下所产生的消耗,还是要减少在无法预期的最差状况(例如糟糕的天气)下所产生的消耗?又或者是要尽量避免在补给品根本无法送达时所发生的那些“令人遗憾的”状况?可以考虑的目标还有很多。
在这个系统中,有很多个必须互相配合的元素,例如运输船、破冰船、各种飞机、用于卸货的冰码头、存储设施、交通工具、通信等。而且在做各种决策时,还要考虑架构中一直可能会发生的一种危险,那就是单点故障。
我还在商务领域中遇到了一个比刚才更复杂的问题,那就是能不能把7家公司的所有部门或主要部门,合并为洛克希德·马丁公司,如果能,应该如何去做。这个系统中的每个“元素”都有其优缺点,每个都涉及很多人,都有自己的目标、能力和局限性。这项决策的关键在于,合并之后的新公司,其效能是否远远高于原有那些部分各自的效能总和。如果做不到这一点,那就没有理由耗费资金去进行合并与收购了。
对于这一类复杂问题来说,并没有简单的数学公式能够给出“正确”答案。然而,系统思维(systems thinking)的训练是一项极为有用的工具,可以帮助我们去评估系统的观感、系统中潜藏的机遇以及系统对参数的敏感程度等。在刚才那个企业合并的案例中,大多数人都认为合并是“对的”,顺便说一下,在相似的案例中,有80%的情况也是如此。
我与本书的一位作者及其他同事,曾经向美国总统提出一项载人航天计划,这项计划是为将来的几十年而制定的。在这个案例中,最困难的地方是怎样合理地定义任务(mission),虽说确定适当的硬件配置也是个不小的工作,但与前者比起来,难度还是要低一些。所幸这种问题都可以通过系统思维来解决。
正如作者在书中所说的那样,系统架构的建立过程,既是科学,又是艺术。尽管这听起来很美好,但现实相当残酷。与达尔文式的物种进化现象一样,用过去的错误架构所搭建出来的系统是无法生存的;反之,用良好的架构所搭建的系统不仅可以生存,而且会越来越好。
所谓复杂系统的架构,也就是这么一回事。