架构师的思考 - 估算的技巧
前面关于架构师如何思考(参见http://sbin.cn/blog/2008/06/16/perfect-architect/ 以及 http://sbin.cn/blog/2008/11/17/architecture-thinking/)进行了一些探讨,架构师应该充分理解业 务背景和需求、综合运用IT的多领域技术,对企业IT的战略、发展路线、以及某些具体的实际的需求提出分析或解决方案。所以,架构师注定要是双语的 - 可以使用业务语言和管理层沟通,可以使用很技术的语言和技术专家和工程师们沟通。
在前文中还多次强调了架构师应该充分掌握并熟练运用分类学 - 从多维度、多角度来观察、思考,并深入浅出地阐述展现自己的分析和解决方案。在实际工作中,架构师经常需要面对具有很多不确定性的需求,在具有很多不确定 性的环境下开发战略、路线图或解决方案,制定预算等。这时候,通常是两难的: 没有清晰的战略和路线图,制订了不了预算和项目计划;没有预算分析,管理层又很难批准什么战略或路线图。是Top-down呢,还是bottom-up 呢? 要解决这种困境,需要架构师们主动地、灵活地出击,抓住问题的主要“矛盾”和关键环节,拿出“高”、“中”、“低”,“近”、“中”、“远”,等一些组合 的分析,以便于管理层进行决策。
在诸多不确定性的环境下,要作出较为准确、切中要害的分析,架构师的个人经验和专业知识非常重要。除了分类学一个工具之外,还有一个小工具叫估算。
估算简单说就是四舍五入、去粗存精的过程。大家去中关村买电脑,决定自己攒机,有经验的简单一算,主板、CPU、硬盘、内存、机箱什么的,大概的价 钱就出来了。如果做的是个攒电脑的预算,就还要考虑季节价格因素什么的,可是大家为什么没有觉得为难呢?因为大家对这个价格很清楚,季节的变化范围也比较 有把握。所以,如果预算的精度要求不高,这个工作就不难。
在企业的实际项目中,问题就往往比较复杂,简单拍脑袋肯定会被管理层、项目团队等挑战,准确的数据要么根本就拿不到、算不出来,要么就非常无比费时 间费精力。架构师就就要在这个夹缝中找到出路。而灵活的“估算”就是技巧工具之一。上述那个任务如果放到大型电脑公司的供应链部门,用来做成本预测分析, 呵呵,那场景就完全不一样。呵呵,我也不是那方面的专家,下面我举另外两个例子来介绍一下“估算”的技巧和运用。
在某个IPT电话会议(Conference)项目中,PSTN Trunk的计算是项目方案设计可能要涉及的任务。全球大概四五十个local IP PBX,当前的话务量只有总数,没有各分公司的分项数据,电话会议Conf带来的额外话务量增加,没有更为准确的需求信息。可是,如果PSTN Trunk的数量不足,导致到时候线路忙,电话会议的服务就会收到影响,项目效果就会打折扣。任务分下去,几天过去了,team还没有把各地PSTN Trunk的数量拿出来。我和大家一起分析后发现,大家在尝试预测话务量增加、分解话务量,然后在换算成Trunk的需求,因为几个环节都有很大的不确定 性,所以进展很慢。我让大家停下来一起分析,转换一下思路。其实,Trunk的数量本身并不复杂,小的办公司可能是1条E1,或T1,大型的办公室可能是 10多条、20条T1,E1。当前的利用率分布也不均匀,30% -,, - 80%。大家对这次电话会议系统对话务量增加的有一个总体上的估计,大概是在原来PSTN通话时长的基础上增加20-30%的样子。好,估算的思路已经有 了。如果当前PSTN Trunk利用率在50%以下,项目则不考虑扩容,如果在50%以上,对于T1/E1,则增加一倍,应该非常充分;对于2-3条左右的T1/E1 Trunk,增加一条,应该可以满足要求。。。。很快,针对这个需求的“设计”拿出来了。
举另外一个示例,在某MPLS项目中,技术方案已经制定下来,项目上线计划初步定了下来,可是各条电路的上线日期还在不断调整。某天,管理层要求一 个财务预算 - 该季度可能支出的网络费用。坦白说,这是个很棘手的任务,各条电路工期随时都有可能调整,价格也有些不确定性。这个任务不可能交给部门的财务人员完成,他 们不熟悉解决方案,也不熟悉项目计划。这个任务不可能交给厂商完成,这是企业的内部财务预测。这时候,我做了一个灵活处理 - 祭出“估算”法宝。电路上线后的一个自然月才收费,电路上线日期基本上分为三批 - 季度第一个月一批、季度第二个月一批、第三个月一批。第一个月的变化不大,收两个月费用,第二个月和第三个月变化较大,假定均匀分布,所以一半收一个月的 费用,一半不收费用 - 再加上我所掌握的其它一些信息,所以很快得出结论::该季度可能支出的费用大概不会超过所有电路的月租费用,在所有月租的70%以上等。。。
大家说:“呵呵,博士,这是架构师吗?怎么像会计了?”。 没错,架构师必须得掌握“钱”,不谈“价格成本”的解决方案没有任务意义。技术解决方案和价格成本永远都是交缠在一起的。架构师需要掌握企业在这方面的基 本政策和知识,“估算”是其中一项重要技巧和工具。分析你的“环境”和可能做出的“假设”,大胆的“估算”吧。