从OMS系统的开发看业务开发平台的形成课件

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

网元网元网元普通电话接入配置组件用户界面工单处理服务调用管理结论1、采用了工作流引擎技术，并构建了UWFE模块，结合APOMS系统体系架构OMS系统体系架构什么是开发平台？开发平台＝统一的技术框架＋核心的数据模型＋一系列逐步积累的业务框架什么是开发平台？开发平台＝和南京研发CRM体系的比较和南京研发CRM体系的比较基于开发平台的服务模式基于开发平台的服务模式细腰型产品架构业务平台业务平台业务平台业务平台技术平台技术平台技术平台技术平台核心技术核心技术核心技术核心技术核心技术核心技术技术技术技术技术技术技术技术技术技术A解决方案B解决方案C解决方案D解决方案E解决方案稳定组件稳定功能解决方案不是产品，产品是由稳定的功能和不稳定功能的稳定开发模式组成的，为了稳定，产品开发平台是产品的核心，不稳定的功能和组件是产品的一系列示例不稳定组件不稳定组件不稳定组件稳定功能不稳定功能不稳定功能不稳定功能细腰型产品架构业务平台业务平台业务平台业务平台技术平台技术平研发是产品的核心系统3系统2系统6产品开发平台公用组件系统7系统4系统1系统5系统8研发最为重要的职责是产品开发平台研发需要建立对PSO实施中的技术管控流程（是否采用或正确采用开发平台）闭门造车不可能开发出产品开发平台产品范围的扩大是个循序渐进的收敛过程研发是产品的核心系统3系统2系统6产品开发平台公用组件系统7基于开发平台的开发模式积累是产品－PSO基于开发平台的开发模式积累是产品－PSO螺旋模型收敛开发平台边界轴需求分析框架确认二次开发产品确认螺旋模型是一种迭代模型，每迭代一次，螺旋线就前进一周在项目实施过程中存在迭代，在软件产品生命周期中也存在跌代在不断的迭代过程中，随着螺距增大，产品日趋完善在迭代过程中的边界轴上，需要交付相应产品保证跌代顺利进行螺旋模型收敛开发平台边界轴需求框架确认二次产品螺旋模型是一种“需求分析”——“框架确认”交付文档边界轴交付文档文档说明形式提供者《项目需求规格说明书》项目中涉及的客户化的需求，以及对整个产品的功能要求DocPSO《产品框架适应性分析报告》针对已有的产品框架，罗列不能适用用户需求的产品框架模块DocPSO《产品功能适应性分析报告》针对已有的产品功能点，匹配featureList，给出已经存在的和需要二次开发的软件功能模块清单DocPSO《重点功能界面原形》通过界面原型反映用户使用习惯和整个系统风格可执行文件、图片、html等PSO“需求分析”——“框架确认”边界轴交付文档文档说明形式提供者“框架确认”——“二次开发”交付文档边界轴交付文档文档说明形式提供者《产品框架变更风险确认报告》权衡各地项目产品实施的不同情况，给出框架变更的风险评估DocR&D《产品框架变更说明书》根据需求说明，如果涉及核心框架的修改，需要提供产品框架变更说明Doc，JavaDocR&D《产品框架缺陷说明书》因为各种原因，导致目前框架不能实现的，需要通过额外编写代码代替的框架缺陷DocR&D核心框架代码补丁包对产品核心框架的修正和增强CodeR&D《项目二次开发指导书》基于项目典型业务的开发实例培训等R&D《功能矩阵》从功能层面，分析出能够持久化到产品中或者只能在项目范围内部使用的功能模块列表DocR&DPSO“框架确认”——“二次开发”边界轴交付文档文档说明形式提供者“二次开发”——“最终产品确认”交付文档边界轴交付文档文档说明形式提供者《产品功能变更列表》描述能够持久化到产品中的，可以为各个项目共享的产品功能模块Doc，JavaDocR&D产品功能代码补丁包新增的和变更的产品功能模块CodeR&D《项目功能列表》描述项目特殊需求的功能Doc，JavaDocPSO项目功能代码包基于产品框架的独立开发的本地化的功能模块CodePSO“二次开发”——“最终产品确认”边界轴交付文档文档说明形式提“最终产品确认”交付文档边界轴交付文档文档说明形式提供者《产品需求规格说明书》产品实现功能的详细描述DocR&D《产品数据字典》包括数据库对象实体结构的描述和系统静态数据Doc，pdm，oomR&D《产品二次开发手册》基于产品框架的二次开发的指导，具备典型业务的开发过程和相应代码说明DocR&D《产品发布手册》包含产品发布包的结构说明，配置文件说明，以及在不同应用环境发布的步骤和配置说明DocR&D“最终产品确认”边界轴交付文档文档说明形式提供者《产品需求规谢谢选择亚信，共创成功谢谢选择亚信，共创成功从OMS系统的开发看业务开发平台的形成21December2022从OMS系统的开发看业务开发平台的形成16December议题从定单调度系统开发及系统设计思路的开发演进过程，说明什么是业务开发平台；业务开发平台包含哪些东西；他为什么会为后续的服务带来扩展能力和伸缩性；在提供了开发框架平台后PSO如何提供服务，研发应承担什么工作议题从定单调度系统开发及系统设计思路的开发演进过程，说明什么定单调度（OMS）系统介绍定单调度（OMS）系统介绍定单调度系统订单调度系统包括业务资源配置、流程调度（定单调度）及业务开通（包括施工）等功能业务配置与业务资源管理紧密相关业务开通功能包括即开即通（和网元或网络管理系统接口）和非即开即同（资源施工接口）两大类网络管理业务配置业务开通业务资源管理物理及逻辑资源管理流程调度定单调度系统O-CRM系统网络资源管理系统定单调度系统订单调度系统包括业务资源配置、流程调度（定单调度把定单调度系统从CRM独立出来，是业务能力的体现在现有大部分系统建设模式中，前后台并不分离，前后台分离，是BPR管理体制变革和面向市场（客户）的要求把OMS系统和资源管理脱离，基于如下原因：目前的本地网网络资源管理系统主要关注物理资源及设备的管理，其他功能较弱，特别是系统业务资源和逻辑物理资源的分隔并不明确目前本地网网络资源管理系统实施情况几乎所有运营商范围内并不统一，进度较慢－－市场驱动，管理驱动，是导致系统功能架构变革的根本原因把定单调度系统从CRM独立出来，是业务能力的体现在现有大部分定单调度系统，我们希望技术创新工作流引擎技术是定单调度系统的核心选择和有限状态机相比，工作流技术优势明显：贴近自然语言的描述使用图的方式表达任务之间的关系，可以灵活调整流程的状态，下个步骤的走向，历史路径清晰可见修改和添加新业务维护简单流程和业务处理，工具提供了分离的可能－－业务处理逻辑和流程分离，使系统伸缩性增强。这是采用工作流引擎技术主要期待解决的问题定单调度系统，我们希望技术创新工作流引擎技术是定单调度系统的开发平台的形成开发平台的形成总体业务技术架构很快做好了－浙江网通工作流平台流程规则流程环节受理审核收费通知需求查勘号配置线配置端口配置IP配置程控测量外线数据机房数据外勤多媒体中心竣工接入机房产品及产品包定单初始化产品1产品2订单环节1环节2环节3环节1环节2环节3环节4竣工调用业务处理逻辑 但没有实现与资源管理系统的分离，因此，自己做了一套资源管理总体业务技术架构很快做好了－浙江网通工作流平台流程规则流程环做完了，发现了很多问题规则驱动的业务处理逻辑和数据驱动的流程要实现语义一致，必须穷举穷举了，为了支持复杂的业务流程，我们发现流程的可调整性根本是句空话按照流程进行分工开发，发现后台的业务逻辑根本不能重用如果资源管理不是我们做的，发现系统接口无限复杂系统为了满足功能，不断庞大各地流程有很大不一致，发现系统重用的程度不高谁写的代码，谁负责，维护困难。。。。开始否定一切：否定工作流否定技术架构研发内部思路不统一，对系统产品化基本绝望做完了，发现了很多问题规则驱动的业务处理逻辑和数据驱动的流程怎么办？思考半年。。。。。。怎么办？思考半年。。。。。。忽然看到：营销产品包营销产品包产品产品产品产品模板产品模板网络业务功能单元网络业务功能单元网络业务功能单元网络业务功能单元忽然看到：营销产品包营销产品包产品产品产品产品模板产品模板网是不是这样？产品的实现流程是管理岗位的工作流程每个岗位是对一个或者多个产品的网络业务单元进行操作网络业务单元的操作是不是只有三种：装；拆，改？如果细分网络业务单元，是否就能解决和网络资源管理系统的接口问题和业务逻辑重用问题？基于这些考虑，发现解决资源管理接口问题的关键是要做一套产品分解为网络业务单元的数据模型！是不是这样？产品的实现流程是管理岗位的工作流程开始对异常流程进行思考忽然想出了一注意：反正异常也不多(出现机率20％)，一旦发生异常，先放到一个异常队列里面去（客响中心）应该要解决工作流的消息响应模型机制（技术）挂起的订单怎么办：问：要干什么？发现都是要干的正常的活再想想，找到了一个新想法：自学习型订单管理系统开始对异常流程进行思考忽然想出了一注意：自学习型订单管理系统－定单控制中心配置异常编码异常编码是原子的异常原因配置异常情形异常情形是一种异常状况的描述配置流程模板自学习型订单管理系统－定单控制中心配置异常编码配置异常情形配又解决了一些技术问题-UWFE基于准确，实时的原则，通过EJB和JMS提供外部事件的响应模型任务的高容错性解决异构工作流的接口问题Workflow引擎(Jbpm)基础包应用程序API工作流应用程序接口全局事务管理BEA7接口包BEA8接口包BEAStudioPlugInIBM(MQ)接口包实例修改ToolKit流程Web监控组件静态数据维护包IBMFDL同步包又解决了一些技术问题-UWFE基于准确，实时的原则，通过EJ效果苏州电信的案例－顺便发现了使用XML作为消息和数据传递的正确性，EAI重庆网通－资源管理系统不是我们的，照样接。顺便还总结了一些系统上线的技巧（实施模式）海南网通很快搞定了效果苏州电信的案例－顺便发现了使用XML作为消息和数据传递的结论1、采用了工作流引擎技术，并构建了UWFE模块，结合APPFRAME，解决了从页面，到工作流引擎使用，EAI方面的诸多方面的问题2、构架了对电信产品的一套网元细分方法，成为系统核心数据模型，网元提供三种方法，构成可重用的原子服务层；3、提供了订单调度控制中心的功能，实现了异常流程的自学习（不断扩展）4、提出了组件的概念，在实践中，实现了组装组件及部分页面逻辑的可重用

