服务层封装绝不仅仅是概念炒作，服务封装关注的是资源的使用，它的出现最本质原因是资源管理的重点从“理清家底”向“有效使用”的转变。在下一代运营环境中，随着接入层的多样化和产品推出速度的加快，这一趋势更为明显。
对服务封装的理解往往存在误区，它往往会被与业务层资源相混淆。实际上，服务不是资源，它反映的是网络（资源）提供的能力，也有人称之为后端产品；服务配置（模板）也不是资源，而是怎样用资源，它定义的是需要哪些资源支持这个服务，怎么支持（派配）。一种服务可以有多种服务配置；服务实例也不是资源，它实际上是表示“这些资源为这个用户提供的这个服务”，通过它可以不仅可以将资源与用户关联起来，还可以管理资源从投用到退服的生命周期。
商用软件如何解决定制业务逻辑问题
商用软件具有成熟、扩展性好的数据模型和技术架构，但是，如何解决定制业务逻辑是一个难点。例如，任意选取中国电信固话业务里面的两个业务逻辑：“公务电话不能开通17909”，“直线电话不能选择Centrex业务”。这些业务逻辑与运营商的网络、业务环境甚至管理结构密切相关，商用产品中不可能穷举。而且，在下一代运营环境中，核心层的融合和智能化使得资源管理更关注接入层乃至终端层。这一层次厂商和设备种类更多，对应的资源派配业务逻辑更为复杂。
因此，商用软件必须解决定制业务逻辑如何无缝嵌入平台核心业务逻辑的问题。而这一点通过传统的面向对象的软件架构很难实现，这就需要从软件架构层面进入新的模式。
资源配置流程该放在哪里
实际上，“资源配置流程该放在哪里”的问题一直存在争论。在中国电信的资源管理系统建设早期，资源配置流程放在资源管理系统中。随着服务开通系统建设，资源配置流程逐步剥离到开通流程。然而，目前也出现一些反对的声音，因为资源配置流程涉及到的后端网络相对比较复杂，开通流程的设计人员很难懂得资源配置。
要回答这个问题，首先要搞清楚流程是什么？实际上，流程是人或者部门之间分工协作共同完成一个事务处理过程。因此，如果资源配置涉及多个部门或者系统之间的协作，则应放在整个开通流程中，以便于流程整体控制、异常处理和回滚。目前大多数业务对应的资源配置都属于这种情况。
然而，资源配置流程的设计确实是比较专业和复杂。这就要求在系统建设规划和实施层面进行有效的控制。服务开通流程平台最好能与资源管理系统并行建设。然而，针对具体情况可以有以下对策。
●对于服务开通系统已建而资源管理系统新建的情况,如果原服务开通流程系统可以支持复杂的资源配置流程，则可以采用对该平台进行同步改造的方式，将资源配置流程纳入整体流程。
●如果原服务开通流程系统不足以支持复杂的资源配置流程，则应选择新建流程平台，初期仅仅在其上新建资源配置流程，后期逐步纳入原开通流程系统的整体流程。
●对于新建资源管理系统而服务开通系统未建的情况，则最好同步选型服务开通流程平台，并将资源配置流程在该平台上实现，以利于今后服务开通流程系统的整体建设。
●如果不能做到以上的并行建设方式，则只能将资源配置流程部分纳入资源管理系统建设范畴，并与服务开通大流程采用单据交互的方式，但这种模式将不利于流程整体控制、异常处理和回滚。
资源数据准确性问题
数据是应用的基础，如何保持资源数据的持久弥新，是关系到系统建设最终成败的重要问题。要最终解决资源数据准确性问题，应坚持流程驱动为资源管理系统数据生命周期变化的主要驱动力，这里的流程包括服务开通流程、工程建设流程、维护流程等。
现网到资源系统数据的网络发现与同步是有效的补充，特别是在资源系统建设的初期以及流程不闭环的情况下（如图2所示）。
图2 资源数据的网络发现与同步
另外，TMFMTOSI规范的发展与应用值得关注。MTOSI致力于解决网络层与OSS层的接口问题，使不同的设备厂商，不同的应用之间有一个互操作的统一标准。
资源管理系统该如何实施
资源管理系统的实施是一个系统工程，需要从规划、技术和管理多个层面进行综合考虑。
首先，应该有一个统一的规划，包括业务和IT建设规划。业务需求是根本，定义好业务应用的目标、内容和边界，是资源管理建设的首要任务。IT建设规划包括新老系统的衔接、与其他系统的集成关系、方法以及系统演进路线等。
其次，应该建立统一的实施和管理部门。资源管理系统建设应纳入企业IT建设的高度加以重视。从以往的经验来看，只有管理、实施和应用部门紧密合作，资源管理系统建设才有可能成功。
再次，应该有一个长期的合作伙伴。资源管理系统建设是复杂而艰巨的，需要软件供应商、系统集成商等的良好支持。
最后，应该有一个好的软件平台。软件平台的选择应慎重，需要从建模能力、集成能力、可扩展性、售后支持等多方面综合考虑。
