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

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

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

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

    总结

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

    鸣谢

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

    注释

    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.