Ocean's Blog [Work]

http://hi.baidu.com/Ocean77

本文旨在通过对全球电信OSS市场的分析，为中国的运营商在定位和设计自己的OSS战略的时候提供一个可以参考的框架。近年来，是否引进国外厂商的计费和OSS软件以达到洋为中用的目的在国内计费和OSS行业引起了诸多争论，但是笔者也意识到这些争论似乎始终也没有给国内的电信计费行业带来太多实质性的变化，国内的厂商们依然坚持认为国外厂商不懂中国国情，而国外的厂商们也因为中国情况的“特殊性”而异常小心谨慎。其实，也许双方或者说多方目前关注的点都偏离了问题的本质，计费和OSS归根结底并不是一个中国的问题，而是电信行业的根本问题 – 笔者希望通过以下的介绍能够更好地说明这一点。

作者：熊绳祖

以前，我们在进行企业信息化规范时，首先想到的是进行企业业务建模，以模型作为基础来进行IT的规划和指导信息化建设。但建模谈何容易，要么模型很粗，放之四海而皆准，对实际建设起不到指导作用；要么就是“只见树木，不见森林”，难以起到良好的规划作用。因此建模一直是一个大家想做，但非常难做的事情。 近年来，在TMF的组织和世界各知名企业（包括电信运营商，软件供应商，咨询服务商，系统集成商和硬件供应商）的共同参与下，NGOSS吸收各国运营商的实际建设经验，越来越完善，也被世界各电信运营商、软件开发商和咨询服务商所接纳，成了业界共同的语言和标准。NGOSS的商业模型eTOM描述了一个全电信运营商在目前商业环境下的商业流程模型，解决了“是什么”的问题，而NGOSS除了eTOM模型外，还包括了分层次的功能模型、集成接口模型和数据模型以及相关技术架构，解决了“如何做”的问题。为我们了提供了一套可行的思维框架，分析问题和表述问题的统一方法论。对于这一凝聚众多业界专家和顶尖公司的智力成果，能为电信运营商带来什么，运营商又该如何做来利用这些智力成果呢？本文对这些问题作一个粗浅的讨论。 首先，NGOSS能为运营商做什么呢？ 一、统一思想，确定努力方向 一直以来，电信业务处在高速的发展之中，业务种类和业务量突飞猛进，我们的系统都是围绕着业务来转，这本没有错，只是没有统一规划和建模，另外还掺杂一些部门利益在里面，导致上线的系统成了本部门的“自留地”，其它部门在思想上反对，在行动上设置障碍，使它难以与其它系统集成，形成信息“孤岛”。公说公有理，婆说婆有理，谁也说服不了谁，系统的效益大打折扣。 有了NGOSS以后，企业所有的部门以NGOSS为共识统一思想，达成一致意见，容易形成合力，共同建设好具体的IT系统。 二、作为企业流程重组的重要依据 电信业务的发展突飞猛进，新的业务层出不穷，先是固定通信，后是移动通信，再后来是数据通信，为了适应业务的发展，新的部门和流程不断产生，这些部门和流程对于某一业务来说，可能是适合的，但不适合企业从全局的角度出发，对企业拥有的资源进行优化组合，以综合品牌和组合产品来面对市场竞争和提供客户服务。eTOM模型对各种业务进行抽象，提取所有电信业务的一般属性，总结出通用的业务流程和功能模型，打破了各个业务之间的壁垒，为企业业务流程的重组提供了重要的依据，有利于消除部门之间的壁垒，打通端到端的流程，为客户提供优质的服务。 三、作为企业业务建模和技术建模的重要基础 NGOSS作为TMF的重要输出成果，产生了eTOM商业流程模型，SIM功能和集成模型，SID数据模型以及相关的技术无关架构（TNA）和技术有关架构（TSA）。实际就相当于一大群全世界的业界精英在为运营商作企业建模和技术建模。运营商以此成果为基础，可以站在很高的平台上，组织自已的一帮人员，深入研究NGOSS和自已的业务，制定出符合自身企业情况的企业业务模型和技术架构模型，以此来指导内部IT系统的建设，反过来，IT系统的建设经验和教训反馈给模型，对模型进行修正和优化。 四、作为合作伙伴选择的评判标准 在电信运营商的信息化建设的价值链上，有如下几个角色的参与：运营商本身，咨询服务商，系统集成商，软件供应商。有可能一个供应商可能集成几个角色，也有可能一个供应商只承担一个角色。各方只有深入理解NGOSS这门通用的语言，才能作深入的沟通，才能优质高效地完成运营商信息化建设这个艰巨任务。因此参与各方对NGOSS的遵从和理解是能够成为合作伙伴的重要要件。 五、作为项目建设的指导依据 企业信息化建设包括组织、流程和IT多个方面，物理上又包含多个系统，每一个系统对应于eTOM模型的某一部分，NGOSS的其它模型为IT项目建设提供了共享数据模型和接口标准，指导项目建设，保证了本项目的成功，也保证了项目与其它项目的接口规范性。 另外eTOM定义了企业的模型，确定了各块的功能边界，明确了需求，保证了项目的成功。 六、作为项目测试和验收的重要输入 TMF为了保证做出来的产品和工程服务符合NGOSS的标准，制定了测试标准和测试案例，以此标准来测试系统，保证系统具有NGOSS所规定的通用性，可扩充性和可集成性。 从上看出，利用NGOSS的成果，就象把全世界的业界专家请到自已的公司进行建模，但NGOSS是一个全电信运营商的流程模型、功能模型和数据模型，具有一定的普遍性，要使NGOSS“落地”，符合自身的情况，需要结合企业的实际业务情况和商业环境作裁剪，使这些先进的理论转化为核心竞争力。作为电信运营商应该如何做呢？ 一、成立NGOSS部门，研究NGOSS，建立适合自已企业的企业流程模型、业务模型和数据模型以及相关技术架构，并把这些成果贯彻到具体系统和项目的建设中去。部门组织结构参考如下： 企业模型研究与规划部的职责有如下几个方面：一、以NGOSS的相关模型为基础，结合企业的业务处理流程，制定不同业务的业务处理流程模型，打通端到端的客户服务流程。二、根据客户化的企业模型，结合市场形势和IT建设现状，进行投资组合分析，进行年度IT规划，确定项目建设清单。保证建设的项目的效益最大化。三、指导和参与项目建设，保证所建设的项目符合模型和规范的要求，同时根据实际建设的经验对模型进行不间断的优化和提升。NGOSS部门人员参与项目建设的方式有如下几种：一、直接参与项目的需求和设计；二、以顾问方式指导项目的需求和设计；三、作为技术评审人员对需求和设计进行模型遵从度评审；四、项目阶段结束后进行模型遵从度审计。在需求和设计过程中，都要有专门的章节来说明在建系统在eTOM模型中的位置，与其它系统的关系。所有的评审和审计都以此为基础。 二、运作上分为日常化运作和项目化运作。1、日常化运作以部门人员为主，主要是以NGOSS来指导业务模型优化，在某个里程碑阶段点，组织评审，通过后生效；2、项目化运作，即每年根据年度项目的执行情况和效果反馈，以及业务策略和发展目标，组成项目组，由相关业务部门共同组成跨部门的项目团队，集中对模型进行讨论和修改，严格评审，只有通过评审的优化才能生效。运作流程如下： 三、在利用NGOSS进行企业信息化建模和指导IT系统建设过程中，要注意如下几个方面的问题： （一）、在企业利用NGOSS进行企业建模和指导信息化建设中要注意以下两种倾向：1、对NGOSS敬若“圣经”，里面的句句都是对的，凡是现实与模型不符的，都要进行变革，这很容易犯理想主义和教条主义错误，导致“画虎不成反类犬”；2、把NGOSS的内容架空，认为NGOSS不适合中国的实际，对信息化建设起不到作用，因此把NGOSS作为一堆锁在柜子的文件来处理。 （二）、在把NGOSS模型与具体业务相结合时，不要对标准进行生搬硬套，要结合自已企业的特点进行合理的裁剪。不同的业务有不同的组件，如TOM模型中的保障部分，对话音业务来说，就不存在用户认证功能，因为用户的号码本身就是身份识别ID；对数据业务来说，用户必须经过Radius认证才能进入数据网络。 （三）、在处理模型和具体系统关系时，要注意平衡“理想”和“现实”之间的关系和逐步演进的策略。由于企业模型的修改涉及到众多系统和思路的改变，因此要慎之又慎，模型的修改要朝着完美的方向演进，但切忌怀着激烈的理想主义思想不顾现实情况，“大刀阔斧”地进行改革，这只可能使模型与现实成为互不相干的两张“皮”。好的演进策略就象“太极图”一样，相互融合，相互促进，构成螺旋式优化的模式。 总之，通过坚持不懈地对NGOSS相关模型的研究，结合运营商的具体业务和IT建设现状，较好地解决了端到端的业务流程问题，企业范围内的系统集成问题，共享的数据模型问题，并通过技术无关架构（TNA）和技术有关架构（TSA），对所建设的系统进行合理的规划和部署，保证了随着业务的发展，系统具有的可扩展性，性能以及最大的资产回报率。   （作者单位：华为技术有限公司）

