《中移动某公司BOSS系统发展演进规划.ppt》由会员分享，可在线阅读，更多相关《中移动某公司BOSS系统发展演进规划.ppt（52页珍藏版）》请在三一办公上搜索。
1、中移动XX公司BOSS系统2010年发展演进规划,2,目 录,3,XX移动BOSS系统近年来的发展回顾,建设目标：提升处理能力主要项目：BOSS集中化改造项目项目内容：全省11个地市的BOSS业务集中处理,建设目标：提升处理能力提升容灾能力主要项目：BOSS二期扩容工程（包含计费软件升级）B-BOSS项目内容：计费帐务优化容灾系统建设B-BOSS综合查询充值,01-03年,03-04年,建设目标：提升处理能力主要项目：BOSS三期扩容工程（包含代销渠道改造）结算二期项目内容：神州行、VPMN迁移代销渠道改造科目整合梦网稽核收入保障财务项目多帐户整合结算功能改造统一开通及二期扩容,04-05年,
2、BOSS集中化改造阶段,枢纽楼BOSS中心建设阶段,学院路中心扩容及改造阶段,集中,整合/优化,整合/优化,建设目标：解藕能力提升，为NGBOSS准备主要项目：BOSS四期扩容工程多帐户（帐务优化）改造计费能力提升BOSS应急系统BOSS2.0项目内容：产品管理统一门户计费能力提升多帐户（BOSS帐务优化）BOSS应急集团门户,解耦、能力提升,0607年,解藕，能力提升,BOSS系统已从以计费帐务为主的单一系统转变为集客户服务、市场、销售、计费帐务、渠道管理、日常运营统计分析等多功能于一身的全面运营支撑体系,建设目标：更大规模支持（双中心）处理能力全面能力BOSS3.0支撑能力建设主要项目：B
3、OSS五期扩容工程BOSS3.O!项目内容：BOSS拆分（双中心）应急系统开通能力提升定制终端管理（资源）渠道管理二期系统建设BOSS3.0建设项目,07,全面提升系统处理能力，系统架构优化，能力提升，,优化架构、全面提升系统性能,4,XX移动BOSS系统体系架构,话务员,客服系统C/S前台框架,客服系统展现页面,知识数据库,客服数据库,业务应用,服务请求,知识库,接触管理,基础应用,现场管理,排班/质检,权限管理,呼叫中心基础平台,WEB页面融合,5,XX移动BOSS系统现状分析,AppFrame技术架构的进一步深入运用，增强了一些关键业务子系统的支撑灵活性及可配置化手段，实现了BOSS功能
4、域的初步解藕,系统持续优化建设所取得的成绩,BOSS3.0工程的实施进一步统一了系统体系架构，调整和规范了系统的功能边界，较大程度提升了客户服务水平,6,对数据类产品营销的支撑能力有待提升，现有的产品订购模型及业务处理流程已无法满足越趋丰富的产品营销需求,系统亟待改进提升的地方,现有一些关键子系统由于是在不同时期所建设，其在系统可维护性、可管理性方面已无法满足日益提高的系统运维管控要求，需要进一步优化和改进,在取得成绩的同时，我们还要看到系统仍然存在一些亟待优化提升的地方,7,目 录,8,BOSS发展演进的驱动力,新的技术标准、技术规范推动系统向前发展,BOSS发展驱动力,企业内部管理需要系统
5、具有更高的业务管理能力,市场竞争环境的加剧，对系统灵活性、快速响应机制提出更高的要求,新的业务需求对系统提出了更高的要求,由于不同时期分别建设的多个系统参与营销和服务支撑，造成相同业务功能分散在多个系统中，急需进行系统融合,由于功能不断堆叠，原有技术架构不能满足业务发展需要,9,目 录,10,一个理想的BOSS系统目标体系架构应具备：业务完整性 包含了正确的并全面的业务概念，支持所有相关的业务活动；系统灵活性 支持业务规则的多变性，以最少的改动可以支持业务的变化和发展；技术前瞻性 除了支持现有的业务需求、解决短期问题外，还可以支持行业里的先进规范（如中移动NGOSS）与企业里未来的需求（如3G
6、、融合计费等）架构合理性 依照业务功能相关度、数据相关性和独立性分析等，决定模块的划分，及各模块的耦合程度，并体现模块间松耦合的思路。这同时也是制定系统间接口和接口重用性的重要基础安全健壮性 作为最关键的业务支撑系统，规划设计从结构上是否足够安全、健壮，在体系架构上保证业务连续运营；数据集成性 目标体系架构中的数据框架与数据流程具有连贯性和一致性，由于单独的数据所体现的价值往往比相关联的数据来的少，数据间的连贯性可加强数据的未来作分析的价值，并形成了清晰的业务支撑网数据视图接口规范性 模块间耦合的好坏都取决于模块间接口的稳定性和接口的效率。不论是同步、异步、实时还是批量接口，其设计必须要符合规
7、范和标准，更重要的是还要形成接口的体系框架用户友好性 系统是否能方便业务操作，降低用户使用成本、提高业务效率、方便业务管理，从而提高是否能提高客户满意度；,8个纬度,5个视角,客户视角系统使用者、操作者视角市场人员视角 系统建设者视角 系统维护者视角,通过5个视角对8个纬度的分析，理想BOSS系统系统架构应具备的能力,11,业务种类和业务容量增长及对BOSS业务灵活性、规则可见的要求，为保证系统的稳定和可持续发展,可以从以下几方面进行控制,行动措施,在明确BOSS总体发展目标后，需要从数据模型、业务流程、系统架构、运维管控层面来规划现有系统的演进目标,12,优化现有系统业务处理流程，逐步解藕系
8、统功能模块改进提升BOSS核心业务模型，基于SID规范设计各系统间可共享的信息数据模型构件化系统功能服务，在共享信息数据模型上，以SOA架构来部署BOSS各系统应用,融合计费帐务,在系统体系架构演进方面要逐步实现松散耦合的系统交互，逐步构件化BOSS业务服务，最终推动BOSS体系架构向SOA方向演进,13,通过构建基于规则引擎的业务流程处理模式，逐步实现代码与业务流程的分离、业务数据与流程的分离，适应快速业务开发的需要，降低代码上线的频率，增强BOSS系统运行的稳定性及支撑灵活性,在系统业务流程实现方面逐步引入规则引擎，实现业务流程及业务规则的灵活配置，提升BOSS系统的业务支撑能力,14,目
9、 录,15,08年BOSS系统发展演进的建设措施规划,系统体系架构演进方面,系统业务支撑能力优化方面,系统运维管控能力提升方面,需进一步论证和探讨的优化措施（暂无结论),需求已明确，待重点建设的优化措施,需求已明确，建议实施的优化措施,按地市继续纵向拆分BOSS系统按功能域(营业/帐务)拆分系统引入新的技术架构及业务架构，逐步重构营帐核心服务，实现系统业务支撑模式的全面转型,构建BOSS营帐历史库，实现业务数据的分级管理,综合查询系统能力提升统一资源管理平台建设用户对帐单规范化建设产品营销的支撑能力提升渠道营销能力完善和提升,CBOSS系统的功能优化,业务受理规则的集中管控平台建设MDB容灾能
10、力建设业务模块编译、发布管理系统建设,BOSS业务自动化测试系统的建设面向运维管控的内部门户系统建设系统服务集成配置支撑平台建设,16,BOSS体系架构演进方面的3个探讨性课题,17,系统体系架构演进方面的探讨性课题1按地市继续纵向拆分BOSS系统，形成三中心或多中心架构,18,BOSS系统横向拆分的驱动力分析,外部视角,NGBOSS目标架构,集团公司对BOSS未来发展的规划由OneCM企业战略推动BOSS向NGBOSS演进，发挥规模优势通过C/P拆分，提升支撑系统的营销能力，加强客户关系的管理,系统体系架构演进方面的探讨性课题2推动BOSS向CRM方向演进，按功能域营业、帐务计费横向拆分BO
11、SS系统,19,BOSS系统横向拆分的驱动力分析,既然BOSS是面向生产的系统，其核心价值在于复杂资费条件下的高效业务计费能力CRM是面向营销的系统，其核心价值在于多变营销环境下的快速语义表达和服务提供能力 在同一套系统中实现两套完全不同的数据核心建模，必然顾此失彼那么为什么不能结合BOSS与CRM的优势，采用某种方式的融合，继续发挥BOSS作为生产系统的复杂资费下的高效业务计费能力，让CRM发挥在多变营销环境下的快速语义表达和服务提供能力？从而使两个系统在不同建设目标指导下，设计发展不同的数据核心模型，以及不同的应用实现框架，在整体层面上去提升BOSS系统的业务支撑能力以及产品营销能力,内部
12、视角,系统体系架构演进方面的探讨性课题2推动BOSS向CRM方向演进，按功能域营业、帐务计费横向拆分BOSS系统(续1）,20,BOSS按功能域横向拆分的总体建设思路,系统体系架构演进方面的探讨性课题2 BOSS系统横向拆分总体建设方案,21,BOSS横向拆分的目标功能架构,系统体系架构演进方面的探讨性课题2 BOSS系统横向拆分总体建设方案（续1）,22,BOSS系统横向拆分总体建设方案营帐核心数据实体的拆分方案,拆分后的营业子系统数据域,拆分后的帐务子系统,目前BOSS营帐子系统中涉及客户资料和营销资料的数据库实体全部划到营业子系统，从系统层面只有营业子系统才保留完整的客户资料；,把目前B
13、OSS营帐子系统中涉及资金、帐单、催缴计划的所有实体都划入帐务管理子系统，在帐务管理子系统中这三个核心模块之间通过各自实体上的ACC_ID进行关联，各实体上的ACC_ID也是帐务管理子系统与营业子系统中核心资料联系的唯一纽带；,23,BOSS系统横向拆分总体建设方案拆分后前端营业系统与后端融合帐务计费系统间的接口方式及原则,24,BOSS系统横向拆分总体建设方案营帐数据域拆分后原有营帐关键业务的实现流程,25,BOSS系统横向拆分总体建设方案营帐数据域拆分后原有营帐关键业务的实现流程（续1）,26,系统体系架构演进方面的探讨性课题3对引入新技术平台、业务架构的总体考虑,市场人员,维护人员,建设
14、人员,对于系统架构的发展演进，各相关人员所提出的能力要求最终聚焦在两个方面：系统具备较高稳定性系统支撑具备较高灵活性07年我们通过BOSS双中心拆分，较大程度增强了系统稳定性，那么08年我们是否可以通过新技术架构、业务架构的深入应用，在提升系统支撑灵活性方面来做出有价值的实践和探索,27,系统体系架构演进方面的探讨性课题3新技术架构、业务架构的支撑能力度分析,BOSS新体系架构的组成,基于新的体系架构，我们能够实现：将现有面向功能垂直式的系统开发模式转变为流程导向，面向服务的开发模式实现业务规则可配置及检测点的动态定义实现业务流程与业务数据的分离，从而支撑业务流程的灵活配置实现业务过程的可视化
15、开发，及服务组件的规范化管理从而，我们能为系统相关人员带来：满足市场人员新需求的快速上线，极大缩短响应周期业务流程的灵活配置，支持市场营销的快速变化快速的产品推广，缩短产品上市周期，增强市场竞争力满足维护人员系统具有较高的配置能力系统服务间松散耦合系统具有运行监控能力满足建设人员服务组件可管理，业务规则可见配置多于代码开发，新业务实现快速部署开发成本可控，人员投入合理,28,系统体系架构演进方面的探讨性课题3新技术平台及业务架构的演进实施策略,第一阶段 在WEB服务层与CORBA层间引入EJB服务层,基于APPFRAME平台的构建EJB服务层实现部分核心业务流程的重构和前移在EJB服务层实现资
16、源平台、规则平台服务接口的应用集成,第二阶段 EJB服务层实现BOSS全部对外服务接口的封装,实现CORBA服务接口的全部迁移，统一由EJB层对外提供基于AppFrame业务架构完整构建部分业务的整体处理流程仍需继续保留的CORBA接口以系统内部服务组件的形式纳 入EJB层注册管理,第三阶段 在EJB服务层全面重构BOSS后台服务，实现系统体系架构的最终转型,逐步将系统CORBA服务全面迁移至EJB服务层，完成BOSS业务处理流程的完整重构利用APPFRAME平台提供业务框架、流程框架实现流程驱动的业务处理模式，以及面向服务的业务过程组装模式这种体系架构的演进过程，也是NGBOSS的建设过程；
17、发展演进的结果不仅实现了BOSS体系架构的整体转型，同时也满足了NGBOSS的建设目标,29,BOSS营帐历史库的总体建设思路,30,系统体系架构演进方面 营帐历史库的建设,营帐历史库建设定位,营帐历史库建设目标,历史数据归档的定位历史库只针对过往业务历史数据中已超过生命周期的历史数据实施归档和存储而当前业务数据以及还在生命周期内的历史数据仍保存在生产库中历史库使用的定位历史库主要针对系统维护人员及营业人员提供用户的相关历史信息查询,用于报障处理及问题分析历史库不直接面向客户为其提供信息查询,通过营帐历史库的建设，实现BOSS业务历史数据的分级管理和存储，保障生产库数据规模维持在一定的增长水平
18、，从而提高BOSS系统的总体运行效率通过构建历史数据迁移控制平台，实现对迁移目标、规则、及迁移方式的配置，并通过自动化的数据迁移模块实现营帐历史数据的自动迁移，提高历史数据维护的工作效率，降低迁移过程的复杂度,31,BOSS营帐历史库建设历史数据迁移控制平台建设方案,32,BOSS系统业务功能支撑能力提升建设措施,33,详单查询子系统提供历史详单、实时详单查询,帐单查询子系统提供月帐单和即时日帐单的费用信息查询,综合查询子系统集成完善各类业务平台的查询功能，提供一个完整的查询环境,外围系统接口,系统功能域,BOSS综合查询系统现状,系统体系架构,现有系统功能模块在运行期间缺乏必要的日志、状态等
19、信息输出，造成系统的运行期管控能力较低，可维护手段较为有限，对故障的定位及解决周期较长,由于存储方式的限制，造成详单查询应用存在单点故障隐患，整个综合查询系统的容灾能力、连续运营能力无法得到有力保障,现有详单数据导出导入周期较长，且容易出错，造成BOSS系统对外提供历史详单查询的时间无法较好控制，对客户的服务承诺也无法获得保障，降低了客户服务满意度,当前的综合查询系统与BOSS营帐数据库间的耦合性较强，营帐库的不稳定会直接导致查询系统的服务中断,综合查询系统支撑能力提升现有系统的发展现状及问题,34,综合查询系统支撑能力提升改造详单文件的存储集成方式，优化详单数据的导出导入流程，提高系统服务的
20、高可用性及数据对外提供的及时性,引入VERITAS CFS系统软件，实现详单查询应用的分布式部署，解决系统单点故障问题，提升系统的整体容灾能力,统一目前系统中实时详单和历史详单的文件存储格式，当月及上月数据不压缩，历史数据实施压缩基于统一的文件格式，重构系统的详单查询应用；同时完善错单、迟到话单、入库失败话单的处理流程，实现查询时的动态数据调整单独设计实现详单接收及存储管理模块，负责接收计费系统分发过来的计费话单，进行相应的数据格式转换并存储,35,综合查询系统支撑能力提升优化现有系统体系架构，增强系统运行期的管控能力,基于AppFrame平台重构综合查询系统WEB服务层，实现查询应用服务的集
21、中部署借助Appframe平台所提供的服务运行状态监控机制，来实现查询系统服务的运行期管控，以及异常情况下的问题快速定位重新梳理和部署系统对外提供的查询接口，减少服务接口间的相互影响，增大数据查询处理的吞吐量充分利用营帐BC库，降低查询系统与营帐生产库的耦合性,36,CBOSS系统业务支撑能力的优化提升优化现有系统架构，增强系统服务的可持续运营能力，提高集团考核成绩,采用系统专人负责制，一老带新，全面提高全体组员的维护能力,落地方业务服务过于集中，单个业务的问题会导致整个CBOSS异常,采用系统专人负责制，一老带新，全面提高全体组员的维护能力,应用系统版本混乱，测试环境不完整，不利于上线版本的
22、稳定,采用系统专人负责制，一老带新，全面提高全体组员的维护能力,应用系统灵活性不够，新功能开发周期长,系统发展现状及问题,37,CBOSS系统的优化建设总体思路,38,构建统一资源管理平台，提升BOSS系统营销资源的运营管理能力,目前BOSS系统重点实现了对号码、SIM卡、有价卡、发票、手机终端、积分兑换实物等资源的管理,目前资源管理功能与上层业务应用服务间耦合性较强，资源的功能调整会影响业务的稳定运行,目前BOSS系统营销资源的管理现状及问题,目前营销资源数据并未实现集中化管理，一些资源数据仍然散落在业务子系统中,现有系统对营销资源管理的功能建设较为分散，缺乏统一的规划和定义；同时在对资源管
23、理流程方面系统缺乏灵活的规则配置,39,BOSS统一资源管理平台建设思路,资源数据域改造,梳理和调整现有资源实体模型，增强实体对资源生命周期流程管理的支撑能力，并形成较为独立的资源实体数据域,资源业务功能域改造,收敛各业务系统中的资源管理服务，构建独立部署的资源业务功能域；并引入工作流平台，实现面向各类资源业务的统一处理流程框架，并支持流程规则的灵活配置,资源业务服务接口改造,梳理整合现有资源服务接口，在其平台中构建统一的资源服务接口层，并采用分布式服务模式来降低与业务模块间的耦合度,40,BOSS系统产品受理业务支撑功能的优化建设思路,BOSS产品受理支撑的发展现状,BOSS3.0实施前,B
24、OSS3.0建设,BOSS3.0实施后,语音产品、数据产品的受理仍然由不同功能域来支撑，未实现融合用户订购关系分散在不同业务系统中对语音、数据产品的组合营销缺乏有效支撑,41,BOSS系统产品受理业务支撑功能的优化建设思路,BOSS营业库,统一产品管理平台,BOSS营业库,统一的产品订单处理流程,产品受理优化建设总体思路,用户产品订购关系管理方面,扩展现有营业系统内的用户订购模型，针对数据类产品以及产品组合包新增对应的订购关系实体，从而实现用户订购关系模型的统一以及订购数据域的统一,产品受理支撑流程方面,基于产品管理平台，融合语音产品、数据产品的订购业务流程，实现统一的产品订购支撑功能域，对外
25、提供统一的产品的订购服务接口针对数据产品，以及数据产品的组合营销包，引入订单处理模式，从而实现对长业务流程的支撑,产品配置及销售方面,基于统一产品平台，实现各类产品组合包的定义，允许不同产品间进行组合打包销售 在产品前台受理方面，提供目录化的产品查询、展现方式，并实现产品查找的关键词定位或拼音定位，提高产品营销的服务效率,42,用户对帐单规范化建设，提高客户话费信息满意度,用户对帐单规范化改进方向,43,用户对帐单规范化建设，提高客户话费信息满意度,用户对帐单规范化总体实施思路,实现系统后付费保底类套餐向包打套餐模式的迁移,统一采用免费资源来实现预付费套餐中的话费优惠，同时免费资源只体现对通信
26、量的优惠,基于产品受理支撑优化的成果，实现用户对帐单中全面体现产品组合包,新增用户通信量的计算汇总科目，能够按照不同通话类型将用户的通信量体现在对账单上,构建一套完整、清晰的科目体系；明确各科目的定义及科目间的关系，将现科目间的网状关系梳理优化成层次关系,针对各类套餐模板设计其专属的对帐单科目体系；并可以根据用户层面的需求分为较粗粒度的科目展现以及细颗粒度的科目展现,44,BOSS系统渠道营销能力提升建设思路,BOSS系统渠道营销能力提升建设,构建完整的客户信息模型，明确客户信息分层展现的内容和规则，并制定不同业务场景下客户信息展现和使用规范 整合各系统域客户信息，构建统一客户视图，实现在各类
27、服务渠道窗口的统一展现,在BOSS系统中逐步引入订单流程模式，实现对系统部分核心和主流业务的预约受理功能 满足进一步捆绑客户的业务需求以及系统中断时，核心业务可持续受理需求,基于统一资源管理平台，重构现有系统中的“直供号码包”功能，切实满足实际生产需求 实现渠道管理系统的WAP门户，支持操作人员的WAP方式接入,完善客户统一信息视图，提升客户信息管理能力,优化渠道营销资源的支撑能力，实现渠道WAP方式接入,建设实现对预约营销模式的支撑，提升客户服务质量,45,BOSS系统运维管控能力提升建设措施,46,构建业务受理规则集中管控平台，提升BOSS系统业务规则的可维护性及业务运营的管控能力,与业务
28、受理相关的业务规则分散在BOSS系统各模块中，部分规则是固化在程序中、部分是通过数据库SQL语言进行配置的,受理规则的校验较为分散，增加了系统变更的风险和测试的压力,目前BOSS系统业务受理规则的管理现状及问题,在规则管理上缺乏退出机制，造成规则数量众多，冗余度大；在一定程度上影响了系统的运行效率，增加了业务受理的时长,业务受理规则的维护缺乏整体控制，规则与规则间关系难于理清，不可避免的存在规则冲突、规则重复等情况,47,BOSS业务受理规则管控平台建设思路,规则维护WEB服务层(BOSS业务门户),业务受理规则服务接口层,规则维护,规则查询,业务规则引擎,规则管控平台应用服务层,业务规则库（
29、公共数据库）,BOSS营业功能域,渠道功能域,其他外围系统,规则校验服务调用,规则校验服务,业务受理规则集中管控平台的总体建设思路,通过规则引擎产品实现对系统业务受理规则的集中化管理；进而实现业务规则的业务语言化及可视化配置改造现有的业务受理流程，由该平台统一提供标准化的规则判断服务接口，将分散式的业务受理规则判断逻辑进行收敛；从而优化系统架构，提升系统的可持续发展能力 基于该平台实现系统业务规则的目录化管理平台的后续发展。该平台今后将考虑扩展到业务受理流程的规则配置，实现BOSS业务从受理流程到受理规则的可视化配置管理，不仅能够提升系统的管控能力，同时也缩短业务实现的周期,48,生产MDB,
30、事务处理线程,事务处理线程,事务处理线程,热备份MDB,数据同步处理模块,数据发送队列,数据接收队列,TCP网络,REDO内存区,REDO内存区,REDO内存区,改造MDB内部的事务控制机制，为内部事务处理线程对应增加数据重处理内存区域，该区域内主要记录当前事务所操作的数据、表、位置、及操作类型,在MDB外部新增数据接收、发送队列；并在主备MDB间建立数据发送/接收通道,建设实现MDB系统的HA，增强BOSS计费帐务系统MDB的容灾能力,49,BOSS发展演进的建设措施系统运维管控能力提升建设,运维管控门户建设,BOSS系统运维管控能力提升的优化建设措施,服务集成的配置管理平台建设,业务自动化
31、测试系统建设,业务功能上线管理系统建设,实现各类维护管理子系统的功能融合，并以门户平台的方式为运维人员集中提供各种系统操作工具通过管控门户的构建，规范对系统的维护操作，加强系统维护的安全性，以及监控、追溯能力,基于AIGA测试平台，构建BOSS业务的自动化测试系统实现对BOSS业务的快速回归测试，缩短业务测试上线周期，有效降低人工成本,构建面向功能模块上线流程的管理支撑系统，实现对业务模块上线期间的全程管理和监控该系统实现对业务代码的自动化编译,以及功能模块的自动化发布功能,实现BOSS应用服务间连接配置信息的模板化，引导管理人员完成配置文件的定义实现对应用服务间连接配置文件的自动化生成，降低
32、配置错误，减少系统上线风险,50,目 录,51,XX移动BOSS系统发展演进的建设步骤,08年度项目规划,09年度远期规划,综合查询系统二期,管控能力提升,体系架构演进,用户对帐单规范化建设,产品营销能力提升,CBOSS系统优化,统一资源管理平台建设,业务规则管理平台建设,渠道营销能力提升,统一接口平台建设,MDB容灾能力建设,BOSS管控统一门户建设,系统应用服务集成配置管理系统,AIGA自动化测试系统建设,编译、发布管理系统,BOSS历史库建设,BOSS体系架构优化,数据库升级,针对体系架构优化，建议采用引入EJB服务层来逐步解藕BOSS系统在逐步迁移业务功能模块的同时，梳理营业、帐务应用模块，为后续NGBOSS演进奠定技术支撑基础,NGBOSS建设,计费实时帐务,其他,“深入优化、逐步演进”,52,谢 谢！,
