从OMS系统的开发看业务开发平台的形成.ppt

从oms系统的开发看业务开发平台的形成,november 8, 2019,议题,从定单调度系统开发及系统设计思路的开发演进过程，说明什么是业务开发平台；业务开发平台包含哪些东西；他为什么会为后续的服务带来扩展能力和伸缩性；在提供了开发框架平台后pso如何提供服务，研发应承担什么工作,定单调度（oms）系统介绍,定单调度系统,订单调度系统包括业务资源配置、流程调度（定单调度）及业务开通（包括施工）等功能 业务配置与业务资源管理紧密相关 业务开通功能包括即开即通（和网元或网络管理系统接口）和非即开即同（资源施工接口）两大类,网络管理,业务配置,业务开通,业务资源管理,物理及逻辑资源管理,流程调度,定单调度系统,o-crm系统,网络资源管理系统,把定单调度系统从crm独立出来，是业务能力的体现,在现有大部分系统建设模式中，前后台并不分离，前后台分离，是bpr管理体制变革和面向市场（客户）的要求 把oms系统和资源管理脱离，基于如下原因： 目前的本地网网络资源管理系统主要关注物理资源及设备的管理，其他功能较弱，特别是系统业务资源和逻辑物理资源的分隔并不明确 目前本地网网络资源管理系统实施情况几乎所有运营商范围内并不统一，进度较慢 市场驱动，管理驱动，是导致系统功能架构变革的根本原因,定单调度系统，我们希望技术创新,工作流引擎技术是定单调度系统的核心选择 和有限状态机相比，工作流技术优势明显： 贴近自然语言的描述 使用图的方式表达任务之间的关系，可以灵活调整 流程的状态，下个步骤的走向，历史路径清晰可见 修改和添加新业务维护简单 流程和业务处理，工具提供了分离的可能,业务处理逻辑和流程分离，使系统伸缩性增强。 这是采用工作流引擎技术主要期待解决的问题,开发平台的形成,总体业务技术架构很快做好了浙江网通,工作流平台,流程规则,流程环节,受理,审核,收费,通知,需求,查勘,号配置,线配置,端口配置,ip配置,程控,测量,外线,数据机房,数据外勤,多媒体中心,竣工,接入机房,产品及产品包,定单初始化,订单,环节1,环节2,环节3,调用业务处理逻辑,但没有实现与资源管理系统的分离，因此，自己做了一套资源管理,做完了，发现了很多问题,规则驱动的业务处理逻辑和数据驱动的流程要实现语义一致，必须穷举 穷举了，为了支持复杂的业务流程，我们发现流程的可调整性根本是句空话 按照流程进行分工开发，发现后台的业务逻辑根本不能重用 如果资源管理不是我们做的，发现系统接口无限复杂 系统为了满足功能，不断庞大 各地流程有很大不一致，发现系统重用的程度不高 谁写的代码，谁负责，维护困难 。 开始否定一切： 否定工作流 否定技术架构 研发内部思路不统一，对系统产品化基本绝望,怎么办？,思考半年。,忽然看到：,是不是这样？,产品的实现流程是管理岗位的工作流程 每个岗位是对一个或者多个产品的网络业务单元进行操作 网络业务单元的操作是不是只有三种：装；拆，改？ 如果细分网络业务单元，是否就能解决和网络资源管理系统的接口问题和业务逻辑重用问题？ 基于这些考虑，发现解决资源管理接口问题的关键是要做一套产品分解为网络业务单元的数据模型！,开始对异常流程进行思考,忽然想出了一注意： 反正异常也不多(出现机率20)，一旦发生异常，先放到一个异常队列里面去（客响中心） 应该要解决工作流的消息响应模型机制（技术） 挂起的订单怎么办： 问：要干什么？发现都是要干的正常的活 再想想，找到了一个新想法：自学习型订单管理系统,自学习型订单管理系统定单控制中心,配置异常编码 异常编码是原子的异常原因,又解决了一些技术问题-uwfe,基于准确，实时的原则，通过ejb和jms提供外部事件的响应模型 任务的高容错性 解决异构工作流的接口问题,效果,苏州电信的案例顺便发现了使用xml作为消息和数据传递的正确性，eai 重庆网通资源管理系统不是我们的，照样接。顺便还总结了一些系统上线的技巧（实施模式） 海南网通很快搞定了,结论,1、采用了工作流引擎技术，并构建了uwfe模块，结合appframe，解决了从页面，到工作流引擎使用，eai方面的诸多方面的问题 2、构架了对电信产品的一套网元细分方法，成为系统核心数据模型，网元提供三种方法，构成可重用的原子服务层； 3、提供了订单调度控制中心的功能，实现了异常流程的自学习（不断扩展） 4、提出了组件的概念，在实践中，实现了组装组件及部分页面逻辑的可重用,oms系统体系架构,什么是开发平台？,开发平台 统一的技术框架 核心的数据模型 一系列逐步积累的业务框架,和南京研发crm体系的比较,基于开发平台的服务模式,细腰型产品架构,业务平台,业务平台,业务平台,业务平台,技术平台,技术平台,技术平台,技术平台,核心技术,核心技术,核心技术,核心技术,核心技术,核心技术,技术,技术,技术,技术,技术,技术,技术,技术,技术,a解决方案,b解决方案,c解决方案,d解决方案,e解决方案,稳定组件,稳定功能,解决方案不是产品，产品是由稳定的功能和不稳定功能的稳定开发模式组成的，为了稳定，产品开发平台是产品的核心，不稳定的功能和组件是产品的一系列示例,不稳定组件,不稳定组件,不稳定组件,稳定功能,不稳定功能,不稳定功能,不稳定功能,研发是产品的核心,研发最为重要的职责是产品开发平台 研发需要建立对pso实施中的技术管控流程（是否采用或正确采用开发平台） 闭门造车不可能开发出产品开发平台 产品范围的扩大是个循序渐进的收敛过程,基于开发平台的开发模式积累是产品pso,螺旋模型收敛开发平台,边界轴,螺旋模型是一种迭代模型，每迭代一次，螺旋线就前进一周 在项目实施过程中存在迭代，在软件产品生命周期中也存在跌代 在不断的迭代过程中，随着螺距增大，产品日趋完善 在迭代过程中的边界轴上，需要交付相应