基于TMFNGOSS架构建立积木式产品体系
秋的作文-藏戏课文
引言：
TMF NGOSS
架构综合
了电信运营商业务运营的最佳实践，提供了全面的电信运营商
业务运营支撑系统的框架标
准，主要包括业务流程框架（
eTOM
）
、信息框架（
SID
）
、应用框
架（
TAM
）和集成框架（
TNA
）
。
TMF
相关规范的发展已经相当成熟，可以作为我们构建全
新产品体系的设计指
南和架构蓝图，也为我们将系统应用“积木化”提供了基础。
作为电信行业业务运营管理标准的制定者和倡导者，
TMF
为支撑电信运营商业务运营的
OSS/BSS
系统的标准化开发提供了全面的框架标准，并形成了众多的最佳实践和应用指南，
覆盖了从制定业务流程优化战略到创建面向业务的技术规范乃至接口模型细节的广阔范围。
TMF
通过广泛地收集和采纳众多会员的先进思想和研究、实验成果，提供了针对
OSS/BSS
软件开发坏境的核心解决方案框架（
Solution
Frameworks
）
，也就是用于促进业务流程自动
化发展的
N
GOSS
（
New Generation
Operations Systems and
Software
）架构。
NGOSS
架构
TMF
NGOSS
架构包
含的解决方案框架提供了一系列业界标准框架和最佳实践，可以用来
增强和改善信息、电
信等行业的业务流程和运营。
NGOSS
解
决
方
案
架
构
主
要
< br>包
含
四
个
关
键
组
件
，
即
业
务
流
程
框
架
（
Business
ProcessFramework-eTOM
）
、信息框架（
Information
Framework-SID
）
、应用
框架（
Application
Framework-
TAM
）和集成框架（
Integration
Framework-TNA
）
，它们共同构成综合业务体系架
构
（
Integrated
Business Architecture
）
。
每一个框架不仅可以独立应用于解决特定的业务问题，
也可以与其它框架整
合起来形成端到端的体系，以便为企业实施全面的解决方案。
为了推动
NGOSS
解决方案框架的采纳和发展，
TMF
还提供了各种实施支持活动和工具，
同时也提供了促进市场推广的广泛信息和市场支持手
段。
业务流程框架（
eTOM
）
业务流
程框架提供了描述电信行业业务流程的通用语言，
并且建立了这些业务流程与支撑
软件系统之间的映射关系；
此外，
还提供一系
列关键业务处理的流程示例。
业务流程框架可
以帮助运营商梳理
现有业务流程，
可以作为一个指导框架帮助定义支撑软件系统解决方案的
范围，同时还可以帮助运营商与其支撑软件提供商、集成商和供货商进行更好的沟通。
< br>
信息框架（
SID
）
信息框架为支撑软件提供商和集成商
提供了描述管理信息的通用语言，
使得跨厂商、
跨系
统的各种软件应用的集成更加方便和有效。
信息框架提供了创建共享信息模
型所需的概念和
原则，帮助定义模型的实体及其元素，建立面向业务的
< br>UML
类模型，以及面向设计的
UML
类模型和序列图，从而建立信息和数据的系统视图。
应用框架（
TAM
）
应用框架以实现系统管理能力的各种应用的功能性及其
作用为着眼点，
为这些应用提供明
确的定义。
< br>运营商的采购部门可以借助应用框架确定采购范围并对相关厂商的解决方案进行
比
较。
集成框架（
TNA
）
集成框架以及业务服务（
Business Services
，也称为“
Contracts
”
）是
NGOSS
解决方案框架
中的关键部分。为了成功地集成不同厂商提供的各种应用，相应的配套设施必须是通用的。
集成框架定义了指导软件开发商创建各种应用组件的体系架构原则，
以便
其能够在分布式环
境中成功地运行；
而业务服务则定义了各种应
用组件在整个体系架构中能够相互连接的
API
。
由于没有规定如何实施这样的体系架构，而只是规定了符合
NGOSS
解决方案框架所必须遵
从的原则，集成框架是与技术无关的，这也是
其缩写为
TNA
的原因（
Technology Neutral
Architecture
–
TNA
）
。此外，集成架构还包含了
TMF
接口规范库，既方便了应用的集成，
又可以作为业务服务
API
累积的基础。以集成架构为基础，
TMF
启动了体系架构一致性
(Architecture Harm
onizationProgram
）
工作，
< br>其目的就在于建立统一的接口和信息模型。
体系
架构一致
性的主要驱动力源自面向服务体系架构（
SOA
）的理念和为提
升电信运营企业灵活
性及敏捷性而创建技术无关支撑平台的目标。体系架构一致性将确定
并协调
NGOSS
各关键
框架之间的相互依赖性。
框架关联
NGOSS
解决方案框架的四大框架结合起来为支撑系统的开发、集成和运行打下了良好的
基础。
这些框架及其内部元素既可以综合应用于承担大规模的端到端开发和集
成项目，
也可
以针对性地独立选取适当的部分用于解决特定的问
题。
这种方式使得支撑系统供应链中的所
有参与者都可以自信地
选取适合其具体业务的框架及其元素，
完成各自的相关工作，
而
无需
担忧不同系统之间的相互配合问题，
其结果就是大大降低了
系统之间的集成成本。
四大框架
之间存在着千丝万缕的联系，例
如：
1
、业务流程框架（
eTOM
）与信息框架（
SID
< br>）是天然相关联的，业务流程框架中定义的流
程单元（
P
rocess
Element
）就相当于信息模型中定义的实体。
2
、集成框架（
TNA
）通过对业务服务（
Business
Service/Co
ntract
）
、接口规范及其实施的描
述，说明了实体的交互特征，更详细地规定了流程处理与实体之间的交互关系。
3
、集成框架（
TNA
）中还保存着业务服务（
Business
Service/Contract
）库。
< br>4
、应用架构（
TAM
）由可采
购应用的定义组成，描述了各个应用领域所支持的流程单元和
实体。
NGOSS
应用
NGOSS
解决方案框架可以作为一个综合系统用于
实施端到端的支撑项目，其独立的组件
（单一的框架或其内部元素也可以用于解决特定的
问题。
NGOSS
解决方案框架可以在整个
< br>相关的组织机构中使用，
运营商、
软件开发商和系统集成
商都可以利用该框架来指导自己的
相关事务。
下面是几个典型应用示例：
业务流程重组（
Business
Process
Reengineering/Redesi
gn
—
BPR
）
：运营商可以利用业务流
程框架（
eTOM
< br>）分析其现有业务流程，确认其当前战略中的冗余和缺失，并重新设计和构
建业务
流程，
以便改善业务流程的不足，
增强业务流程的自动化处理能
力。
咨询机构也可以
基于业务流程框架帮助运营商完成类似的工
作。支撑系统迁移战略的制定：
NGOSS
解决方
案框架提供了将遗留支撑系统迁移到面向未来的、
可维护的、
灵活的新系统的指导方针。
运
营商及其软件开发商可
以在
NGOSS
解决方案实施方法论的指导下，定义面向未来
的通用支
撑系统基础设施架构。设计和规范管理解决方案：
NG
OSS
解决方案框架详细定义了应用、
信息模型、
接口和体系架构规范，
运商及其软件开发商可以用于规定和获取面向未来的
支撑
系统解决方案。软件应用开发：
NGOSS
解决方案的四大框架及其实施方法论可以帮助软件
开发商建立组件化开发过程
，创建低成本的支撑系统解决方案。
系统集成：在面临集成难题之时，
NGOSS
解决方案框架中明确定义的通用语言、接口和体
系架构为系统集成商整合跨厂商
异构系统指出了明确的方向，
使其能够实现可重用的、
具备
成本效益的集成解决方案。
平台创建
< br>平台是一组反映运营企业及其特定业务模式的相关业务服务、
人员和角色的组合。
平台的
体系架构将展示一个运营企业的服务提供方式，并明确企
业运营价值链带给企业的局限性。
根据支撑系统的具体需求，
可
以将各种相关的业务服务
（
Business Service
s
）
组合成为相应的
支撑系统平台。下
图是一个支撑系统平台组合的示例。
积木式产品体系探讨