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

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

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

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

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

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

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

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

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

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

    构架师需要做出决策

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

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

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

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

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

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

    总结

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

    注释

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

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

    3 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.

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

    5 Philippe Kruchten, Op. cit.