作者：邓洁霖 

随着NGOSS系列规范的不断细化和完善，这些规范所包含的思想方法、设计原则已被业界普遍认可，这些规范的成果也被越来越多的服务提供商和OSS开发商所采纳，用于开发更适合当前市场需要的OSS系统。但由于不同的企业提供的业务种类不同、市场规模不同、服务的范围不同，在规范的具体应用过程中，如何对NGOSS给出的通用模型与相关领域知识相结合进行选择，以适合具体企业的具体解决方案，仍然缺乏一个统一的方法论。NGOSS生命周期方法论(以下简称NGOSS方法论)正是为这一目的而开发的。NGOSS方法论指导应用者利用NGOSS的成果，分步骤地定义、开发和部署适合于本企业的OSS系统。

NGOSS四大视角

经过一年的努力，TMF于今年1月发布了NGOSS方法论第一版。其目标是建立一套统一的生命周期视图和方法框架，帮助人们充分利用NGOSS的已有成果，包括eTOM，SID，NGOSS体系结构，充分获取领域知识，完整地分析业务问题、定义业务流程、设计和开发解决问题的系统方案，监控系统的执行。    该模型提供了从两类NGOSS应用者看系统的视角，一类是业务提供者的视角，一类是系统开发者的视角。两类应用者又分别从逻辑的和物理的两个层面看系统。逻辑层面关注解决方案中技术无关内容的定义，如业务流程、业务规则、信息模型等。物理层面关注解决方案中技术相关内容的定义和具体实施，如具体实现技术选择，COTS产品选择，运行方案等。