网元网元网元普通电话接入配置组件用户界面工单处理服务调用管理结论1、采用了工作流引擎技术，并构建了UWFE模块，结合APOMS系统体系架构OMS系统体系架构什么是开发平台？开发平台＝统一的技术框架＋核心的数据模型＋一系列逐步积累的业务框架什么是开发平台？开发平台＝和南京研发CRM体系的比较和南京研发CRM体系的比较基于开发平台的服务模式基于开发平台的服务模式细腰型产品架构业务平台业务平台业务平台业务平台技术平台技术平台技术平台技术平台核心技术核心技术核心技术核心技术核心技术核心技术技术技术技术技术技术技术技术技术技术A解决方案B解决方案C解决方案D解决方案E解决方案稳定组件稳定功能解决方案不是产品，产品是由稳定的功能和不稳定功能的稳定开发模式组成的，为了稳定，产品开发平台是产品的核心，不稳定的功能和组件是产品的一系列示例不稳定组件不稳定组件不稳定组件稳定功能不稳定功能不稳定功能不稳定功能细腰型产品架构业务平台业务平台业务平台业务平台技术平台技术平研发是产品的核心系统3系统2系统6产品开发平台公用组件系统7系统4系统1系统5系统8研发最为重要的职责是产品开发平台研发需要建立对PSO实施中的技术管控流程（是否采用或正确采用开发平台）闭门造车不可能开发出产品开发平台产品范围的扩大是个循序渐进的收敛过程研发是产品的核心系统3系统2系统6产品开发平台公用组件系统7基于开发平台的开发模式积累是产品－PSO基于开发平台的开发模式积累是产品－PSO螺旋模型收敛开发平台边界轴需求分析框架确认二次开发产品确认螺旋模型是一种迭代模型，每迭代一次，螺旋线就前进一周在项目实施过程中存在迭代，在软件产品生命周期中也存在跌代在不断的迭代过程中，随着螺距增大，产品日趋完善在迭代过程中的边界轴上，需要交付相应产品保证跌代顺利进行螺旋模型收敛开发平台边界轴需求框架确认二次产品螺旋模型是一种“需求分析”——“框架确认”交付文档边界轴交付文档文档说明形式提供者《项目需求规格说明书》项目中涉及的客户化的需求，以及对整个产品的功能要求DocPSO《产品框架适应性分析报告》针对已有的产品框架，罗列不能适用用户需求的产品框架模块DocPSO《产品功能适应性分析报告》针对已有的产品功能点，匹配featureList，给出已经存在的和需要二次开发的软件功能模块清单DocPSO《重点功能界面原形》通过界面原型反映用户使用习惯和整个系统风格可执行文件、图片、html等P