解密微软的架构师之路

<DIV >
<P>——专访Windows HPC Server 架构师徐明强</P>
<P></P>
<P></P>

<P>文 / 白苗 </P>
<P></P>
<P></P>
<P>若是说起架构师 ， 几乎所有的开发人员都知道的一个伟大架构师来自微软， 他就是比 尔&#8226; 盖 。这个 20 世纪最伟大的技术天才有太多的传奇。 对于架构师这个群 体， 他同样产生了非同小可的作用 。作为一个企业的大老板， 他是第一个给 自己冠之以 “ 首席架构师 ” 头衔的人。也正因如此， 整个 IT 领域才开始不断涌现出架构师这个并不算新的职业。 为 了追寻微软的架构师文化， 我们采访了 微 Windows HPC Server 架构师徐明强博士， 邀请他为我们解密微软的架构 师之路。 </P>
<P></P>


<P><B>微软架构师定义 </B></P>
<P>对微软内部的架构师的定义， Windows HPC Server 架构师徐明强博士是这么描述的： “ 微架构师的职责定义主要在两个方面。 一是要负责整个 项目中技术活动和工程过程， 进行领导 和协调。 二是要负责理解系统本身的业 务需求， 并且创建合理完善的一个系统 体系架构。 进一步的细化则可以展开来 谈。 ” </P>
<P>“ 通常架构师要确立每一个构架视图的整体架构， 比如说视图的详细结 构、 元素的分组以及实现主要分组之 间的接口描述。 因此和其他角色对比 ，架构设计师的见解是用在广度， 不是在 深度， 这样才能确保架构师在技术活动 中起到领导的作用。 第二方面 ，对于业务需求来说， 架构师要负责通过软件架 构来决定主要的技术选型。 典型的工作 包括系统需求设计， 实现和部署的视图 以及测试等等。 ” </P>


<P><B>三种架构师 </B></P>
<P>这种通用的解释如果难于理解， 那 么是不是会有更具体的实施方法？ 像 微软这样庞大的软件开发组织结构里，架构师会根据产品团队， 工作职能进行 进一步划分。 随后 ，徐明强开始介绍微软架构师的分类。 </P>
<P>“ 如果要理解微软的架构师职能划分， 就需要先了解微软的产品部门划 分。 通常在微软内部的产品组 ，有三个更小一级的分组， 一是项目经理组 ，二是开发组， 三则是测试组 。 ” </P>
<P>“ 项目经理组主要是负责业务的需求定义， 产品规格书撰写 。而开发组则主要负责软件的实现， 以满足项目经理 所定义的需求规格书。 测试团队的主 要任务则是确保软件产品交付的质量。不同的分组， 有不同的职能划分 。因此 ， 我们看做是有项目经理架构师， 开发架 构师和测试架构师几种基本类型。 ” </P>
<P>“ 不同的架构师职能大相径庭， 比 如项目经理架构师， 更侧重于业务上的 需要。 从这个意义上看 ，你就会发现不同架构师的区别。 由于项目经理主要是 看用户的需求， 对整个系统性能提出要 求， 对工作品质提出要求 ，同时还要确认在用户应用场景， 产品是否可以有效 地被系统支撑， 因此它具备了非常不同 的职能。 ” </P>
<P>“ 而开发组的架构师比较侧重于技术， 尽管某些问题上会与项目经理 架构师重叠， 但更多时候分工还是非 常明确的。 技术架构师的一大职能是 技术选型， 比如在产品中选择使用什 么技术， 比如数据库要采用哪种规格 的 SQL server ， 比如数据库的模式（ schema ）应该怎么样设计 。 当然， 这 里也包括 .NET 组件的选择等， 这些是 开发组架构师所关注的。 </P>
<P>“ 从测试方面看， 测试架构师则关 注测试系统对架构的设计的帮助， 包括 如何自动化测试， 或更有效的手工测 试等。 比如说 HPC Server 测试组的架构师的工作， 由于涉及到很复杂的分 布式的系统， 就需要做可扩展性测试 ，计算资源分配的测试， 包括测试方法的 设计等。 ” </P>


