000_ctgmboss oss 2.5_分总册_培训材料.pptVIP

OSS规范发展历程 OSS 2.5 背景 OSS 2.5 规范体系 成果概览 OSS 2.5规范的主题聚集点 要点2：概念体系的调整 要点3：OSS承接订单拆分功能 要点4：保障类系统的融合 要点5：建设运营服务分析系统（ODS-O） * * * * * 目录 OSS提升点 OSS服务能力的包装和提供 一体化和共享化的技术架构 实现有序、持续地发展 技术架构发展目标 存在的主要问题 系统架构发展目标 OSS系统纵向互联互通不顺畅，无法有效支撑全程全网运营，横向整合与管理要求仍有差距。 OSS系统关键技术重复建设，不利于企业核心IT架构的积累和复用 OSS数据的一致性和完整性问题突出，缺乏数据共享的有效机制和技术架构。 集成架构多样化，无法适应业务的快速变化； OSS系统与内外部系统的接口不规范，缺乏统一标准，协调工作量大，厂商替换成本高。 OSS系统众多，用户操作多个终端，需要提高IT系统的使用便捷性。 技术体系一体化：实现总部、省二级IT系统的垂直连通，提供跨域、跨省的客户受理、开通、保障和服务能力。 技术体系的共享化：建设公共平台，促进关键技术的共享和收敛。 信息数据共享化：提升数据的横向整合与纵向贯通，提高信息的及时性、准确性。 引入SOA和构件化设计思想，逐步稳定核心IT架构，快速主动适应业务变化； 建立企业应用集成平台，制定企业统一接口标准，推进跨系统的业务流程监控。 建立OSS门户建设，推进应用界面整合和用户操作的便捷性。 系统分类和融合策略 识别最小颗粒度系统 系统识别的原则按照优先级从高到低为： 数据集中原则：数据集中，避免在两个系统维护同一数据实体。 定位明确和功能聚集原则：系统需要支撑相对完整的一组业务能力和业务流程，将类似或紧密相关的功能划入同一系统，尽可能不依赖于其他子系统完成其主要功能。 平滑过渡原则：尽可能不要对目前已经较为成熟和完备的系统进行结构性的改动，以利于实施和演进至目标系统。 SOA为指引：创建能够即时适应未来业务需求变化的 IT 环境，打破传统应用边界，实现IT的集中化、集成化、标准化及资源的最大共享。 融合原则按照优先级从高到低为： 业务驱动：业务的关联和业务运转的高效性是系统融合的首要驱动因素。 技术驱动： 关键技术收敛：使用相同技术的系统可以融合； 数据聚类：操作或者使用相同数据的系统可以融合； 计算能力：系统融合需要平衡系统的计算能力； 安全稳定：系统融合需要平衡系统的安全性和稳定性； 技术成熟度：系统融合需要平衡关键技术的成熟度和市场产品的限制； 使用者驱动：尽可能减少同一人操作过多终端/界面的工作负担，提升运营工作效率。 系统分类 系统融合策略 系统是项目实施的最小建设单位 以规范定义的系统粒度和边界指导系统建设，不同系统之间要松散耦合、边界清晰。 以规范定义的系统指导专业之间的整合、全业务支撑的整合。 以规范定义的系统指导省集中。 同一类型系统内的要实现技术共享 逐渐实现同一类型系统内部的技术共享，共享技术平台、共享公共组件，并逐渐实现关键技术的收敛。 同类系统内部的技术共享并不意味着系统的紧耦合，逐步以SOA方式实现系统的融合。 同类系统群的融合可以根据各省实际情况确定融合方式和时间。 不同类型系统之间的不建议系统整合和合并 不建议跨类型系统的系统整合。 系统分类 系统分类建设的意义 对OSS系统未来的演进和融合提供了指引 降低OSS系统数量，突出OSS的核心能力 结合业务驱动和技术驱动进行分类，适应全业务运营和系统技术架构融合的需要 提供综合业务支撑能力 针对不同业务、不同客户提供个性化支撑 保障类系统 将服务保障系统、施工调度系统、网络运维管理系统融合为保障类系统 资源管理系统 规划管理系统将在网络资源管理系统的基础上扩展建设 自动激活系统 配置管理的功能未来将在自动激活系统的基础上扩展实现 综合网管系统 将综合告警系统、综合性能系统融合为综合网管系统 系统架构对全业务运营的应对 系统架构的目标：系统健壮、业务灵敏 架构设计参考：SOA、J2EE、MVC IT系统架构建议 符合业内主流技术和发展趋势 分为数据层、业务逻辑层、控制层、展现层 集成接口层 OSS公共平台 门户平台 企业GIS平台 应用集成平台 运营服务分析系统（ODS-O） 公共平台整合对OSS的IT能力提升 提高了IT基础平台的复用程度 保护投资 通过各种应用锤炼基础平台 在全局上实现OSS的整体IT架构优化 数据管理能力是提升OSS能力的核心 ODS-O ODS-B 接口数据 企业数据仓库(EDW) 数据抽取 分析结果 服务保障 施工调度 …… 服务开通 综合网管 测试管理 …… 自动激活 数据抽取 数据共享 ODS(广义) 彩铃平台 HLR …… 号百平台 集团 ODS 数据上报 数据获取 集团ED