在深入探讨混合云计算之前，要想在企业内部高效使用混合云，规划师们需要先理解一些知识。
本文探讨云规划师必须牢牢记住的核心思想和策略，有关混合云工作流管理和集成，包括理解混合化的四大主要驱动力。
几乎所有企业都坚信他们会成为公有云计算的客户，至少在小规模下，而且很多企业已经开始使用了。他们也坚信在未来还是会自己搭建本地内部的数据中心。于是，混合云，与其说是云方案选择之一，不如说是云方案的必然结果。云规划师必须理解混合化的驱动力，制定出能够集成混合云所隔离开资源的混合云策略，并且在日益动态的未来管理好工作流。
如果我们接受(也应该接受)企业长期需要数据中心的需求，由于公有云服务能够以各种方式辅助到这些数据中心，那么混合云的需求就自然而然出现了。目前混合化的四大驱动因素是：
服务器整合，这也是驱动虚拟化的趋势，如果低使用率的应用特定服务器能够托管在公有云上，这一趋势将会继续向前推进。基于非常低的使用级别，以及相同的应用运行在多个、广泛隔离的卫星式分布的环境里，云环境无疑是***选择。
云爆发所需的扩展能力来匹配需求并且替换故障组件。企业意识到如果应用设计上考虑到支持这一场景，那么公有云能够在极端情况下作为内部IT资源的有力补充。
生产部门购买的作为服务的应用。尽管很少有生产企业真正准备好将其应用部署到IaaS上并且管理它们，但是大多数企业都认为他们很高兴能够至少以服务的模式购买一些应用程序。这是创建通常称为“影子IT”的趋势，企业有着一些CIO不知道的应用程序，直到有人提出这些应用程序需要集成。
核心应用里日益增长的敏捷需求。如果没有影子IT，不需要服务器整合，那么企业会毫无疑问得选用公有云服务。移动工作的能力以及为竞争问题，机遇或者公开政策变化来创建快速业务响应的需求，所有这些都鼓励企业至少将核心应用分解成前端/后端架构，前端托管在云上，后端放在自己的数据中心里。
对于云规划师或CIO而言，这些驱动因素带来的问题是他们几乎无法为之计划的特殊情况。影子IT，究其根本是私密性。敏捷性是解决意料之外的问题或者机遇的有效方法。混合化从而意味着构建混合云架构，能够在问题出现时快速适应。
混合架构必须集成单独的应用和数据元素。要想使之能够工作，必须定义混合模型，以及在支持该模型的混合云中所需的工具和技术。如果这些都完成了，那么新的混合元素就能适应该模型，也就能够按照计划工作。
混合云架构先要了解支持终端用户的应用所特有的前端/后端特性。应用可以分为和信息展示相关的部分、GUI，以及用户通知和支持，这些部分天然云友好。这部分必须被清晰得隔离出来，前端后端之间的工作流必须设计成能够高效通过云边界。后台组件，设计为驻留在数据中心里，也必须“分层”，这样被设计用来更新敏感和业务至关重要的数据库的部分，数据编辑以及分析流程能够松耦合。这样能够创建出应用程序的三层架构，最上层是UI，最下层是数据库更新。
第二步是将云边界可视化，能够展现成从上到下的部分。在每个部分，边界需要穿透为混合云使用做过优化的应用连接，并且也能够改变费用和风险。比如，将云边界推到堆栈的底部会导致巨大的数据库风险以及托管费用，因此似乎只在大规模IT故障的时候才需要这么做。在从上至下的每一步里，云边界位置预示着一系列的将边界设置于此的条件，以及一系列在这个点云边界所需的强制策略。
第三步是选择一种云工作流管理和集成策略，尽可能在所有层都能够统一，并且使用工作队列在各层之间实现松耦合。这一步的目标是确保如果在云和数据中心的给定应用层里移动组件，流程在技术组件连接的级别上是一致的。没有这一步的话，每个组件的移动都需要自定义。
当已经拥有混合架构映射的时候，针对改变的动态驱动来测试已有方案至关重要。敏捷业务支持的基准线标准是优秀的企业架构模型，使用现代框架(比如 TOGAF)，以及通过业务流程执行语言驱动的服务总线工作流。虽然这样的方案从技术角度而言很重量级，但是它能帮助实现通过连接组件成一个业务流程来 “组合”出一个应用。不管你怎么做，在三层混合架构的任何一层，都必须实现同样的目标。
上述所有的混合驱动因素会导致云边界的移动，边界也会由于内部或云上的花费，云链接的性能以及是否有足够技能的员工团队维护内部应用程序等因素的改变而变化。混合化的敏捷架构可能无法防止所有这些问题(通常是激烈的冲突)的发生，但是它能够确保你对这些问题的响应能够足够高效。
