NGOSS速成心法之第一式

    起这个名字是有渊源的。首先NGOSS是我们学习的内容，是后面经常会说到的，暂且放下不表。速成乃我等心愿，希望能趁周边罕有高人之时，早成正果，哪怕只是低手，也能尽一时之快了。至于心法一说，实在是不得已，当前视野之内精通NGOSS之人实在是少之又少，无人传授实体功法，只能几人一齐拿着文档纯以唯心方式对其揣摩，仿若当年寇仲和徐子陵初拿《长生诀》胡猜乱试，只能以心法形容之。不扯×了，进入正题……

    我们的第一个问题：
    什么是NGOSS？
    根据书上的意思，我是这样猜的。NGOSS首先是一个体系结构，他是针对电信运营行业特点，提出的一套规划体系、分析业务、设计系统、实现设计、改进完善系统和软件的框架。以它为依据，可以指导产生能适应当前及未来数年市场需求和业务变化的，灵活机动的，自动化业务处理流程系统。NGOSS的重点在于做事前决策，通过前期的规划和分析建立解决方案模型，而不是在有了产品后再去强行加入诸多的修改去适应实际的业务行为。这里有个有趣的插曲，开始没有资料时，祭起GOOGLE大法一阵乱搜。发现NGOSS有2种缩写全称，一为“Next Generation Operations Support Systems”，一为“New Generation Operasions Systems and Software”。着实让我纳闷了一会，后来看了一篇文档才清楚，前者为2002年NGOSS的定义。我猜大概是TMF后来为了在NGOSS引入实现上的参考或引导，让NGOSS更为实质化一些，扩展了NGOSS范围，引入了TNA软件架构等内容，所以更改了全称。其实扩展开来想，老外的IT行业的很多理念在一个时期或演变方式都是比较类似的，都善于用概念来逐步引导商业行为。比如，NGOSS的模型总让我想起同时期的SOA。索性乱弹一下，从企业IT化的开始想起，大家一开始有业务IT化需求时，软件厂商跳出来为企业开发了一系列孤岛系统，后来IT巨头拓展了网络功能，大家的同一系统可以互访了，逐渐有了C/S、B/S等基于网络软件系统。而后，大家又希望不同系统之间也能互访，于是又出现了EAI。这时好像IT市场增长点越来越少了，这时IT巨头们又适时提出SOA，让他成为解决目前IT困难的银弹，鼓励大家把原有的应用系统规划成原子服务，上层再用低耦合的方式编排成业务流程。感觉系统结构是越来越科学，越来越能满足企业的需要，而这一切其实各企业又都按着IT巨头这些先知们的指引消费了大量的设备和服务，让IT巨头们能站得更高，所以IT巨头们又会找到了一种完全取代目前这种一层层搭起来的架构的技术。于是IT界又是一次大变革，人们的信息化生活和工作又是一次大飞跃，然后在这种技术上，大家再一次按那种规律一层层演化进步……KAO，扯太远了。

    第二个问题：
    NGOSS由哪几部分组成？
    按照书上说的，大致由五部分组成：
    1、NGOSS生命周期和方法论，这玩意比较玄，不过生命周期中的四个视图倒能说明这五大组成部分之间的关系，这是我们的第三个问题，后面再说；
    2、增强电信运营图eTOM，这个是一个纯粹业务上的框架，是通过对行业业务处理的分析，形成的一个分层分类的结构图；
    3、共享信息和数据模型SID，这个我理解是一个大的数据模型，是分析系统会涉及到的业务信息，抽象出各管理域之间能够共享，达到互信可识别使用目的的数据描述；
    4、技术中立构架TNA，我理解是以用无技术特性的契约来描述各业务单元，包括描述单元的活动信息、行为特征等，我觉得XML Schema应该是能够支持这一功能的技术；
     5、NGOSS一致性测试，也有叫系统遵从性检测的，英文文档上的原文没看明白。意思差不多是用于验证解决方案或实现后的产品是否符合NGOSS体系架构，比如，业务分析阶段，我们定义出的业务模型是否符合eTOM，系统设计阶段，我们以一些测试方法来验证设计是否遵从了技术中立架构，这是我猜得。

    第三个问题：
    NGOSS各组成部分之间的关系怎样？
    NGOSS各部分之间的关系我是这样理解的：NGOSS生命周期是整个结构构建实施过程，覆盖全部过程的是方法论，同时遵从性检测应该也是渗透在全部过程中的，用于控制整个过程是符合NGOSS的。生命周期依次表现为业务、系统、实现、部署四个视图。其它三个组成部分分别会在这四个视图中发挥作用。
    业务视图中，用eTOM框架和SID模型定义业务过程和相应的业务实体。这个阶段会用业务人员熟悉的语言描述这些定义，传递到下一下视图。
    系统视图中，参考eTOM框架，使用业务视图的输出，使用SID和TNA建立系统模型，包括对象、行为和计算交互等定义。这这环节会使用技术无关的方式准确描述对象和行为的契约，作为本视图的输出。
    实现视图中，使用上两个视图的输出，完成系统视图中的中立架构到具体实现方案的映射，从技术无关到技术相关。输出包括，系统合约的实现、类实例图、数据模型、执行环境等，对系统合约中的交互行为描述体现为代码或接口定义、API、WS等。
    部署视图最不好理解，理论上应该是在这里描述系统实际运营生产中的如何进行监测，保证系统是按照预想的方式工作，并根据系统运行情况进行相应的调整。

    暂时只能理解这些，也不知道对不对，可能经过后续的学习后，回头看现在的理解会觉得十分肤浅，或者干脆错得天翻地覆，呵呵，不管了。
    另外要说的是，讨论是促进学习过程的一个好办法，往往一个人学习时，以为已经理解的部分，在学友的质疑下变得吹弹可破，这样可以激发对知识的深入挖掘，一不小心说不定就会打通任督二脉，让知识融会贯通，成为一代宗师，用双龙的话说就是“进窥天道”。不过万一任督二脉没打通，反而被集体BS一通，那也真够郁闷的，呵呵～