《实践与思考》系列连载（4）——众说纷纭“架构师”

最近在讲的一个课程，是有关.NET平台上面软件架构和开发生命周期管理方面的内容。下面这个大纲是我自己规划出来的，如果有兴趣的朋友可以参考一下：http://www.xizhang.com/resources/软件架构和软件生命周期管理培训课程.pdf

这个课程实际上主要关注的是.NET平台本身架构设计思想、以及在特定开发场景下的一些最佳实践，当然也会分享一些我自己的心得和经验。

既然是讲这个课题，难免就会讨论到“什么是架构师？”或者“架构师到底应该做什么？”这样的问题，我得承认，对于这两个问题大家的理解通常都是不尽相同的。这方面从来也不缺乏争议。事实上，我一般在开始课程之前都会有一个调查的，下面这个问卷，如果有兴趣的朋友也可以参考一下

架构师访谈

实际上，架构师的定义确实不是很简单，我们来看一下下面的一个段落，是微软给予的分类，我觉得这种分类还是有一定科学依据的

架构师是软件开发活动中的众多角色之一，它可能是一个人、一个小组，也可能是一个团队。

微软对架构师有一个分类参考，我们参考一下，他们把架构师分为4种：

1. 企业架构师EA(Enterprise Architect)
2. 基础结构架构师IA(Infrastructure Architect)
3. 特定技术架构TSA(Technology-Specific Architect)
4. 解决方案架构师SA (Solution Architect)。

微软的这个分类是按照架构师专注的领域不同而划分的。

1. EA的职责是决定整个公司的技术路线和技术发展方向。盖茨给自己的Title就是首席软件架构师，网易丁磊也喜欢这么称呼自己，实际上就是EA角色；
2. IA的工作就是提炼和优化技术方面积累和沉淀形成的基础性的、公共的、可复用的框架和组件，这些都是一个技术型公司传承下来的最宝贵的财富之一；
3. 特定技术架构师TSA，他们主要从事类似安全架构、存储架构等专项技术的规划和设计工作；
4. SA的工作则专于解决方案的规划和设计，“解决方案”这个词在中国已经到了严重泛滥的程度，大忽悠们最喜欢把它挂在嘴边。所谓解决方案，就是把产品、技术或理论，不断地进行组合，来创造出满足用户需求的选择。售前工程师一般都是带着它到客户那里去发挥的。

大家对于架构、架构师有什么样的认识和见解，我这里欢迎大家参与讨论。而对于这方面的思考，我将在本书中有一个章节来讨论，总结出来也会对大家有帮助。

这里希望多听听各方面的反馈。请大家不要客气，畅所欲言，直接留言或者给我回复邮件(ares@xizhang.com)都可以。谢谢

我自己的看法是：

架构师不是变戏法的，要做好架构师工作，需要对技术平台、框架有全面和深入地了解，并且洞悉前人总结的经验和最佳实践，能够运用到自己的设计中去。

和有些朋友可能会有些不同意见的是，我认为尤其对于中小型团队而言，架构师最好是能够参与编写代码的。（这里所说的架构师，如果按照上面的分类来说的话，通常是属于TSA）。我个人觉得架构师应该具有对代码的足够热情，并且有能力设计出决定项目和产品的基础技术框架（从这个意义上说，可以走向IA的定位）