这样构成了四个视角，分别是业务视角、系统视角、实现视角和部署视角。

NGOSS业务视角：

在这一阶段，要明确系统的业务目标、范围和职责。利用eTOM和SID描述业务过程、业务实体、业务流程和业务规则，以适合管理环境和业务提供的需要。
NGOSS系统视角：

在这一阶段，主要关注系统对象、对象行为和交互操作。利用eTOM、SID和TNA来建立功能模型、构件模型、流程模型和信息模型，明确对象间的信息交互，协调一致地支持业务过程的要求。

NGOSS实现视角：

该视角主要关注如何利用硬件、软件和COTS，根据系统设计的要求具体实现一个特定的OSS系统。在这一阶段，要解决如何将技术中立规范中的设计转换为与技术相关的具体实现。

NGOSS部署视角：

部署视角是从系统维护者的角度监控系统的执行，保证系统符合业务的需要；如果系统不满足需要，能够通过NGOSS的调整和控制机制，使其符合业务需求的变化。这些控制机制如基于过程管理中的流程定义，基于策略管理中的规则设置。

NGOSS知识库：

NGOSS方法论提供了一种信息集中保存的机制，称为NGOSS知识库。NGOSS知识库中的信息来源于合作组和TMFNGOSS两个方面，包含三类知识：*现有的合作组织知识：包括软件业的已有成果，电信业的运营和业务知识*NGOSS知识：包括TMF定义的各种框架、模型、规则、技术方法等*共享知识：以上两类知识的通用部分。

NGOSS SANRR方法论

NGOSS方法论支持过程迭代，过程迭代即包括4个阶段的整体循回演进，也包括每个阶段自身的不断演进，这一方法被缩写为SANRR方法。

它包括五个实现步骤：

1)定义范围(Scope)：通过对当前环境的描述和实现目标的设定，明确定义系统演进需实现的业务和功能的范围、边界。

2)分析(Analyze)：分析新增业务或功能与原有业务或功能的关系，并用模型化语言对新增业务或功能加以定义和描述。

3)规格化(Normalize)：分析新增业务或功能对原有业务流程、功能模型、信息模型、业务规则等的影响，将新增部分加入到原有模型中，形成一个统一的新模型。

4)合理化(Rationalize)：通过检查和验证，进行差异分析、冲突分析和冗余分析，列出和标明出现的问题。

5)纠正(Rectify)：针对上个步骤列出的问题，对产生问题的模型进行修改，重复4)和5)直到全部完成。

知识的融合

NGOSS方法论总结了当前软件开发方法论中较有影响四个方法，它们分别是JohnA.Zachman创立的企业体系结构框架，ISO和ITU-T推荐的开放分布式编程参考模型RM-ODP，对象管理组织(OMG)倡导的模型驱动体系结构MDA和三位UML创始人提出的统一软件开发过程USDP。NGOSS在前人研究的基础上，抽取了各种方法论中适合NGOSS原则和体系结构的部分，从MDA中，借鉴了元模型、技术中立和技术相关思想，从RM-ODP中借鉴了从多视角看系统的方法，从USDP中借鉴了用例驱动和迭代演进的理念。

可见性

NGOSS方法论从两个方面强调了可见性。其一是提供了测试点标识，使系统在开发和运行过程中，都能被测试、监视和管理系统的当前状态。突出了系统的了管理性。其二是知识库的可共享，在NGOSS方法论中，系统从开始的业务目标描述、技术建模、技术实现到系统部署，其中的各种方法、模型、组件、固件和规则等等都可来源于知识库，以达到知识重用的目的。

可追溯性

通过提供方法和工具，对每一过程进行跟踪，验证其业务和功能是否能实现，达到前向可追溯的目的；通过提供监视机制，保证运行满足业务的需要，达到后向可追溯的目的。

用例驱动

在NGOSS方法论中，用例(UseCase)描述贯穿于NGOSS生命周期的四个视角，由于每个视角关注解决方案的不同方面，因此有四类NGOSS用例，每类用例由核心元素集和新元素集组成，反映了特定视角的相关需求。

应用原则

NGOSS方法论不是重新创建的一套全新的方法，而是当今软件领域各类知识有机融合的产物，反映了当前一些最新的软件工程思想，因此，有些方法还在不断发展中，并未成熟。同时，NGOSS方法论中提出的一些方法还需要相应的可操作性的模板和工具的支持。因此，在方法论的应用上，首先要遵循的原则是充分领悟方法论所包含的思想原则、工作方法。

因此，只有在深刻领会其思想原则的基础上，才能有效利用市场上一些成熟的工具，协助OSS系统的开发和建设。其次是不断积累相关知识，包括各种在OSS系统开发过程中产生的中间结果和元素，为需求的不断改变和扩充提供可重用的组件，缩短电信业务部署和提供的时间，真正做到适应市场的变化。

