也许你所在的公司最近交给你一项任务，判断你们单位是否就应用一项新的技术（如云计算）做好了准备。一般来说，出现这样的任务就说明了应用这项新技术会带来的影响尚不明确。影响可能是对财务的，整个组织的，或是运营的，所以使得这一任务具有复杂性。

　　在评估是否对应用某一新技术做好准备时，首先需要去做的是了解采用该技术所能产生的价值、所需成本以及相关的最佳实践。当然了，你能得到的任何信息在技术出现的早期阶段很可能只是夸夸其谈，即是说它们很难度量。接下来，必须去了解和分析哪些事物会阻碍组织采用新技术。最后，必须对采用新技术之后所产生的变化有一定的预见性。这项工作要求对即将采用的技术有深入的了解，同时也需要具备判断该技术可带来何种解决方案的能力。

　　有些人可能要说准备度这个事儿说起来有点儿虚，因为没人能准确预判采用新技术所带来的结果，这么做只是为了反对采用新技术而提供一些佐证罢了。在某些单位，这样的情况可能正是项目准备度分析的准确刻画。然而，大多数情况下，准备度确实为IT执行部门对选择将要采用新技术所面临的挑战提供了一些基本认识。此外，它能够帮助辨别是否有其他当务之急需要在新技术采用之前就解决，或者在采用新技术的过程中对现有项目的风险以及可能遭遇的失败等。

　　本文讲述了有关云计算准备度评估的可能性及相关问题。

　　云计算：我们准备好了吗？

　　云计算准备度评估中最棘手的问题之一是要弄清两个事情：a)那些想得到评估结果的人认为云计算是什么？b）他们对准备度评估的期望是什么。

　　下面我们进一步细谈上述两种情况：决定准备度评估成功与否的最关键因素就是首先要定义云计算：以下相关的几个问题：

　　谁是云计算的首要干系人？

　　应用云计算的期望效果是什么？

　　通过我们的云计算应用可带来哪些类型的服务？

　　我们云计算服务的主要客户是哪些人？

　　请注意，该定义不是通过硬件架构或者某种标准亦或某特定的参考实现的形式描述的，而在于理解消费者、治理主体、以及所提供服务的基础上制定的。

　　下一步，势必要搞清楚管理层期望从准备评估中得到怎样的结果。有些领导只是期望一个采用新技术的理由，而另一些则期望看到明晰的前景和具体实施路径。所谓理由，是明确价值因素以及与现运行因素之间的比较评估。如果需要的是明晰且有具体实施方案的，就必须对现有环境架构的理解，设计出一个目标（to-be）架构，并将两者进行比较分析。以上两种期望的结果都是比较理性的，而且可能同时满足。根据投入的程度而设置期望值对于这种评估是非常重要的。

　　业务是诚实的视角

　　许多领导愿意雇佣第三方顾问来做云计算评估，这是因为他们觉得这些外部人员相对于内部员工会更加客观诚实地进行评估。如果是内部员工被委派去做云计算评估的话，就会出现类似警察局里的内务部一样。若能推荐外部人员来进行评估，还是建议这样来做。

　　由于云计算有诸多目标，足够可以写一本书而非一篇文章来讨论其可能的实施路线。而本文的目的在于寻找运维上能够节约成本以及更大的敏捷性；而这些也往往是最普遍的期望。要实现这些目标就意味着必须对执行团队以往的事件管理、能力管理、以及系统可用性方面的业绩进行分析。在进行分析活动的过程中，你需要记录这些系统和过程，同时还要对整体的运维成熟度进行评分。

　　由成熟度偏中或偏低带来的么问题会随着采用云计算而放大。如果运维团队在交付基础设施服务方面不够成熟，那么添加自助服务支持、showback/chargeback、以及保证多租户安全只会进一步加重该团队的负荷。因此，对一个熟悉的行业进行IT运维水平的衡量是至关重要的。要想降低运维成本并实现敏捷就需要一个非常成熟的基础设施运维团队，他们拥有强有力的流程并实现了一定程度的自动化。

　　另外，还需要为衡量企业的业务治理、风险管理、及合规（GRC）等的成熟度选择适当的方法。弱治理模式只会成为引入云计算后政治斗争的温床。这是因为应用了云计算之后，要使IT部门保持独立性就更加困难了。此外，多租户还要求比管理竖井应用更多安全控制层。GRC方面的工作应该有助于确定组织内部有关安全和治理的问题区域，并且应在采用云计算之前得以修正。

　　在这些问题区域度量组织的业绩可能会是件费力气的事儿。人们常常隐瞒那些能够确切描述事件状态的必要关键信息——这样的情况甚至会出现在外部承包商中，要找到行业评测标准来衡量运营和GRC的成熟度是非常困难的，因为这些标准往往是咨询机构和供应商的高度机密，而且需找业务内的问题区域也可能引起激烈的反应。

　　准备度分析报告

　　如上所述，准备度判别是一项负杂而冗繁的工作，然而，将准备度结果工作传达到业务部门的方法同样繁杂。业务部门往往不具备技术上的宽度和深度来理解每一个评估点所带来的结果。例如，云计算所要求的安全控制比现有应用堆栈更高，而一般说来业务部门的领导是不会将这两方面关联起来考虑的。此外，他们可能也不能理解为什么对现有应用竖井的管理比一个集成应用架构（如云计算）要更加昂贵。

　　因此，将准备度报告作为一种概念展示给业务部门就需要将实际的因果关系在短时间内内联系起来。一种实现方法就是仪表板（dashboard）。它能够以直观方式同时展现多维数据。如图所示，它可以快速地表达大量信息，而不需要太深究其背后的标准。当然了，如果有个别人感兴趣这些建议结果是如何得出的，这也是很正常和值得期待的事情。

　　另一种交付结果的方法是使用SWOT（优势、劣势、机会、威胁）矩阵分析模型。业务领导们一般都非常善于使用SWOT分析来帮助指导业务发展。云计算准备评估的理由通过这种方式呈现是很棒的。显然，若使用路线图来描述，则要求比这些方法更多的细节来支持。

　　总结

　　为客户做了一系列的评估之后，摆在面前的事实是准备度评估提供了三个关键要素：a）对应用云计算的合理期望，b）组织内部支持和阻碍新技术采用的因素，以及c）IT成熟度模型也可以成为IT转型以及IT即服务（ITaaS）交付的驱动力。

　　云计算准备度评估也很像夜晚时走在丛林中。一不小心就会走错路迷失方向。一旦开始了，通常会想要了解与每一个研究区域相关的所有因素。然后，现实情况往往是你没有足够的时间来为项目相关的所有问题寻找答案。进行评估必须要循序渐进，并且按照计划有步骤地进行。与计划不符之处或者太过纠结于细节的计划可能会导致以下一种或多种后果：

　　－太多数据要分析
　　－死胡同
　　－过多干扰运维
　　－缺乏业务部门的支持
　　－不能按时交付

　　重中之重， 需要再三强调的是：云计算还是被许多IT职业人视作威胁。目前数据显示，公司转至云计算会导致用工量的减少。这可以说是一个短期的效应。云的确在一定程度上改变了职责和技能需求，但是，从长远来看它会刺激工作岗位的增加。可仍然有一些人由于畏惧或其他政治斗争因素而不愿配合提供评估所需的信息，制造障碍。这样的情况发生时，缺少数据或很难得到数据，那么还是请继续往下进行下去，因为这种情况对于最终评估组织是否准备好采用云计算同样是有价值的。