电信运营商BOSS建设流程分析与探讨

谢晓军，胡军军

（中国电信股份有限公司广东研究院 广州510630）

1 引言

通过收购和重组，电信行业进入了全业务竞争时代[1]，尤其是移动业务的竞争日趋白热化，电信运营商纷纷启动以客户为中心的企业转型之路，越来越重视与客户体验紧密关联的BOSS（business & operation support system）建设。在总体投资减少的背景下，BOSS投资仍保持在相当的水平之上，投资占比也逐步接近发达国家电信运营商的水平。各家运营商[2～4]都逐步建成了以省分公司为主、集团公司和省分公司协同的两级应用架构，基本满足了客户产品受理、服务保障、业务计费等急迫需求，实现了面向前端的客户管理、产品管理、营销管理、经营分析等功能以及面向后端的施工调度、资源管理、开通激活等功能，全面支撑了企业各项生产和管理流程。在部署方面完成了从本地网向省公司的集中，实现了系统的统一规划，对于后期的系统运营和维护起到了降本增效的作用。然而，在技术架构方面还存在许多不尽如人意的地方，组件划分、服务抽象、数据模型和基础设施等方面存在严重的不统一和不一致的现象，这给运营商集约化业务支撑和运营管理带来了极大的困难和障碍，难以满足移动互联网时代的行业竞争需要。举例来讲，某运营商为降低成本拟推广采用LAMP（Linux+Apache+MySQL+PHP）平台，但在实际推进过程中发现供应商在省分公司建设工程中的研发仅仅是在现有系统基础上进行二次开发，受工程进度和研发成本的限制，根本无法进行LAMP平台的大规模改造和移植。要解决这些问题，仅仅关注如何设计出更加完善的目标架构是不够的，还需要对现有系统建设流程进行优化和调整，改变当前工程建设仅能基于供应商应用软件进行二次开发的局面。

2 BOSS建设流程现状

国内电信运营商BOSS建设的主要方式是软件外包，虽然最早“97系统”时期有部分自主开发以及后来省集中过程中部分进行了COTS（commercial off-the-shelf）套件的尝试，但都没有成为主流。

当前以外包为主的系统建设主要包括以下几个步骤：首先，由集团公司组织进行系统规划和规范；然后，省分公司按照集团公司要求和本省业务需求组织工程实施；其次，供应商根据省分公司工程需求进行研发；最后，省分公司组织进行验收上线运营工作。如图1所示，通常可以将其归纳为4个闭环的过程。在部分系统全国集中建设的情况下，集团公司也会组织工程实施，其过程与省分公司的实施过程类似，这里不再赘述。

第1个闭环过程是由集团公司负责的规范圈。集团公司组织各省分公司和供应商共同编制规划或规范，然后由供应商自主开发出相应的原型系统，最后由集团公司组织进行入网测试，根据测试结果将供应商纳入省分公司招投标短名单，同时集团公司根据测试情况调整规划和规范要求，以便于系统蓝图的落地和实施。这个闭环过程主要解决的是未来3～5年BOSS发展方向的问题。

第2个闭环过程是由省分公司负责的工程圈。省分公司根据集团公司规划和规范要求，结合本省本年度业务需求编制工程需求，组织招投标并选择合格的供应商负责工程实施、跟踪和管理工程进度，最后安排系统割接上线，并组织进行系统测试和验收工作。

第3个闭环过程是由供应商负责的开发圈。供应商根据省分公司提出的工程需求进行系统分析设计，然后在原有系统基础上通过配置或者编码实现定制化的二次开发，最后进行系统测试和交付。该闭环的周期有长有短，如果针对年度工程需求，大致需要几个月的时间，如果针对突发性的业务需求，如节日促销，可能只需要几周或者几天时间。

第4个闭环过程是由省分公司负责的运营圈。省分公司负责日常的系统运营维护，保障其可用性。随着互联网运营开发模式的兴起，在这个闭环中也越来越注重日常维护性开发的工作投入。

以上4个闭环过程对系统技术架构能够产生一定影响的是规范圈和开发圈。一方面，规范圈中供应商会根据规范要求进行原型开发，但由于缺乏明确的项目驱动和资金投入，原型系统质量难以保证；另一方面，开发圈的重点是进行定制性的二次开发，受工程进度和项目成本的限制，难以对技术架构进行较大的调整。这些问题导致了运营商对BOSS技术架构缺乏基本的管控能力。

