因为众多公司采用更多的IT云服务，接洽越来越多的云服务提供商(如阿里云)，过去屡试不爽的IT塔式体系再也无法满足要求。外包咨询公司Pace Harmon的负责人Steve Keegan说：“原有的模式缺乏清晰的所有权，而想要左右横跨传统塔式结构的XX即服务方案方面的决定，需清晰的所有权。确定谁有拍板权并不是易事――是服务器团队，应用开发团队，还是数据库团队?”IT团队需围绕流程，而不是围绕技术方面(比如基础设施或应用程序)来进行重组。在流程驱动型IT组织，“大家致力于长远来看有益于组织的活动，而且职责明晰，完成工作的效率得到了提高，”Keegan如是说。

　　但这种“规划、建造、运行”的模式常常并不奏效，原因有好多。Keegan说：“决策过程仍由应用开发团队说了算。遗留应用软件的负责人不希望其左右资源投入决策的权势有所削弱。领导班子并没有让自己的管理人员负起责来、留意诸职能部门的边界。架构职能部门缺少成功所需的资源，因而变得严格监管，没有时间来做贡献、为项目和计划负责人提供规划方面的真知灼见。”那些确实成功改用“规划、建造、运行”模式的IT团队得到了领导层的明确支持，并且大规模实行变化，而不是让某些团队继续采用一贯以来的方式来运作。Keegan介绍了将IT转变成流程驱动型组织的五个要点：

　　1、在投入生产环境之前建立一种有效的闸门机制。

　　Keegan说：“明确服务转变后归谁所有的能力需整合到模式当中，以确保进入生产环境的完全是准备得到支持的变更系统。”负责这些决策的那些职能部门应该独立，但与负责建造的职能部门和负责运行的职能部门协调起来。“这种能力负责建造到运行的环节，确保一切都是正确的(以满足业务要求)，已经记录(那样它可重现和复制)，可支持的(那样电话打到求助台后，工作人员知道该怎么做)。无论是什么变化，无论什么时候需要部署，起到把关作用的闸门机制都需先考虑果真进入到生产环境后，运行部门有没有能力支持这种变化。”

　　2、征募一批业务分析人员。

　　这些IT专业人员应该能与业务部门处理好关系，而不是仅仅擅长处理应用软件，从而处理前期规划。他们会拥有业务流程方面的知识，而阐明应用领域所需要的变化，开发新的、一致的业务流程需要这种知识。Keegan说：“许多人以为业务分析人员外面多的是，实际上常常远远不够。业务分析人员提供了一种核心竞争力，能够让支持业务的底层系统满足业务部门对变化的需要。”

　　3、让架构团队负责应用规划。

　　Keegan解释：“让应用开发团队负责应用软件组合和路线图规划是好事――只要你不想停用应用软件，或简化应用软件方面的支持以及因而产生的成本。传统的应用开发负责人通常通过增添复杂性，增加应用软件套件而导致许可和维护成本增加，并加大因而产生的支持的复杂性，以扩大其控制权――因为它们只负责交付一个个项目，而不是对支持所部署系统的成本负责。”架构团队肩负的使命是，优化应用软件组合，降低总体拥有成本，及将投入的资源最大限度地利用起来。应当鼓励高效地利用应用软件套件并加以合理化改动，停用和迁移不常使用或者维护成本高昂的应用软件以及平台，并且优化成本和质量。

　　4、别在规划方面敷衍了事。

　　Keegan说：“最终形成商业方案的确定范围和规划的项目早期阶段确实值得投入足够的资源和精力，这不仅对确保投入的方向正确大有作用，还确保项目投入分配合理，因为其目的是确定范围，为此制定计划，并证明有必要投入开支以实现战略性业务目标。”计划把大约5%到10%的项目时间(及成本)用于制定商业方案。Keegan说：“花更多的时间用在规划上，不仅更加确信你会对结果感到满意，你还知道当项目正式开工的时候，你不会对计划做太多的变化。”

　　5、规划充分、人员配齐后再开始项目。

　　Keegan说：“因为不了解或者不清楚应用软件组合方面的约束，企业高管以及其他领导人插手干预，试图确定自认为合理的预算和时间表，而这种时间表也许现实，也许不现实。”要充分利用应用软件组合规划职能部门，确定优先级，明确首先需要哪种XX即服务方案。

　　英文：http://www.networkworld.com/article/2838575/cloud-computing/5-tips-for-transforming-enterprise-it-towers-into-cloud-services.html