方法论提供的不仅仅是开发过程和辅助工具的集合，更是一种思想。将这些思想运用到具体的开发实践中，会极大地提高OSS系统的开发效率和质量。

      由于种种原因，例如缺少可循的标准、经验和知识的限制等，在信息化发展的初期阶段往往不可避免地出现一些问题。非标准和私有化技术的采用，使得很多信息系统没法持续发展，最后只能推倒重来；独立采购或自主开发的系统，由于缺少互连互通的标准，使得集成困难重重；各种各自为政，缺少规范和统一的信息模型，使得系统与系统之间缺少“共同语言”。信息化标准的问题，困扰着企业当前的信息化。

　　信息化需要标准化，这是无容置疑的了。信息化发展到今天，无论是从技术还是行业的角度，都有很多标准应运而生，似乎有规可循了。企业在信息化发展道路上也积累了很多经验和教训，为信息化向前发展奠定了基础。而且，也有很多业界同行的经验和教训可以借鉴。在这种前提下，在信息化中考虑标准化应该是具有一定的可行性的了。

　　当然，标准的形成有一定的过程，甚至，这样的过程永远是一个进行时。也就是说，标准化的过程是永远没有终点的一个过程。因此，信息化的标准化是在制定企业信息化架构时必须综合考虑、充分权衡的问题。在制定企业信息化架构时，我们不仅要考虑技术标准和行业标准，而且要结合企业的实际情况，形成自己的标准化体系，从而指导企业信息化的建设和发展。

　　技术标准　　

　　信息技术标准化的问题体现在: 没有相应的标准可循、太多的标准无从选择，以及标准本身也在不停地发展变化。信息化的重要目标之一就是通过信息手段提高企业的竞争能力，而其中的关键就是让自己的信息化技术领先对手一步。让自己领先对手的方法之一就是先进技术的使用。然而，往往当一个新技术开始形成的时候，标准化问题却落后一步，这样就出现了没有标准可循的局面。

　　在这种情况下，企业就面临着采用新技术的风险问题。新技术采用得合适，企业的技术优势使得企业的竞争能力大大提高。电子商务技术的使用就是一个典型的例子，正确的电子商务技术的采用，不仅仅使企业的生产效率大大提高，节省大量成本，增加企业的利润；而且，使得企业比竞争对手站在更高的台阶之上，提升企业的持续发展能力。相反，错失良机，被竞争对手远远甩在后面，使得企业由此一蹶不振的例子也比比皆是。因此，当相应标准还没有建立起来的时候，怎样选择具有前景的主流技术是非常重要的。

　　另一种情况则刚好相反，不是没有标准，而是标准不唯一或者标准太多。这种情况的出现，往往是因为标准的发展出现多个“马车头”。这可能是因为商业利益的原因，可以是历史的原因，甚至有可能是政治的原因。当这种问题出现时，企业可以选择站在某一个“阵营”，理想的情况是找到方法能够兼顾多个标准，从而使企业信息化立于不败之地。所以，这是一个怎样将多种标准融合在企业级架构中的问题。对这样的问题，没有一个黑白分明的简单答案。找到答案的出发点是对企业级架构的全面考虑，这也是为什么企业级信息化架构这么重要的原因。

　　标准自身的演进和发展也是在制定企业级架构时要认真考虑的问题。一个技术标准也有其自身的生命周期，在兴起的时候可能受到业界极力地推动，这种推动可能是当时业界对技术的认识所致，也不排除是由于某些利益集团为了自身的利益出发；当发展到一定的时期，相关的技术可能不再是主流的技术而被取代。CORBA就是一个典型的例子，十多年前，CORBA被吵的轰轰烈烈，被认为是信息技术的主流技术，今天却已成为了历史。一些企业由于没有全面的考虑，今天面临的就是怎样从其中跳出来的问题，这导致的不仅仅是信息化的成本问题，而更重要的是持续发展等更深层面的问题。

　　新的标准可以说是层出不穷，不断涌现。例如，Web服务和SOA等，今天也是新的“宠儿”。的确，技术的发展催生了这些新的技术和新的标准，是今天信息化的大方向，是信息化技术发展历史上的一个重要里程碑。然而，有人却得出了“SOA无所不能，企业没法解决的问题SOA都可以解决”，这未免让人觉得与“每亩产五万斤粮”是同一轨道上的“卫星”。如果企业信息化用这样的思路去采用新的技术标准，问题的产生只是迟早的事了。

　　因此，新标准、新技术的跟进，一定要结合企业的实际情况，在认真评估相关风险之后，在统一架构的基础上制定循序渐进、能进能退的发展策略。

　　行业标准　　

　　信息化不仅仅是技术问题，信息化是利用信息技术来帮助企业实现其业务和战略目标，因此，与技术标准相对应的另一面就是相关行业的标准问题。长期以来，无论是国外还是国内，对信息化中业务标准化问题的重视都不够，往往认为企业内部应用系统只要能解决自己的业务问题就足够了。随着信息化的发展，特别是电子商务的普及，才使得我们越来越关心业务标准化的问题。电子商务使得企业间的边界不再是业务的壁垒，使得企业间的互连互通成为一种“必需”，因而相关标准也不再是奢侈品而是必需品。
行业标准从内容上来说包含两个方面：数据和流程。数据标准规范了企业间数据交换的格式和数据交换的范围，例如，SWIFT是金融业的数据交换标准，HL7是医疗健康业数据交换的标准。除了数据标准之外，相关业务流程的标准使得企业间进行“业务对话”成为可能。例如，高科技制造业所使用的RosettaNet就是一种融合了数据、业务和技术的标准。

