软件构架师的特点

级别： 初级

Peter Eeles, 高级 IT 架构师, IBM

2006 年 3 月 15 日

来自于 Rational Edge：在电影制作术语中，软件项目经理被称作制作人，因为他们决定需要做什么事情。而软件构架师就是导演，他来决定所作的事情是否正确，并且他要保证产品符合投资人的要求。下面这篇文章就是描述软件构架师的。

这篇文章是关于软件构架的系列文章（共四篇）中的第二篇。上个月，这个系列文章中的第一篇给构架作了一个定义。因此现在我们可以把注意力集中到创建构架的人员——构架师身上。软件构架师被证明是软件开发项目过程中最具挑战性的角色。软件构架师是项目的技术领袖，并且从技术角度来讲，他承担了项目成败的责任。

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

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

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

软件构架师是技术主管

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

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

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

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

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

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

下面介绍一个人和一个角色的区别。一个人可以扮演很多角色（例如，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)的作者之一。