3 供应商研发流程

在整个系统研发过程中，供应商根据省分公司进行定制开发只是冰山的一角，隐藏在水面下的是供应商庞大的系统研发过程体系。软件产品线工程框架[5，6]大致可以描述供应商的这一过程，如图2所示，框架将其分为领域工程和应用工程两个过程，其好处包括：更低的研发成本、更高的软件质量、更短的上市时间等。

领域工程的目的是建立可重用平台，实现产品线的通用性和可变性，与平台研发相关的主要过程步骤包括需求、设计、实现、测试等。其中领域需求过程主要是获取和描述可重用平台共同的变化和需求，领域设计过程会确定可重用平台的参考架构，领域实现过程涉及可复用软件组件的详细设计和实现，领域测试负责对可复用组件的确认和验证。在这4个步骤中，领域设计过程形成了系统的组件划分、服务抽象和数据模型等大部分技术架构的决策，这些都会反映在可重用平台的参考架构里。另外，领域实现过程决定了系统底层平台的选择，比如是否采用LAMP。

在领域工程所建立的平台上，应用工程利用其可变性等特性，根据运营商具体需求配置和开发BOSS应用。运营商现有BOSS建设模式中的开发圈在这个框架中只是应用工程中的众多应用开发过程之一，对于技术架构的影响力也就可想而知了。

运营商希望通过规范圈统一各省分公司技术架构，从而降低系统运营和维护成本，提升业务集约化支撑的能力。然而，运营商所面对的不同供应商却有着不同的诉求，他们希望针对不同的运营商通过领域工程尽量采用统一的技术架构建设软件产品线，这样既可以降低研发难度和实施成本，也容易形成有效的技术积累和知识沉淀。通过以上分析可知，技术架构的决策起决定性作用的是领域工程，基于过往项目经验的架构理所当然地成为软件供应商的首选，于是造成了由不同供应商负责实施的BOSS技术架构存在较大差异。

4 BOSS建设流程优化建议

根据分析可知技术架构决策起决定性作用的是领域工程相关过程，因此要改变这种情况，关键是运营商需要作为重要的干系人参与到领域工程的需求、设计、实现和测试中，推动不同供应商设计出满足运营商统一技术架构要求的可重用平台。

通过优化和调整规范圈闭环的工作流程，运营商可以适度介入供应商的领域工程中，这样规范圈不仅需要交付系统规范要求，更为重要的是需要交付一套满足通用性和可变性要求的可重用平台，也许称之为领域圈更加合适，如图3所示。有了运营商参与的领域工程对于供应商而言会更加贴近市场需求，能够更加全面地考虑系统架构的影响，满足产品线更加长远的发展需要。其大致过程如下：集团公司组织供应商和省分公司共同制定领域需求（含统一的技术架构要求），通过招投标选择有实力的供应商针对领域需求开发可重用平台并提供资金支持，最后由运营商进行领域测试，确保可重用平台满足运营商技术架构统一的相关要求，如组件划分、服务抽象、数据模型和基础设施等，然后选择试点省分公司进入工程圈闭环，进一步对可重用平台进行修改和完善，最后定型推广。

与原有流程最大的不同在于两阶段工程的引入，其中重点是运营商需要介入领域工程中，这与传统的系统建设过程有所不同。在领域需求过程中，其主要目的是识别可重用平台的通用和可变需求，它不解决单个应用的需求问题，这就需要与数量众多的不同的利益相关者进行交流，研究不同来源的需求信息，归纳和整理出通用和可变的需求清单。在领域设计过程中，相对于传统的应用设计会有更多关于满足可变性要求的设计要求，参考架构必须支持大规模定制开发，需要更多地考虑可扩展性和可维护性等非功能需求。同时，运营商还需将统一技术架构所要求的组件划分、服务抽象和数据模型等贯彻其中，确保得出满足各方期望的平台参考架构。在领域实现过程中，最大的区别还是在于对可变性的支持，为未来二次开发留下足够的空间和手段，另外相对单一系统开发配置管理显得尤为重要。即使运营商不参与领域实现的工作，但是为了降低后期运营和维护的复杂性，对于基础设施和系统软件（如操作系统、数据库、中间件等）的选择也应给出一些强制性的要求。在领域测试过程中，重点是对可变性的测试。对于运营商而言，由于可重用平台不是一个完整的上线部署的系统，如何进行工程验收是一个难题。一方面，可以通过实验室测试进行验证，检验可重用平台是否满足通用性和可变性需求是否满足以及是否符合组件划分、服务抽象、数据模型、基础设施等技术架构方面的要求；另一方面，与试点工程结合也是一个有效的方法，根据试点工程的建设过程以及上线运行情况对可重用平台进行评估，作为平台最后的验收依据之一，这样也可较好地融入现有的BOSS建设流程。