　　企业信息化在考虑行业标准的时候不仅仅是要考虑其所在行业的标准，也要考虑其相关行业的标准，从而可以充分融合这些标准为自己的业务服务。行业标准的考虑不仅仅是为了实现与外界的互连互通，它也是指导企业内部系统建立的标准。事实上，一些行业也逐渐形成了企业内部信息化系统建设的标准和参照模型。例如，电信领域的NGOSS/eTOM模型就逐渐成为了电信企业信息化的参考模型或标准。

　　企业信息化标准　　

　　技术标准和行业标准是企业信息化的基础，但关键的是企业应该将相关标准与自己的实际情况结合，建立自己的标准体系，使之成为自己信息化架构的一个组成部分。

　　行业的标准可以用来指导企业业务架构的形成或改造，传统企业在向现代企业迈进的过程中，不可避免地要进行适当的变动和调整。例如，根据业界标准对企业流程进行再造，使企业的业务和信息化能够更有效互动，就是一个可以用行业标准推动企业业务架构的典型例子。

　　企业级的标准信息化模型是信息化能否持续发展的很重要一步。如果没有标准化的信息模型，各个应用系统自行其是，使得系统之间完全没有共同语言，从而形成无法消除的信息孤岛。标准信息化模型与行业标准的融合,决定了企业信息化系统与外部系统的互联性。在标准信息化模型的指导之下，各个应用系统充分考虑信息的共性，再结合应用系统自身的重点和特性，形成一个既满足标准，又有自身特点的应用系统。

　　合理的集成架构可以使得信息化系统不受限于某一个单一的标准体系或某一个单一的技术体系。集成技术也可以用来解决因标准演进所带来的融合问题，从而避免或降低了因为标准的变化所带来的风险问题。标准的使用也可以用来提高系统的可管理性，从而降低信息化系统的拥有成本。因此，企业信息化标准就是在企业级架构的层面结合业界的技术和业务标准，形成适合于企业自己的标准，而不是简单的技术和业务标准的堆砌

　　架构一词是舶来品，是architecture的中文翻译, 其英文的本意是来源于建筑行业的建筑艺术、建筑（风格）和结构，引入到软件领域里面来以后，并没有一个统一的定义。有的人将架构定义为：功能+设计+构造手段，我们可以通俗的理解为：总体设计和总体结构。

　　买过房子的人都知道5层以下的楼房一般是砖混结构，而高层和小高层的楼房都是框架结构，楼层越高对结构要求越高。软件也是一样，系统越庞大，生命周期越长，结构的重要性就越明显。因此，随着人们对软件工程的深刻理解，将架构进行充分的强调是很自然的，正如人们越来越强调系统的需求分析，从而有了领域工程师和领域专家的概念一样。其实强调软件架构的最主要的目的有3个：

　　重用：人们希望系统能够重用以前的代码和设计，从而提高开发效率；

　　扩展：人们希望在系统能够保持结构的稳定的前提下很容易地扩充功能和性能，希望能够“以静制动“；

　　简洁：常言道，简洁就是美，好的架构一定易于理解，易于学习，易于维护，人们希望能够通过一个简洁的架构来把握系统；

　　正如我们可以很简单地用砖混结构和框架结构来概括一幢大楼的结构，专家们也定义了一些术语来定义软件的架构风格，如层次结构、B/S结构等。软件架构设计是软件设计的一部分，是其中的总体设计。软件的架构设计有一定的创造性，但它毕竟是一个工程活动，架构的设计是有章可循的，有一定的规律性的，是可以重复的，有其稳定的模式。当然，在系统一开始很难可以建立一个完善的稳定的架构。迭代是软件开发过程中必然的一个过程，这是人的思维活动的一个必然阶段。

　　软件架构师实际上就是软件的总体设计师。首席设计师就是总设计师，打个通俗的比方：邓小平是中国改革开放的总设计师，我们用现在的说法可以讲，邓小平是中国改革开放的首席架构师。架构师的形成一定是在实践中积累起来的，而并非上了几次培训班，读了几本书就可以成功的，架构师是在工程实践中培养出来的！
架构师也并非是万能的。架构师是客户需求和开发者之间的桥梁。在软件行业中，一般提到的架构师是技术架构师，而忽略了领域架构师或者讲是领域工程师的概念。一个好的领域专家一定是业务领域的架构师，他能够给出某一个业务领域的架构，我们可以称为业务架构，只有技术架构和业务架构紧密结合才有可能真正创造出一个好的系统！

　　C语言花费了二十年从蛮荒之中杀出一条血路，Java苦心耕耘了近十年方成大气，C#在Beta版本推出两年前就开始通过各种途径营造气氛，砸下了数不清的美金，直到现在还未被主流应用所完全接受。而MDA（Model Driven Architecture 模型驱动架构）自从2002年被OMG（Object Management Group 国际对象管理集团）提出以后，"随风潜入夜，润物细无声"，未见轰轰烈烈宣传，各大厂商却惊人一致地争相跟进，关于MDA的话题转眼之间在网络上也如火如荼地繁荣起来了。

