基于TMFNGOSS架构建立积木式产品体系

整理文档很辛苦,赏杯茶钱您下走!

免费阅读已结束,点击下载阅读编辑剩下 ...

阅读已结束,您可以下载文档离线阅读编辑

资源描述

引言:TMFNGOSS架构综合了电信运营商业务运营的最佳实践,提供了全面的电信运营商业务运营支撑系统的框架标准,主要包括业务流程框架(eTOM)、信息框架(SID)、应用框架(TAM)和集成框架(TNA)。TMF相关规范的发展已经相当成熟,可以作为我们构建全新产品体系的设计指南和架构蓝图,也为我们将系统应用“积木化”提供了基础。作为电信行业业务运营管理标准的制定者和倡导者,TMF为支撑电信运营商业务运营的OSS/BSS系统的标准化开发提供了全面的框架标准,并形成了众多的最佳实践和应用指南,覆盖了从制定业务流程优化战略到创建面向业务的技术规范乃至接口模型细节的广阔范围。TMF通过广泛地收集和采纳众多会员的先进思想和研究、实验成果,提供了针对OSS/BSS软件开发坏境的核心解决方案框架(SolutionFrameworks),也就是用于促进业务流程自动化发展的NGOSS(NewGenerationOperationsSystemsandSoftware)架构。NGOSS架构TMFNGOSS架构包含的解决方案框架提供了一系列业界标准框架和最佳实践,可以用来增强和改善信息、电信等行业的业务流程和运营。NGOSS解决方案架构主要包含四个关键组件,即业务流程框架(BusinessProcessFramework-eTOM)、信息框架(InformationFramework-SID)、应用框架(ApplicationFramework-TAM)和集成框架(IntegrationFramework-TNA),它们共同构成综合业务体系架构(IntegratedBusinessArchitecture)。每一个框架不仅可以独立应用于解决特定的业务问题,也可以与其它框架整合起来形成端到端的体系,以便为企业实施全面的解决方案。为了推动NGOSS解决方案框架的采纳和发展,TMF还提供了各种实施支持活动和工具,同时也提供了促进市场推广的广泛信息和市场支持手段。业务流程框架(eTOM)业务流程框架提供了描述电信行业业务流程的通用语言,并且建立了这些业务流程与支撑软件系统之间的映射关系;此外,还提供一系列关键业务处理的流程示例。业务流程框架可以帮助运营商梳理现有业务流程,可以作为一个指导框架帮助定义支撑软件系统解决方案的范围,同时还可以帮助运营商与其支撑软件提供商、集成商和供货商进行更好的沟通。信息框架(SID)信息框架为支撑软件提供商和集成商提供了描述管理信息的通用语言,使得跨厂商、跨系统的各种软件应用的集成更加方便和有效。信息框架提供了创建共享信息模型所需的概念和原则,帮助定义模型的实体及其元素,建立面向业务的UML类模型,以及面向设计的UML类模型和序列图,从而建立信息和数据的系统视图。应用框架(TAM)应用框架以实现系统管理能力的各种应用的功能性及其作用为着眼点,为这些应用提供明确的定义。运营商的采购部门可以借助应用框架确定采购范围并对相关厂商的解决方案进行比较。集成框架(TNA)集成框架以及业务服务(BusinessServices,也称为“Contracts”)是NGOSS解决方案框架中的关键部分。为了成功地集成不同厂商提供的各种应用,相应的配套设施必须是通用的。集成框架定义了指导软件开发商创建各种应用组件的体系架构原则,以便其能够在分布式环境中成功地运行;而业务服务则定义了各种应用组件在整个体系架构中能够相互连接的API。由于没有规定如何实施这样的体系架构,而只是规定了符合NGOSS解决方案框架所必须遵从的原则,集成框架是与技术无关的,这也是其缩写为TNA的原因(TechnologyNeutralArchitecture–TNA)。此外,集成架构还包含了TMF接口规范库,既方便了应用的集成,又可以作为业务服务API累积的基础。以集成架构为基础,TMF启动了体系架构一致性(ArchitectureHarmonizationProgram)工作,其目的就在于建立统一的接口和信息模型。体系架构一致性的主要驱动力源自面向服务体系架构(SOA)的理念和为提升电信运营企业灵活性及敏捷性而创建技术无关支撑平台的目标。体系架构一致性将确定并协调NGOSS各关键框架之间的相互依赖性。框架关联NGOSS解决方案框架的四大框架结合起来为支撑系统的开发、集成和运行打下了良好的基础。这些框架及其内部元素既可以综合应用于承担大规模的端到端开发和集成项目,也可以针对性地独立选取适当的部分用于解决特定的问题。这种方式使得支撑系统供应链中的所有参与者都可以自信地选取适合其具体业务的框架及其元素,完成各自的相关工作,而无需担忧不同系统之间的相互配合问题,其结果就是大大降低了系统之间的集成成本。四大框架之间存在着千丝万缕的联系,例如:1、业务流程框架(eTOM)与信息框架(SID)是天然相关联的,业务流程框架中定义的流程单元(ProcessElement)就相当于信息模型中定义的实体。2、集成框架(TNA)通过对业务服务(BusinessService/Contract)、接口规范及其实施的描述,说明了实体的交互特征,更详细地规定了流程处理与实体之间的交互关系。3、集成框架(TNA)中还保存着业务服务(BusinessService/Contract)库。4、应用架构(TAM)由可采购应用的定义组成,描述了各个应用领域所支持的流程单元和实体。NGOSS应用NGOSS解决方案框架可以作为一个综合系统用于实施端到端的支撑项目,其独立的组件(单一的框架或其内部元素也可以用于解决特定的问题。NGOSS解决方案框架可以在整个相关的组织机构中使用,运营商、软件开发商和系统集成商都可以利用该框架来指导自己的相关事务。下面是几个典型应用示例:业务流程重组(BusinessProcessReengineering/Redesign—BPR):运营商可以利用业务流程框架(eTOM)分析其现有业务流程,确认其当前战略中的冗余和缺失,并重新设计和构建业务流程,以便改善业务流程的不足,增强业务流程的自动化处理能力。咨询机构也可以基于业务流程框架帮助运营商完成类似的工作。支撑系统迁移战略的制定:NGOSS解决方案框架提供了将遗留支撑系统迁移到面向未来的、可维护的、灵活的新系统的指导方针。运营商及其软件开发商可以在NGOSS解决方案实施方法论的指导下,定义面向未来的通用支撑系统基础设施架构。设计和规范管理解决方案:NGOSS解决方案框架详细定义了应用、信息模型、接口和体系架构规范,运商及其软件开发商可以用于规定和获取面向未来的支撑系统解决方案。软件应用开发:NGOSS解决方案的四大框架及其实施方法论可以帮助软件开发商建立组件化开发过程,创建低成本的支撑系统解决方案。系统集成:在面临集成难题之时,NGOSS解决方案框架中明确定义的通用语言、接口和体系架构为系统集成商整合跨厂商异构系统指出了明确的方向,使其能够实现可重用的、具备成本效益的集成解决方案。平台创建平台是一组反映运营企业及其特定业务模式的相关业务服务、人员和角色的组合。平台的体系架构将展示一个运营企业的服务提供方式,并明确企业运营价值链带给企业的局限性。根据支撑系统的具体需求,可以将各种相关的业务服务(BusinessServices)组合成为相应的支撑系统平台。下图是一个支撑系统平台组合的示例。积木式产品体系探讨维基百科中对积木的说明:“积木是一种训练孩子手眼协调能力的玩具,也可以增进孩子创造力的发展,其玩法没有一致性,它的形状有很多种,可以让孩子利用不同形状的积木而拼出所要的造型,引导孩子发挥想象力。积木起源于建筑的模型,以最基本的立方体图型,创造出特别的模型。”对于业务运营支撑系统来说,也可以引入积木的概念。从业务运营支撑系统来看,由于需求发展和运营职责等方面的原因,形成了总体功能边界相对比较清晰的、通常是独立发展的多个解决方案,例如Billing、CRM、BI等。一般而言,这些解决方案都是依据运营商的业务和系统规范设计和开发的,即使是同一家厂商提供的系列解决方案,其体系架构、信息模型等都可能完全不同,而在业务运营环境中,它们之间又需要具有很好的交互连接性,这一方面给开发、实施、整合和维护造成了巨大的障碍,另一方面也大大增加了系统部署和维护的成本。要解决这个问题,建议基于TMFNGOSS架构建立积木式产品体系。一致性设计以TMFNGOSS解决方案框架为蓝图,采用其关键框架为指导,对支撑系统各产品线进行整合,对产品体系进行一致性设计。以业务流程框架(eTOM)为指导,进行流程单元的一致性梳理和设计。目前,最新发布的eTOMv8.0已经将流程单元细化到Level3级别,对我们梳理和设计满足国内、国际运营商支撑系统需求的系统功能框架具有极好的指导意义。我们可以在此基础之上,进一步细化Level4、Level5乃至更细粒度(如有必要)的流程单元。可以将各级别的流程单元实现为不同层次的应用积木模块,以便根据国内、国际运营商的具体需求,按照应用框架(TAM)对这些模块进行组合,形成适当的解决方案。为了保证各层次的应用积木模块能够平滑地组装,统一的信息模型和集成架构及接口至关重要,可以基于信息框架(SID)和集成框架(TNA)对信息模型和集成架构及接口进行一致性设计和实现。由于历史和国内运营商需求的原因,公司当前的产品线已经按照功能域进行了相对比较明确的划分,并且按照研发职责将研发工作分配到不同的研发中心。这些研发中心及其负责的产品线之间没有一致的研发计划,更没有一致的架构设计,存在着比较大的系统集成障碍,同时也存在着一定程度的重复工作。基于TMFNGOSS架构建立积木式产品体系之后,可以按照流程单元划分进一步清晰产品线边界,仍然可以按照Billing、CRM、BI等解决方案模式来进行产品线划分,一方面各负其责,减少重复工作,消除集成障碍;另一方面加强各研发中心之间的交流与沟通,实现充分的资源共享。两种方法基于TMFNGOSS解决方案框架对产品体系进行梳理和设计,可以通过两种方法来实现,即自底而上方法和自顶而下方法。产品体系的梳理和设计主要针对支撑系统中的流程单元,也就是要以业务流程框架(eTOM)为基础进行梳理和设计。自底而上方法就是从现有产品和解决方案中的业务流程单元出发,将现有的业务流程映射到eTOM框架中,构建自己的基于eTOM框架的业务流程单元分解体系和流程单元定义。自顶而下方法就是基于现有的eTOM框架对业务流程单元进行更细节的分解,对业务流程进行定义,连接相应的流程单元,将分解后的流程单元及相关流程组合起来,构成业务流程域,并对其行为进行全面的描述。三个层面以建立基于TMFNGOSS架构的积木式产品体系为目标,分阶段解决以下三个层面的问题:1、对现有产品进行梳理,建立产品流程单元(ProcessElements)与NGOSS架构,特别是eTOM框架的映射关系,形成产品体系售前方案的理论基础;针对不同运营商的需求,组合成相应的产品实施方案,提高研发成果、解决方案和PSO工作的可重用性;2、在产品梳理的成果之上,建立流程单元与运营商组织单元的映射关系,形成ITC咨询业务的方法论基础,提高ITC咨询业务的竞争力;3、在NGOSS架构下对产品线进行统一规划,通过一致的系统架构、一致的数据模型、一致的接口模型,建立产品体系的一致性,明确各产品线之间的职责分工,提高产品化程度,达到交钥匙工程的基本要求(对海外市场尤为重要)。在完成上述三项基本工作的同时,逐步建立完善的产品文档体系,为国内、国际市场推广提供丰富产品资料库,以便针对不同的需求进行组合和剪裁,形成具有竞争力的解决方案。

1 / 9
下载文档,编辑使用

©2015-2020 m.777doc.com 三七文档.

备案号:鲁ICP备2024069028号-1 客服联系 QQ:2149211541

×
保存成功