从技术分层角度分析，运营商参与领域工程决策由易到难分别是硬件平台、系统软件、中间件和应用软件，当然对于总体架构的控制力度也逐步提高。其中硬件平台和系统软件的选型决策可选择范围相对较小，一般无需定制或者二次开发，而且与供应商需要协调和沟通的复杂性较低，因此介入难度较低。然而仍有可能对应用架构造成较大影响，比如将小型机平台改为x86云平台，需要对应用进行云化改造，同时还涉及自动化部署、弹性伸缩、高可用性和应用监控等方面的基础服务提供问题。中间件的介入则较为复杂，它的选择不仅影响到应用运行的环境，如数据库服务、消息服务、流程服务、会话服务、事务服务和缓存服务等，而且也影响到应用的开发、测试、发布和部署等方面的技术决策，对于运营商而言需要有相当的软件研发技术实力，而且需要与供应商进行较为密切的协调和沟通，因此介入难度较高。最为复杂的当然是应用软件的介入，这也是领域工程的核心。首先，可重用平台通用和可变需求的识别和确定，其个性化程度要远高于前三者，需求来源也更加复杂和多变；其次，平台设计过程中涉及的大规模定制开发等方面是运营商较为陌生的，即使不参与代码实现，也需要大批具备较高研发能力的人员参与其中；最后，为保证平台实现和二次开发的有效衔接，运营商有必要对研发过程进行全程管控，甚至深度参与平台测试工作。

运营商参与领域工程，尤其是涉及中间件和应用软件层面时，需要具备一定的软件研发过程管理能力。如果运营商进行可重用平台的自主研发，可以参考CMMI进行软件研发的组织和管理工作。如果仍采用软件外包的方式进行可重用平台的研发，可以对CMMI进行适当剪裁，把重点放在技术方案制定和跟踪、配置管理、问题管理、接口测试等方面。由于外包的开发工作无论是在领域工程还是应用工程阶段都可能涉及多个供应商的方案和进度的协调，因此技术方案制定和跟踪显得尤为重要，一般需要运营商和供应商共同成立专门的技术方案组来负责，除了在工程初期需要根据需求制定总体技术架构以及分工实施安排，且在工程过程中还需要根据项目组提交的各种问题和新的需求不断调整技术方案并重新进行分工安排，藉此来保证技术架构要求的跟踪和落实。

5 结束语

为满足市场的快速变化和企业战略转型的要求，电信行业BOSS建设流程仍需不断完善，运营商积极参与领域工程的需求、设计、实现和测试，推动不同供应商设计出满足运营商要求的可重用平台，对于运营商提升架构管控能力会有较大帮助。但领域工程对于电信运营商而言还比较陌生，还存在诸如质量保证、系统演进、工具保障等具体实施问题，需要笔者进一步研究和探索。

1 顾强,郑世林.中国电信体制改革政策配套效果研究.中国工业经济,2012(8)

2 李萌.BOSS管理系统研究与应用.北京邮电大学硕士学位论文,2012

3 侯蒙.IT支撑网建设和运维系统规划.北京邮电大学硕士学位论文,2012

4 柳博亮.新环境下的电信运营商信息化建设方式探讨.信息通信技术,2012(1)

5 Clements P,Northrop L.Software Product Lines:Practices and Patterns.New Jersey:Addison-Wesley,2001

6 Pohl K,B觟ckle G,Van Der Linden F.软件产品线工程.张佳骥,李彦平译.北京：国防工业出版社，2010