软件构架师是一个谈判代表
为了了解软件构架的很多尺度问题，构架师需要随时和投资人沟通。这种沟通常常需要谈判技巧。例如，构架师需要特别注意的一件事是：最小化项目中可能出现的风险，因为这直接关系到系统构架的稳定性。由于风险是和需求紧密相连的，所以可以通过移除或者减小这方面的需求来降低风险。因此把这种需求取消，需要构架师和投资人达成共识的。这就需要构架师是一个有效的谈判人员，来权衡这些问题。
总结
这篇文章介绍了软件构架师的一些工作。这个系列中的下几篇将介绍软件构架过程的特性，以及把软件构架作为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.
参考资料
您可以参阅本文在 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)的作者之一。
文章来源于领测软件测试网 https://www.ltesting.net/
