如何才能称得上是一名架构师？

在 MSDN 开发者中心的博客上有一篇很有意思的文章，作者在文中讲述了在微软的文化（至少是其文化的一部分）中架构师的定义，带我们对软件架构师这个角色所经历的历史进行了回顾，并描绘了使架构师变得至关重要的驱动力。他从当架构师还是可有可无的那段时期开始讲起：

在不久以前，开发平台还是更加倾向于自我封闭，自给自足的。从健壮而复杂的环境——比如主流的 COBOL，到轻量级且易于理解的 xBase 语言，最为重要的技术决定早就已经有人帮你做好。对于软件项目而言，这是利益和障碍共存的。其中一项好处就是，当人们在某一点存在有共识的时候，就无需浪费时间来争论作这件事情的最佳方式是什么了。

文章的作者 Dagum 接着又对我们当前所使用的基本栈式架构的多样性进行了简单说明，以及这种灵活性最终所带来的代价：我们必须要有效的管理系统的复杂性。

由于面向组件的软件开发方式的出现，我们可以根据特定的问题来选择最佳的平台。但尽管这样，对很多程序员来说，切换到新的平台上进行开发也是件很头疼的事情。所以一个好的架构师的首要目标就是把新的平台和 API 的复杂性隐藏到更为简洁的结构之后，让它们更加注重于待解决问题（特别是一个业务问题）的领域，当然最重要的就是让普通的程序员容易理解掌握。 软件架构就是这样变成了以安全、及时、精确的方式开发商业解决方案的一条坦途。这条路完全是由技术决策铺成的，这些决策是至关紧要的。架构师必须要做出种种决策，来方便开发人员的工作。

和过去相比，我们现在不再是从厂商那里购买通用型的软件，而是根据要开发的商业解决方案来做出决策。

Dagum 解释说这给架构师的职责和定义带来了一场突如其来的变革，从以应用程序为中心，转到了更加侧重于企业化乃至以基础设施为关键着眼点的职责上，他还详述了进来新词满天飞的架构变革的趋势——SOA——背后的主要驱动力。他在讲述早期软件架构师的定义的时候，列举了以下四个最佳实践：

• 设计模式（Design Patterns），从“四人帮”的那本设计模式书发起
• 架构模式（Architecture Patterns），Dagun 以 Smalltalk 中使用的 MVC 模式来加以举例说明
• 反模式（Anti-Patterns），它的名字就准确说明了它的含义
• 框架，他以 ORM 映射工具和 MVC 支持框架来举例说明

随后，他又解释了随着架构师一职被人们正式认同，相应的角色和责任是如何被转变到一个更高的抽象层次上的，它们又是如何围绕下面三个范畴巩固起来的：

• 基础架构师（Infrastructure Architect），主要以硬件 / 网络 / 操作系统这种平台的微架构为中心
• 解决方案架构师（Solution Architect），他的职责要跨越软件 / 数据库 / 硬件的界限，来为特定的解决方案定义一个一栈式的架构
• 企业架构师（Enterprise Architect），他更像是一个管理型的角色，他的责任和范围是覆盖整个组织的

最后，Dagum 以对未来的展望结束了全文。他还特别提到了 SOA，MDA，软件工厂，软件即服务（Software as a Service）和 Web 2.0。随着时间的推移，人们心目中对架构师定义也有了不同的理解，Dagum 在文中对这种变化及其背后的驱动力做了归纳。

查看英文原文： What is an Architect anyway?