<P><B>协同工作， 准确分工 </B></P>
<P>这么多不同的架构师， 如何协调 工作， 这是很多人马上会想到的问题 。尤其是在面临冲突的时候如何解决， 关 系到每一项工作是否能顺利推进。 关于 这个问题， 徐博士给我们举了个例子 。 </P>
<P>“ 比如我负责 HPC Server 产品的规格说明书， 那么开发组就会强调是否 有充裕时间实现各个组件， 而测试组将 会根据规格说明书来考虑， 这个组件所 实现的功能是否严格满足规格要求。 开 发组会有很好的意愿来完成产品开发，但如何衡量是否完成却是一个问题。 从 我们的角度看， 首先就是应用的场景 。例如在一份需求说明文档中， 如果你能 描述为什么有这个需求， 且写得非常 清楚， 那么开发就能准确地知道他们需 要做的工作是什么。 如果有一套非常清 楚的目录， 告诉用户如何使用产品 ，那么当这个系统做出来以后， 每一步都应 该考虑到用户在每一个阶段有什么样的知识背景能够完成下去。 只要应用场 景的故事清楚， 文档自然也能够清楚 。 ” </P>
<P>“ 当然， 不同的工作也会有不同的 优先级。 这同样是项目经理架构师需 要定义清楚的。 技术架构师的主要精 力， 会放在具体选择哪个组件实现 。这对于技术架构师来说， 是非常有把 握的。 因此我们可以看到 ，产品需求定义得越细、 需求的优先级定义得越 好， 说明项目经理架构师很好地完成 了自己的工作， 对于开发架构师的衡 量， 则是采用什么技术以及何种组件 / 架构提高了开发效率。 ” </P>
<P>“ 另外一方面是测试， 项目经理的 架构师同样需要与测试架构师协同工作。 功能的每一个方面在需求中表现 得越细致， 各方面的系统指标越清晰 ，就越可以帮助测试架构师更好地完成其工作。 牵涉到可扩展性 、可延时等细节性能的指标， 是测试架构师的优 势， 他们知道怎样才能处理好这些事 情， 但它们希望看到明确的指标 。 ” </P>


<P><B>团队成长 </B></P>
<P>多数公司里， 架构师都是宝贝 。而很多程序员， 也确实梦想自己能成 为一名软件架构师。 但架构师的数量 总是有限， 多少人可以成为架构师 ？架构师的团队是如何成长起来的？ 徐 博士用亲身经历讲述了 HPC 团队的发展历程。 </P>
<P>“ 根据产品开发周期， 不同的团队 会有不同的配置。 我在 HPC 产品组经历了两个多， 近三个版本 ，所以有一点体会。 在 HPC 第一版的时候， 基本 上我们的产品会分三个主要的组件，每个主要组件会有一个小团队。 当时 包括作业调度系统、 管理系统和消息传递界面 (MPI) ，基本上每个组件都有一个架构师。 尽管有的一开始没 有架构师的头衔。 当时 大概是一个架构师和三个开发人员和三个测试人员协同战。 ” </P>
<P>“ 主要原因在于项目一开始， 团队并没有考 虑如何定义架构， 这里 包括技术选型等， 很多 时候架构师会考虑这些事情， 此时不会严格按 照前面说的不同角色分工。 到了后期的版本 ，产品问世， 用户需求喷 涌而出的时候， 项目管 理架构师角色就开始明晰化了。 尽管主要的工 作是在第一个版本上增加功能， 但各个部门都 会开始聘用更多的开发人员和测试人员， 同时管理人员也会 增多。 ” </P>


<P><B>架构师的核心能力 </B></P>
<P>为了让开发者逐渐成为架构师，基础的能力还是需要具备的。 “ 我觉得架构师必须学会的第一件事情就懂得如何进行权衡。 因为我们面对的都是 相互矛盾的一些设计要素和限制， 但 事实却要求你在这些相互矛盾的要素限制和约束条件之间取得非常巧妙的平衡。 ” 徐博士感叹道。 </P>
<P>“ 架构师必须足够成熟。 因为他们 往往需要在无法获得完整信息的情况下， 迅速领会问题 ，根据经验做出审慎判断。 其实微软内部有能力要求 ，能把一张比较模糊的图片清晰化。 这 里我想归纳四个方面。 首先是在专题 领域的经验和对微软软件开发工程的经验。 第二个就是判断力 、决定能力和领导力， 推动各个团队的技术进展 ，并且能在压力下作出关键性的决策，然后将开发贯彻到底， 而且要提高效 率。 架构师有权在技术上作出决定 ，在大家意见不一致的时候， 他要能给 出自己的一个意见。 第三则是善于沟 通。 这其中首先就是赢得他人的信任 。只有这样， 才可以对他们进行说服 ，而后进行指导。 微软架构师跟其他的 合作的人没有直接的上下级关系， 所 以不能靠命令进行指导， 所以必须要 靠赢得其他人的赞同。 第四点 ，是通常说的抽象思维和分析的能力。 具体 思维的人可能比较注重细节， 但往往 也会将问题复杂化， 使头绪增多而无 法收敛。 抽象思维可以帮架构师地从 大量信息、 系统文件中 ，看出一些规律来， 而且找出与之相关的方面 ，归纳关键问题， 表述模糊的概念并将其 变成相关各方能够理解的项目构件。 ” </P>
<P>“ 最后， 我认为无论是什么样的架 构师都要具备一定的商业头脑， 业务 的知识要充分把握， 因为对业务把握 能够带来一个拥抱变化的能力， 而且 可以在设计的时候留出一点扩展的余地， 适应将来可能来临的需求变化 。 ”</P></DIV>

哎呀