软件定义的数据中心的一个首要目标就是，帮助IT部门提高灵活性，为用户们迅速提供类似云服务的服务。它还承诺：以一种更协调、更简化的方式提供IT服务，从而节省资金。基础设施的各部件和服务具有如下特点：合并、完全自动化、受业务策略驱动、集中管理，以提高性能。软件定义的数据中心(SDDC)可以监测需求，并且配置适当的资源，短短数秒内即可自动响应。
为存储、网络和计算等部件开发软件定义解决方案的供应商们预测效果会很好，比如资本开支可以节省75%，运营开支可以节省55%。支持软件定义的数据中心的技术有助于消除传统数据中心在计算、网络和存储等方面的孤岛，并且夯实在许多大中型企业已成熟起来的服务器虚拟化基础设施。
不过与往常一样，光凭技术无法达到要求。SDDC需要对IT流程进行一番相当全面的重新设计，才能带来它声称有望带来的诸多优点：节省成本、提高生产力和业务灵活性。下面这五个策略可以帮助你在向软件定义的基础设施迁移的过程中尽量确保成功。
1. 从小处入手
对采用软件定义的数据中心的许多公司来说，面临的***障碍就是惰性。过去有一种误解(这一方面归咎于供应商)：公司必须一头扎入，同时改造数据中心的全部运营系统，以及/或者致力于一开始就要耗用大量资源的项目。这让人望而生畏，事实上也没有必要。
相反，你开始趟上SDDC之旅时先从一个小规模项目入手。这个小项目与某个不太显眼的服务或活动有关，仅仅涉及SDDC环境的一个层面：比如计算、网络或存储。比如说，迁移涉及数据库服务的存储工作负载就是让你有机会试水的理想项目。如果公司在不干扰服务的情况下，使用VMWare Live Migration之类的技术来动态迁移虚拟机，就有机会了解SDDC，并获得可以量化的效益，比如正常运行时间达到100%。
反过来，力争整个电子商务网站***试水SDDC可能会带来灾难。这种类型的项目涉及多个应用服务(库存、订单管理和发货)，因而需要软件定义的存储、网络和计算等方面的解决方案都无缝地协同运行。要是新的基础设施出现了什么故障或延迟――试用新技术时很可能会出现这种情况，高层管理班子一下子就会看到负面结果。要是创收系统停运，哪怕停运一分钟，***执行官也不乐意。
如果从一个小规模的非关键性项目入手，IT人员就可以迅速了解情况，并为下一个项目完善流程，因而可以在不带来业务风险的情况下，加强SDDC方面的专长。
2. 具备必要的技能
在软件定义的数据中心，IT团队需要懂得系统自动化和编排的人员。这些技能涵盖不同的技术领域，通常与业务部门、与外部服务提供商密切合作的人员或者担任跨部门角色的人员(比如系统管理员)才具备这些技能。
其次，要明白SDDC技术通常与供应商密切相关。比如说，选择一款思科的解决方案就需要在思科网络方面拥有专长的人员。根据贵公司内部拥有的技能来选择平台要容易得多，风险也要低得小，而不是试图对人员进行再培训、熟悉一种陌生的技术。即便如此，即便企业拥有一支很能干的团队，SDDC还是处于早期阶段，IT部门仍需要在培训、支持及外部咨询方面投入资金。
3. 评估遗留技术和供应商合同
没有哪个明智的IT负责人会为了采用SDDC功能而想要(或能够)丢弃并更换所有系统和供应商关系。IT部门应该根据与供应商签订的长期合同和购买力，将业务优先级纳入进来，然后根据那些关系再来决定购买怎样的SDDC。
一家公司之所以统一使用思杰桌面技术，而不是VMware技术的公司，就是出于成本、功能和供应商采购协议等原因。对这家企业而言，改用另一家供应商可能会让采购策略过于复杂，因而不太可能选择来自VMware的SDDC解决方案。另外还需要评估硬件报废状态。如果IT人员想要部署思科SDDC，但是拥有的惠普网络基础设施才用了两年，那么选择惠普解决方案有更高的经济效益。#p#
4. 重新考虑IT组织
在软件定义的基础设施看来，“没有更多的孤岛”这句口号已走到了路的尽头。CIO根本无法继续像过去那样运行IT部门，存储、网络、服务器和应用程序等不同的小组都愉快地各自工作。保持孤岛是SDDC面临的技术障碍;在SDDC中，数据必须自由流动，并且总体上加以协调。
孤岛还有悖于最终目标。在理想情形下，SDDC提供来自所有部件的更密切相关的信息，然后将该数据在整个IT部门不断分发，从而使更有效的决策和管理实现自动化。它关心的不是服务器正常运行时间或存储效率，而是用户能够按照所需的服务级别完成事务或任务吗?IT人员能多迅速地升级好系统?应用程序的运行方式支持业务部门的目标吗?
角色也在变化。如果公司部署了VMware等软件定义的计算产品，这会影响存储小组或网络小组。那些人就需要根据虚拟化基础设施以及针对SDDC优化的标准，优化并交付服务。最重要的是，人员必须以新的方式进行合作，而且常常是跨原有的边界合作。
5. 使用业务度量指标
多年来，IT部门一直在以人工和自动化的方式来监测性能，不过那些度量指标对业务部门来说常常没多大意义。如果只有10%的服务器其利用率为30%，那么提高服务器利用率并没有(貌似)明显的业务效益。相反，选择几个对业务经理们来说很重要，并且有助于衡量新基础设施成效的度量指标。有时候，那些度量指标因项目而异。
不管怎样，度量指标回过头来应与业务效应紧密相关。选择的度量指标应该能证明你在面向SDDC的新环境中支持用户有多灵活、多高效、多有效。衡量所有项目的一个共同指标是部署速度。灵活性是如今IT部门的首要驱动因素，软件定义的基础设施应该能够大幅缩短部署、升级或修复用户服务的时间，甚至可以缩短90%。
其他度量指标包括如下：
•适应实时需求的速度，这可以通过衡量与服务器和客户机之间的响应时间来了解;
•在停运时间为零的情况下迁移存储资源的功能;
•改造基础设施以运行不同应用程序的速度;
•诊断问题的速度;
•在用户停运时间为零的情况下扩展基础设施的功能;
•更换系统的速度;
•将工作负载迁移到其他基础设施(比如从AWS迁移到VMware)的速度;
•用户满意度;
•易用性;
•总体成本。
至于SDDC到底是一种技术还是一套方法，还存在一些争议。实际上，SDDC既是一种技术，又是一套方法。但是如果IT部门在开始讨论时一味着眼于该选择哪些供应商，就无法全面了解SDDC具有的价值。SDDC需要在交付和管理IT方面有一种新的思路/方向，这种思路/方向立足于业务优先级、合作和速度。
