作为软硬件资源服务化、抽象化的云管平台，其逻辑架构如何清晰化地设计和界定？

先上图：

狭义的云管平台就是在云资源的上层，再做一层管理平台， 即资源服务层，来实现自服务界面，将服务的底层资源实现、部署策略和动态调配实现抽象化，并集成各类运维、管理和流程的工具等。
而广义的云管平台则另外包含了云资源管理平台，要形成资源统一适配器接口，来匹配底层不同的计算、网络和存储资源，实现对所有异构的资源的统一管理，这样的好处在于通过统一的资源适配接口屏蔽各位资源的差异性，同时支撑上层的服务编排与部署。
所以，我们更应该以广义的角度去设计和界定云管平台，而不是狭义的将云管平台和底层各类资源去简单适配和驱动，一方面这样做，容易将资源服务层越做越臃肿，而且还很难解耦合。另一方面，这样做的整体架构不清晰，资源变更和新增后，又会加重资源服务层的开发难度。

为实现 IT 服务管理模式转型，需要 2 部分工作 : 一部分为基础架构层建设，需要建设可编程的基础设施，软件定义基础设施，即提供 API 可通过调用 API 提供资源，如 VMware 和 PowerVM 虚拟化平台、私有云、容器云、 SDN 、软件定义存储等；另一部分为服务化工作，即需要在基础设施之上建设云管理平台， 在软件定义基础架构平台基础上建立面向业务开发测试、应用运维的 在线 服务门户，与流程管理系统对接，使开发测试、应用运维可在线申请，审批通过后，平台自动调用软件定义基础架构 API 以及运维管理工具 API 完成应用运行环境自动化交付和管理信息的自动同步 。实现基于安全合规强监管要求下的资源环境的在线自助服务、自动化部署以及部署后的变更、回收全生命周期管理。

通过上面的建设 ， 可以解决以上矛盾和问题，一方面更加快速可靠的提供开发测试、生产运行环境，解放生产力，助力加速开发测试、投产上线、业务发展；同时， 释放 IT 人力，实现资源的全生命周期闭环管理，持续跟踪精益管理 ，减少资源浪费 。