关于软件架构师的一些思考

haroldlbc

   做好一个软件，必须建立好三个架构：

   业务架构：业务架构包括业务流程，业务模型两方面，业务架构决定了软件的功能需求和非功能需求。

   应用架构：应用架构是业务架构在软件上的映射，理论上应用架构与具体的技术实现无关：与使用的界面技术无关，与界面显示的方式无关，与数据持久化技术无关。软件功能需求决定了软件应用架构。

   技术架构: 技术架构是软件使用的具体技术实现的设计，软件非功能需求决定了软件技术架构。

   一个软件架构师可以不是业务专家，也可以不是技术细节专家，但他必须有很强的学习能力能快速了解技术，同时必须有总结抽象简化的能力，能够与业务专家沟通，充分了解业务，总结出业务架构，建立软件的应用架构,并协调帮助技术专家建立技术架构。如果说软件开发人员的工具是开发语言和API，则软件架构师的开发语言是uml，API是设计模式。软件架构师应多采取面对面的交流方式，而不是只使用冷冰冰的email，很多事情不是通过发一封email就可以明白的。

   很多软件架构师都有这种想法：做为一个软件的总体设计者，我不应该屈尊从事具体的开发工作，这样当软件架构师当然很舒服，你只需要站在一旁，进行一些全局性的思考，用你的系统远景目标来激励自己的员工，而把无聊的具体的开发工作交给手下的开发人员。但是要想建立好的软件架构设计，并将架构设计贯彻为最终的实现代码，软件架构师必须全身心的投入到软件的日常开发测试工作中，软件架构并不是一项只注重高瞻远瞩的工作，也不能只是一味地与用户沟通——虽然这也是他们工作的一部分。软件架构师必须切身地融人到软件开发当中。只有对软件所涉及的业务和技术有综合全面的了解，才能制定切实可行的软件架构设计。

   上面一段话实际上是借用了前一段时间看的一本书《执行-如何完成任务的学问》，这本书讲的是一个领导者如何在企业内部建立一种执行文化，如何制定企业战略，并落实企业战略，如何将一个战略目标转化为具体的任务，其中的很多内容同样对如何成为一个优秀软件架构师有很多借鉴。

来源：UML软件工程组织