我接触过不少订单协同软件开发架构设计师，其中的大多数都是不称职的。这些架构师给软件开发带来的坏影响，大过项目中的每一个人。我总是感到很惊讶，为什么有这么多的软件开发组织在如何甄选优秀架构师的问题上毫无作为呢？在4.3.5节中，我会展开这个话题。到目前为止，我们对于什么是软件架构已经有了一个粗略的了解。我们知道了架构的定义，知道了架构的来源，知道了构架软件系统的一般方法，知道了订单协同软件开发构架系统的能力要求，知道了软件架构的重要性，知道了一般软件开发组织的架构水平的现状。 知道这些还远远不够，接下来我将介绍构架软件系统的其他技能。

      软件架构的设计业界技术成果就像绝大多数的人类创造物一样，软件架构也不是凭空产生的。软件业经过多年的经营和发展，已经涌现了许许多多优秀的技术成果。这些技术成果，分布于软件开发中的各个方面——从订单协同软件开发方法论到设计理念、从平台到模型、从算法到规范。是否善于使用这些技术成果来构架自己的软件系统，已经成为衡量一个软件架构师成功与否的标准之一。在本节中我打算介绍一些自己近十年来的技术见闻，这些见闻包含了我接触过的众多技术中的一部分。很多技术在当时极具震撼力，现在看来却已经不再那么时髦。 

老实说，我在这里谈论一些“落伍”的技术，却并不会为此感到不安。这就好像大多数人的成长规律：年轻的时候是个新技术的狂热追随者；随着年龄的增长，无法控制地放慢脚步，最终转向保守主义阵营。当然，每个人对于保守的认识是不同的。拿我来说，我极度反感动态语言，以及在一个非常受限的“小笼子”里折腾花里胡哨的界面。从这一点上说，我是保守的。但我也有反思、创新的一面，比如，我认为采购评审软件早该淘汰了，纯粹是商业的原因才让这个历史产物生存到今天。浏览器需要补充新鲜血液，我估计这一天很快就要到来。 与本书中的所有章节一样，我不会对以下提到的技术进行完整而精确的解释，相反，提及的内容大多点到为止。