一个项目的成功归功于很多因素。可若想毁掉一个项目，一个失败的设计就足够了。
团队中架构师的作用就显得很重要。架构师不仅需要眼观六路，耳听八方，对一些技术细节有相当程度的了解。而且要对项目进行中各个阶段的重点，以及对设计决定所产生的影响有充分的认识。你准备好了么？
咱们从传统项目过程中的不同阶段来说说吧。本文以虚拟化设计为案例。
我设计了一个图来帮助分析部署系统的几个阶段。
一、需求分析阶段
客户需求
在需求分析阶段，需要挖掘出客户真正在乎的需求，最好对需求进行分优先级，不能眉毛胡子一把抓。而且需求并不是一成不变，项目过程中增减需求是平常的事，但由此造成的影响要评估并更新文档。有时项目组需要和客户协商撤销或者推后某些需求。可能的原因有：造成整个方案成本大幅上升；与其它关键需求冲突；可能造成项目延迟等等。
环境的限制
这点尤其重要，却常常容易被忽略。在分析阶段尽可能挖掘限制条件，会避免后面阶段很多的问题。比如客户已经在使用NFS，并且现有维护人员有能力维护该系统。你在推荐SAN的时候就要考虑带来的影响；若客户与某大供应商有协议，你是否可以考虑其它厂商？若客户有较严格的安全性策略，设计共享时要考虑哪些部分是不可以共享的，是否需要虚拟层的防火墙等等。
假设的条件
有时在项目执行中会因为某些需要客户或第三方完成的事情不具备，而造成项目延迟。这就需要在合同中就对这些假设特别说明/，以避免后面的责任不清。比如假设客户网络环境是可以支持你的设计的，可实施时才发现上行网络的防火墙的带宽或端口限制会大大影响你的方案的性能。
比如假设你需要使用客户已有的数据库，却发现版本和你的方案不兼容。
二、设计阶段
概念设计
根据需求分析阶段的信息，应该尽快出一个概念设计的草图来描述以下信息。系统大概分几个运行环境，是否需要单独的开发和测试环境；
多个数据中心之间的联系，是ACTIVE-ACTIVE还是ACTIVE-PASSIVE；数据是否在数据中心之间同步；虚拟和物理网络如何共享等等。
逻辑设计
以概念设计为纲，逻辑设计描述了更多系统各部分的联系。HBA和光纤交换机，存储设备是如何联系的；集群是如何设计的；主要的管理软件等等
物理设计
依据逻辑设计，物理设计具体到使用什么设备和型号，与上行物理网络的联系，服务器在机柜位置的分配等等。
可能的影响和风险。
某一个设计决定可能会影响到其它设计决定，也有可能带来一些风险。需要评估风险并提出规避风险的方案。
最佳实践(Best Practice)
盲目照搬所谓的最佳实践，可能并不适合你的环境。需要知道最佳实践背后的原因和使用的环境。
重点是不仅知道做什么，还要知道为什么这么做。为了避免人们对所谓最佳实践的误解，VMware
已经将其更改为设计指导
模块和整体
虚拟化方案大概有存储、网络、主机及集群、虚拟机和管理系统几个模块，按模块设计有助于系统的深入设计一个主题。不过一定要注意模块间的关联。比如你虚拟机的内存由2G改称4G，那么集群设计中的内存就要重新考虑，同时影响到了Swap空间增长，存储也要考虑。
在设计阶段需要完成的文档有以下：
架构设计
整个系统的概述和各个组成部分的描述。
安装手册
具体的安装步骤。当然不是说要细到怎么安装vCenter，标准安装可参照已有官方文档。关键是要突出设计中针对用户环境定制的部分。比如你网卡负载均衡采用Load based teaming；集群的Admission control policy在只有20%空余资源时生效等等
衡量一个好的安装手册很简单，如果有经验的系统管理员按照安装手册部署的系统，没有和架构设计有大的偏差，应该算是可以的。
实施计划
在真实环境中项目经理负责和架构师一起制定适当的计划。干什么，什么时候完成，谁负责等等。
有经验的架构师可以分析各项任务的倚赖性，做好统筹分派。
测试计划
很重要的一步，怎么才证明你的系统符合用户要求？怎么才让客户签字？成功执行测试计划尤其重要。
运行计划
架构师要有全局观，某些设计决定对运维环境，人员能力以及成本都有影响。比如，vCenter Linked clone会让维护人员用一个管理界面管理两个vCenter；
尽可能利用脚本或者现有软件自动的功能减少重复性的人工和不必要的人为失误；考虑激活EVC，
避免以后新添服务器需要重启集群中的服务器。
本文小结：
成功的系统是怎么炼成的？
充分了解真正客户需求，并采取合适的技术方案满足需求，是关键的第一步。沟通协商能力和技术能力一样，二者不可或缺。
也要注意灵活性，有创意的解决问题。不能因为所谓技术上的完美，牺牲其它客户很在意的方面，比如成本、项目进程、人员等等。有时适当的中庸之道不失为一个可行的方案。