　　然而MDA是什么？究竟是什么带来了MDA？究竟MDA为IT业带来了什么？MDA又揭开了一个怎样激动人心的大时代的序幕呢？

　　我来谈谈我为什么学习Hibernate，希望对大家能有点启发。
　　
　　在我做过的很多项目的过程中，我一直有一个悬而未决的问题在困扰我，那就是持久层的开发。持久层的开发一般来说要么用CMP，要么用JDBC＋DAO。 CMP就不用说了，它对我来说是一种失败的实践，而JDBC+DAO也存在很多的困难，我很难做到把关系表记录完整的映射到持久对象的关系上来，这主要体现在多表的关系无法直接映射到对持久对象的映射上来，可能是一个表映射多个持久对象，有可能是多个表映射一个持久对象，更有可能的是表的某些字段映射到一个持久对象，但是另外一些字段映射到别的持久对象上。而且即使这些问题都处理好了，也不能直接按照对象的方式来对持久对象（PO）编程，因为存在1：N关系的持久对象的查询其实就是1+n次对数据库的SQL，我曾经有一次失败的持久层设计，结果是某个关联很多其它持久对象的PO一查询就是5n＋1次 sql，速度慢的不得了，最后不得不整个修改底层设计，最后等于是完全抛弃了对象设计，完全是按照表字段进行操作。
　　
　　但是这样做非常难受，因为系统的设计是从需求设计，系统设计这样自顶而下的，结果都到了详细设计阶段了，被持久层映射问题限制，不得不自底向上修改设计方案，又回到了按照过程进行编程的老路上来，非常的糟糕。
　　
　　我对这个问题思考了很久，最后终于意识到这其实是一个很经典的问题：对象和关系的映射问题。实际上自从OOP编程流行以后，就存在这个难题了，所以才有人提出关系数据库进行重新设计，改用对象数据库，但实际上关系数据库并没有被淘汰，于是就只能在上层的应用层找解决方案。这时候我明白了我需要的实际上是一种 ORM产品。
　　
　　我最早想到的ORM就是JDO，于是我下载了两个JDO产品，准备认真的学习一下，但是研究了一段时间之后，我发现我对JDO非常的失望，原因如下：
　　
　　1、 JDO没有一个好的开源免费实现，好的产品都是商业产品，并且在国内没有销售和技术支持。这就造成了JDO只有学习之用，不能把它用在实际项目中，否则的话，你把软件卖给客户的时候，还要告诉他，你还要另外去买一个国外的软件产品，并且在国内没有技术支持，出了持久层的问题，我们也解决不了，请你自己打国际长途去解决问题，你认为客户能答应吗？
　　
　　2、JDO不是一个轻量级封装，它试图建立一个完整的持久层框架，但是还很不完善，造成了JDO 感觉比较笨重，很多操作方式令人觉得烦琐和古怪。这加重了程序员学习和编程的负担，而且封装的太多会造成一个严重的问题就是一旦出现报错信息，调试起来非常困难，你很难准确的定位错误究竟出在哪里，封装的越轻，问题越容易定位，越容易解决，封装的越重，问题越复杂，越找不到原因，CMP就是一个很好的例子，出了错误，调试起来非常困难和麻烦。
　　
　　3、JDO的标准很不完善，存在重大缺陷。最主要的问题体现在PO不能脱离PM（相当于 Hibernate的Session）而存在，这是个非常严重的问题，会造成编程的时候进行大量VO的拷贝操作，烦琐极了；另外一个重大缺陷是静态的 POJO的Enhancer，不能运行期动态Enhance，无法进行增量编译和调试，编程和调试起来非常烦琐，每次都要手共运行一个工具对POJO进行 Enhance；此外还有一些缺陷，例如JDOQL不完善，映射关系的表达不够强大等等。
　　
　　4、JDO产品的分裂。这个问题也比较严重，由于JDO1.0标准的缺陷，而JDO2.0标准还遥遥无期，而各个JDO厂商为了能够在竞争中脱颖而出，那么除了在易操作性和性能上的提高之外，想要吸引客户，就必须有自己的产品特色。那么1.0标准的缺陷正好给了他们发挥的舞台，每个厂商都会有自己独到的解决方案来解决标准的缺陷，然而这却造成了JDO 产品事实上的分裂。这种分裂严重到什么程度？我可以简单举个例子：你写好的POJO，用一种JDO的Enhancer进行Enhance过以后得到的 PO，在另一个JDO产品上跑不起来。这很像当年Unix的分裂，结果就是二进制代码级的不兼容，而只能在C源代码级兼容。现在的JDO也有这样的趋势，就像App Server的差别一样，一个在Weblogic上开发好的EJB，移植到Websphere，你一定需要重新进行配置。
　　
　　我心目中的ORM最好有如下的特点：
　　
　　1、开源和免费的License，我可以在需要的时候研究源代码，改写源代码，进行功能的定制。
　　
　　2、轻量级封装，避免引入过多复杂的问题，调试容易，也减轻程序员的负担。
　　
　　3、具有可扩展性，API开放，当本身功能不够用的时候，可以自己遍码进行扩展。
　　
　　4、开发者活跃，产品有稳定的发展保障。
　　
　　抛弃了JDO以后，我根据上面的原则，先后排除了TopLink，CocoBase，Castor等，最后选择了Apache OJB和Hibernate。
　　
　　OJB的排除很容易做出，一是因为它的文档太简单，太少；二是因为OJB计划下一个版本全面支持JDO，它的API会有重大变动，所以现阶段学习OJB是个错误，等它的API稳定了以后再学习不迟。
　　
　　Hibernate的发现是很偶然的事情，只是在别人提到JDO的产品中，附带提了提而已，但当我开始研究Hibernate之后，我发现终于找到了我梦寐以求的ORM了。
　　
　　Hibernate 完全符合我上面提到的标准之外，也解决掉了JDO的所有缺陷，而且方式之优雅令人赞叹。Hibernate的文档也是非常非常有特色的地方，它不仅仅是 Hibernate的功能介绍那么简单，它实际上是一个持久层设计的最佳实践的经验总结，文档里面的例子，文档里面的总结全部都是最佳设计的结晶。我认真的把Hibernate读下来的感觉就是，不单单把Hibernate掌握住了，而且对持久层的设计的经验都长了一大块，以前可从来没有觉得持久层的设计还有那么多的学问，也由此感觉到Gavin绝对是一个大牛人。
　　
　　当然选择Hibernate最最重用的原因是Hibernate是一个我能够完完全全驾驭的了的软件。Hibernate的源代码非常少，而且写的非常简洁，我总觉得挺奇怪的，这么少的源代码能够实现这么多的功能，是个奇迹。 Hibernate的源代码树分的很清楚简单，源代码很易读，我一旦碰到文档中没有讲到的问题，或者文档中提到但是我搞不清楚的地方，我就去源代码中找，所有的问题都豁然开朗，而且让我对Hibernate的运行原理和细节搞的特别清楚，好像Hibernate就像自己写的代码一样，很清楚的知道，怎么写程序可以让Hibernate运行效率最高，最省内存，程序出了错误，很清楚的知道是什么地方的问题，怎么解决。所以用Hibernate让我特别放心，我能够驾驭它，而不像那些过于复杂的软件，本身框架就复杂的很，再加上不开源，出了问题也不知道怎么回事。

