混合云架构困难重重。

　　首先，方案的整体规划，需要将传统的本地IT架构和公开以及私有云部署融合在一起，涵盖不同系统的集成，同时还要保证安全性。为这样的规划做准备需要海量的管控工作。管理如此多样复杂的新环境令众多企业烦恼不堪。错误不可避免——有时候还是重大失误。

　　咨询师David Linthicum说，在实施混合云架构上很多企业之前都会犯的一个错误是从OpenStack开始。 IT企业使用开源云软件平台来构建私有云，它提供了类似公有云的功能，但是使用的是内部架构。这么做很合理，但很多企业并没有真正理解他们会面临的问题。

　“他们采取的方案会遇到很多工程难题，因此最终不是超支，就是很快便放弃了，”Linthicum说。

　　对于很多企业而言，问题在于他们过于相信私有云的魔力——它可靠且易实现，是公有云的替代方案，Linthicum说，

　　“咨询师们都知道，”部署私有云的复杂度，“外部的确没有很好地沟通”，他说。

　　如今，更好地理解了技术，并且拥有了更好的工具，企业在实施混合云架构时不会那么容易犯致命错误了；但是每当新产品出现时，市场上的噪音对企业会产生负面影响，咨询公司Hurwitz & Associates的董事长Judith Hurwitz说。

　　使用软件即服务。当SaaS应用首次面世时，业界热闹非凡，各大企业欣喜若狂。他们能够在数秒内下载一个应用并且运行起来——而无需理会IT的繁文缛节。这样非常便利，直到每个部门都有30个SaaS应用时，IT被叫来清理现场。

　　“这样的场景在每一代技术的更迭中都会发生，无论是客户端-服务器或者各种计算浪潮里，大家都想自己完成想要的东西，因为等待IT处理太让人烦躁了，”Hurwitz说，指的是新企业技术的仓促忙乱的引入。

　　没有计划，没有底层架构，同时没有管理众多web应用的管控框架，这些只是很多IT部门困扰的开始，Hurwitz说。

　　不能头痛医头脚痛医脚，IT部门需要学习如何预防问题的发生：和业务部门一起，倾听用户的需求。

　　“因此不是IT说不。IT部门应该说，‘我们有专家，有经验，让我们一起来让这个变成现实’，”她说。

　　Hurwitz的所说的部门间的结盟也是另外一种IT错误。IBM工程师Rajesh Jaluka曾经负责管理一家大型医院系统的IT项目 -- 项目原因不方面透露医院的名字 -- 中央IT部门没有开发任何关于下属医院之间如何完成工作的技术标准。

　　“他们的确期望我们，作为引入技术的外部开发团队，来驱动标准，因此他们并没有积极参与其中，”Jaluka说。

　　缺乏参与是致命的。Jaluka说他的IT团队负责的中央数据库的其中一个和自动化绑定了 ——并且接入了病人监控系统。自动化是由“事件”触发的，比如数据库更新。但是没有任何文档记录了是什么触发自动化。错误的消息甚至可能会重启机器。

　　“如果做错了什么，那么就会影响到病人，甚至可能带来生命危险，”他说。

　　标准也是Pamela Wise-Martinez的头等大事，她是保护养老金的政府机构的首席云和企业数据架构师。她认为拥有坚实的企业架构— 展现需求和业务部门以及IT部门期望的蓝图—在任何IT项目交付之前是最重要的，无论是像部署混合云架构这么复杂且大规模的事情，还是仅仅需要优化一条业务流程。

　　“如果没有企业架构师参与，那么就不可能理解如何会影响到企业的其他部门，”她说。

　　美国政府也遇到过类似的问题。在二十世纪早期，当引入面向服务架构来在机构之间共享并提供数据时，就遇到了类似的困难。

　　“我们只是在这个领域没有足够的知识和培训，因此联邦政府发现要达到目的非常困难，”Wise-Martinez说。

　　在实施混合云架构时没有足够的知识储备，会导致一系列的后果。Linthicum说欧洲企业通常会犯的一个错误是将财务数据迁移到公有云上，因此这些数据会挪动到国家之外，这是违反欧盟数据保护法的。

　　“他们选用了某个系统，并迁移过去的时候，实际上完全没有理解为什么要这么做，”Linthicum说，“这些他们只能在监管部门发现之前尽快悄悄地挪回来。”

　　但是IT领域的错误也有其自身价值。Hurwitz引用了90年代的客户端-服务器计算模型。

　　“我杜撰了一个词，称之为‘胖客户端综合征’，”她说。“将这么多的逻辑和数据放置到每个客户端并最终让其不堪重负。”

　　错误的根源也很简单：技术还没发展成熟。但是这一失败中却推进了分布式计算步，让业务用户比之前任何时候更为强大。

　　“如果不犯错，那么就会永远停滞不前，”Hurwitz说。“因此我认为这是科技世界必经的创造性破坏阶段。”