解密微软的架构师之路，作者： wuzhimin
Windows HPC Server架构师徐明强
若是说起架构师，几乎所有的开发人员都知道的一个伟大架构师来自微软，他就是比尔•盖。这个20世纪最伟大的技术天才有太多的传奇。对于架构师这个群体，他同样产生了非同小可的作用。作为一个企业的大老板，他是第一个给自己冠之以“首席架构师”头衔的人。也正因如此，整个IT领域才开始不断涌现出架构师这个并不算新的职业。为了追寻微软的架构师文化，我们采访了微Windows HPC Server架构师徐明强博士，邀请他为我们解密微软的架构师之路。
微软架构师定义
对微软内部的架构师的定义，Windows HPC Server架构师徐明强博士是这么描述的：“微架构师的职责定义主要在两个方面。一是要负责整个项目中技术活动和工程过程，进行领导和协调。二是要负责理解系统本身的业务需求，并且创建合理完善的一个系统体系架构。进一步的细化则可以展开来谈。”
“通常架构师要确立每一个构架视图的整体架构，比如说视图的详细结构、元素的分组以及实现主要分组之间的接口描述。因此和其他角色对比，架构设计师的见解是用在广度，不是在深度，这样才能确保架构师在技术活动中起到领导的作用。第二方面，对于业务需求来说，架构师要负责通过软件架构来决定主要的技术选型。典型的工作包括系统需求设计，实现和部署的视图以及测试等等。”
三种架构师
这种通用的解释如果难于理解，那么是不是会有更具体的实施方法？像微软这样庞大的软件开发组织结构里，架构师会根据产品团队，工作职能进行进一步划分。随后，徐明强开始介绍微软架构师的分类。
“如果要理解微软的架构师职能划分，就需要先了解微软的产品部门划分。通常在微软内部的产品组，有三个更小一级的分组，一是项目经理组，二是开发组，三则是测试组。”
“项目经理组主要是负责业务的需求定义，产品规格书撰写。而开发组则主要负责软件的实现，以满足项目经理所定义的需求规格书。测试团队的主要任务则是确保软件产品交付的质量。不同的分组，有不同的职能划分。因此，我们看做是有项目经理架构师，开发架构师和测试架构师几种基本类型。”
“不同的架构师职能大相径庭，比如项目经理架构师，更侧重于业务上的需要。从这个意义上看，你就会发现不同架构师的区别。由于项目经理主要是看用户的需求，对整个系统性能提出要求，对工作品质提出要求，同时还要确认在用户应用场景，产品是否可以有效地被系统支撑，因此它具备了非常不同的职能。”
“而开发组的架构师比较侧重于技术，尽管某些问题上会与项目经理架构师重叠，但更多时候分工还是非常明确的。技术架构师的一大职能是技术选型，比如在产品中选择使用什么技术，比如数据库要采用哪种规格的SQL server， 比如数据库的模式（schema）应该怎么样设计。当然，这里也包括.NET组件的选择等，这些是开发组架构师所关注的。
“从测试方面看，测试架构师则关注测试系统对架构的设计的帮助，包括如何自动化测试，或更有效的手工测试等。比如说HPC Server 测试组的架构师的工作，由于涉及到很复杂的分布式的系统，就需要做可扩展性测试，计算资源分配的测试，包括测试方法的设计等。”
协同工作，准确分工
这么多不同的架构师，如何协调工作，这是很多人马上会想到的问题。尤其是在面临冲突的时候如何解决，关系到每一项工作是否能顺利推进。关于这个问题，徐博士给我们举了个例子。
“比如我负责HPC Server 产品的规格说明书，那么开发组就会强调是否有充裕时间实现各个组件，而测试组将会根据规格说明书来考虑，这个组件所实现的功能是否严格满足规格要求。开发组会有很好的意愿来完成产品开发，但如何衡量是否完成却是一个问题。从我们的角度看，首先就是应用的场景。例如在一份需求说明文档中，如果你能描述为什么有这个需求，且写得非常清楚，那么开发就能准确地知道他们需要做的工作是什么。如果有一套非常清楚的目录，告诉用户如何使用产品，那么当这个系统做出来以后，每一步都应该考虑到用户在每一个阶段有什么样的知识背景能够完成下去。只要应用场景的故事清楚，文档自然也能够清楚。”
“当然，不同的工作也会有不同的优先级。这同样是项目经理架构师需要定义清楚的。技术架构师的主要精力，会放在具体选择哪个组件实现。这对于技术架构师来说，是非常有把握的。因此我们可以看到，产品需求定义得越细、需求的优先级定义得越好，说明项目经理架构师很好地完成了自己的工作，对于开发架构师的衡量，则是采用什么技术以及何种组件/架构提高了开发效率。”
“另外一方面是测试，项目经理的架构师同样需要与测试架构师协同工作。功能的每一个方面在需求中表现得越细致，各方面的系统指标越清晰，就越可以帮助测试架构师更好地完成其工作。牵涉到可扩展性、可延时等细节性能的指标，是测试架构师的优势，他们知道怎样才能处理好这些事情，但它们希望看到明确的指标。”
团队成长
多数公司里，架构师都是宝贝。而很多程序员，也确实梦想自己能成为一名软件架构师。但架构师的数量总是有限，多少人可以成为架构师？架构师的团队是如何成长起来的？徐博士用亲身经历讲述了HPC团队的发展历程。
“根据产品开发周期，不同的团队会有不同的配置。我在HPC产品组经历了两个多，近三个版本，所以有一点体会。在HPC第一版的时候，基本上我们的产品会分三个主要的组件，每个主要组件会有一个小团队。当时包括作业调度系统、管理系统和消息传递界面(MPI)，基本上每个组件都有一个架构师。尽管有的一开始没有架构师的头衔。 当时大概是一个架构师和三个开发人员和三个测试人员协同战。”
“主要原因在于项目一开始，团队并没有考虑如何定义架构，这里包括技术选型等，很多时候架构师会考虑这些事情，此时不会严格按照前面说的不同角色分工。到了后期的版本，产品问世，用户需求喷涌而出的时候，项目管理架构师角色就开始明晰化了。尽管主要的工作是在第一个版本上增加功能，但各个部门都会开始聘用更多的开发人员和测试人员，同时管理人员也会增多。”
架构师的核心能力
为了让开发者逐渐成为架构师，基础的能力还是需要具备的。“我觉得架构师必须学会的第一件事情就懂得如何进行权衡。因为我们面对的都是相互矛盾的一些设计要素和限制，但事实却要求你在这些相互矛盾的要素限制和约束条件之间取得非常巧妙的平衡。”徐博士感叹道。
“架构师必须足够成熟。因为他们往往需要在无法获得完整信息的情况下，迅速领会问题，根据经验做出审慎判断。其实微软内部有能力要求，能把一张比较模糊的图片清晰化。这里我想归纳四个方面。首先是在专题领域的经验和对微软软件开发工程的经验。第二个就是判断力、决定能力和领导力，推动各个团队的技术进展，并且能在压力下作出关键性的决策，然后将开发贯彻到底，而且要提高效率。架构师有权在技术上作出决定，在大家意见不一致的时候，他要能给出自己的一个意见。第三则是善于沟通。这其中首先就是赢得他人的信任。只有这样，才可以对他们进行说服，而后进行指导。微软架构师跟其他的合作的人没有直接的上下级关系，所以不能靠命令进行指导，所以必须要靠赢得其他人的赞同。第四点，是通常说的抽象思维和分析的能力。具体思维的人可能比较注重细节，但往往也会将问题复杂化，使头绪增多而无法收敛。 抽象思维可以帮架构师地从大量信息、系统文件中，看出一些规律来，而且找出与之相关的方面，归纳关键问题，表述模糊的概念并将其变成相关各方能够理解的项目构件。”
“最后，我认为无论是什么样的架构师都要具备一定的商业头脑，业务的知识要充分把握，因为对业务把握能够带来一个拥抱变化的能力，而且可以在设计的时候留出一点扩展的余地，适应将来可能来临的需求变化。”
（本文来自《程序员》杂志0906期）