What's in store for 3G? More sophisticated inventory management is required if mobile operators are to get the most out of 3G - The Future of Telecom - Industry Overview
Telecommunications International,  Jan, 2003  by Ronnie Beggs

Is it written in stone that 3G profits are years away or can money be made sooner? The good news is that there is a way to accelerate 3G's arrival, but it's through the back office and not the front.

As we know, 3G networks are more complex than the previous generation of wireless networks. That's the tradeoff -- flexibility comes at the price of complexity. And complexity, if it isn't to cause trouble, needs to be managed. The simplest and most public example is the issue of 2G/3G handoff, which has no real equivalent in the simpler 2G world. And the solution is only partially to do with handset technology.

So, understanding what new complexities 3G introduces to conventional wireless networks and operating practices is essential. And this means taking a fresh and thorough look at how back-office software systems - so-called operational support systems (OSS) - can deliver an efficient operation.

Implementing the right OSS, one that supports network build, provisioning processes and staff resource requirements, marks the path to 3G longevity. Carriers must recognise that the more complex requirements of 3G necessitate a new view of OSS, and this is where inventory management comes in.

Different generations

To understand why OSS is a priority for 3G, it's important to understand the differences in 2G OSS. In 2G (and before), coverage was the primary concern. Carriers rolled out cell antennas and base stations to cover as much geography as they could. The networks delivered basic mobility across populous regions, offering services analogous to wireline POTS.

The relative simplicity of 2G operations focused investment more on network rollout and support of cell sites than operational efficiencies and OSS. Aside from network tracking and billing applications, there was little need for a sophisticated operational support systems infrastructure. It wouldn't have been high on a priority list because it would have had little impact on the things that mattered most to the business at the time - subscriber acquisition based on available coverage based on network build based on socio-demographic models.

Industry-accepted OSS models, such as the TeleManagement Forum's Telecom Operations Map, validated the 2G carrier approach to OSS. The TOM's first iterations positioned OSS in the traditional realms of fulfillment, service assurance and billing - a service-oriented view that met 2G requirements.

3G, however, radically changes what's needed in the back office. In addition to voice, 3G will deliver mobile internet access based on packet-switching and across multiple technologies - such as IP and ATM - rather than the connection-oriented voice-only 2G services. It will deliver much higher bandwidth, enabling mobile video applications and mobile web browsing, and provide mobile applications and access to web-based services from anywhere. Such applications will fundamentally depend on the availability of bandwidth wherever a subscriber happens to be. Whereas 2G coverage required new network build, 3G demands large-scale change to the existing infrastructure.

But the supporting systems needed are vastly different. Instead of simply tracking where network assets are, operators need ways of managing, pre-planning and allocating the much higher capacity that 3G networks will contain. Capacity, rather than just the ability to offer mobility (which a national network of cell sites and interconnection offers), is now also a critical asset for the service provider to track and manage.

The additional capacity required to service high bandwidth applications at the edge of the network will mean that leased capacity will be too expensive to depend on. Operators are building their own transmission networks and managing backbone capacity themselves, a next-generation reality that demands OSS sophistication.

This step change in technology that 3G represents is the primary force pushing operators to pay close attention to OSS. Delivery of high bandwidth services across multiple technologies requires a broader interpretation of 0SS to include not just the billing system, but quality of service, differentiated services, capacity and service transport -- the very same issues that wire-line carriers are just beginning grasp with 055 themselves.

As technical complexity shifts 055 thinking, the industry is broadening its view of ass and influencing operator ass decisions.

The role of TMF

TeleManagement Forum's Next Generation OSS initiative, or NGOSS, represents a consortium of carriers and vendors working towards accurately defining the OSS to help the industry address it effectively and completely. A key component is eTOM, or enhanced Telecom Operations Map, which illustrates the wider focus OSS must have if carriers are to successfully manage vast networks comprising new and ever changing technologies and services.

eTOM identifies processes and applications associated with network building, capacity management and provisioning, in addition to the traditional OSS tasks of fulfillment, assurance and billing. And eTOM's expansion of the OSS boundaries is affecting operators' strategic OSS decisions because it exposes the interaction between planning processes and operational management -- functions that the 2G world isolated bath technically and organisationally.

Moreover, eTOM provides a framework to make the integration between planning and assurance possible, and is creating an industry-wide realisation that effective service assurance (and by extrapolation, customer satisfaction) is linked directly to the quality of the network build and the foundations for the service transport.

As the bridge between network planning and network operational management, inventory management is key. Inventory management means maintaining the service-to-network relationship information essential for efficient operations management across the multiple technologies and bandwidth requirements introduced by 3G. It also means maintaining a unified end-to-end view of network connectivity (from cells to application servers) to support the reservation of future planned resources.

A skills shortage

Technology isn't the only issue in the leap from 2G to 3G that is focusing attention on inventory. There's a people problem, too -- a major skills shortage of the right technicians with the right knowledge and experience.

It's apparent in two areas: knowledge of IP and ATM service and network management, and experience of large-scale network rollout. The former can be addressed by importing skills from fixed line carriers but this knowledge still has to be applied in a mobile environment.

The latter is more difficult. The majority of people in the industry have entered after the original GSM networks were rolled out, creating a shortage of people with experience in managing such large-scale rollouts. Consequently, the ability of the inventory management application to automate network build tasks is essential, enabling operators to implement networks consistently and quickly with fewer skilled staff.

Inventory management

Taking a central role in the OSS, inventory management supports three critical functions in the 2G to 3G transition process: network planning, capacity management, and network provisioning.

First, in a network planning role, inventory assures that 3G carriers build the right network the first time. Having spent more than US$100 bn in licences alone, carriers cannot afford to make mistakes in the equally cost-intensive network deployment process.

Second, in addition to physical inventory, successful 3G operations will demand precise knowledge of available capacity. Unlike 2G voice networks, 3G networks will carry data-centric services from any number of different content providers, requiring capacity to be available whenever and wherever a subscriber service needs it. By modelling logical capacity as well as physical resources, inventory can help assure 3G networks meet the bandwidth requirements of the services they intend to deliver.

Finally, inventory enables automated network provisioning. Using the physical and logical inventory data to set configuration rules, routine processes (such as reparenting of base stations) can be automated to speed network deployment and assure consistency.

Inventory in use

The idea of highly automated inventory-centric operations isn't a pipedream. It's being done now. There are solutions available that provide the sort of capability that is helping startup and transitioning 3G operators meet launch schedules and build confidence in their long term operating efficiency. Software can also be used to provide inventory-centric provisioning support for the rollout of a mobile operator's radio access, core switching IT and transmission networks. These tasks can be done within just a few weeks to support a mobile operator's network and capacity planning. Automation of highly repetitive tasks, such as site build specifications, can also be employed to both speed up the design process and ensure consistent results.

A solution such as this provides centralised access to network inventory information across the entire organisation, modelling critical network resources such as UMTS, transmission, IP, and ATM network equipment, logical network connectivity and physical network configurations.

Don't forget ROI

Inventory-centred OSS can also accelerate a carrier's ROI (return on investment]. Consider the hypothetical case of a 2G operator moving into 3G with 2,500 new base stations. Productivity improvements might include:

* improved inventory accuracy and process automation templates that reduce design effort by 20 per cent;

* complete and accurate network inventory reduces errors that lead to rework by 50 per cent, and also reduces any necessary rework effort by 50 per cent;

* planning and design efforts for BTS reparenting can be reduced to as little as 30 minutes; and

* a single inventory repository can reduce alarm augmentation effort by 50 per cent, and reduce resolution rework by 50 per cent.

Plug in some numbers based on conservative calculations and these benefits alone can lead to a possible cost savings exceeding US$27 m -- a significant return in a cost-conscious, profit-hungry industry.

Profits versus prophets

The telecom industry has a history of sceptical predictions that often turn out to be plain wrong. Those today predicting a decade or more of 3G profit-free years bring to mind the naysayers of two decades ago who predicted that wireless growth was not sustainable.

Today we know wireless communications as one of the most remarkable growth industries ever and 3G is its next chapter. Carriers adopting the right inventory-centric OSS approach as part of their transition to 3G will win and hold the lead in this market -- they'll be the first to return profits and overturn the prophets of gloom.

Ronnie Beggs, product manager (wireless), Cramer Systems

COPYRIGHT 2003 Horizon House Publications, Inc.
COPYRIGHT 2003 Gale Group