出家如初,成佛有余

学习电信BOSS系统好榜样-电子商务系统建设思考2:方法论

Posted in Uncategorized by chuanliang on 2007/12/01

    诸如B2B、B2C、C2C、电子支付这样提供SaaS的电子商务运营商所提供的电子商务系统与电信运营商的BSS/OSS类似,都为运营性系统。所谓的运营性系统是指通过软件系统持续的建设和运营为客户(主要为外部客户)提供服务。运营过程的集成性、实时性和动态性、敏捷性,要求运营商的支撑系统必须能支撑动态变化的需求和在线实时管理变化的要求,要求支撑系统的业务业务架构和技术架构能支撑新的业务模式引进和局部功能模块重构的需要,保证新的运营支撑系统的业务架构和技术架构能支撑动态变化和管理动态变化。怎样让支撑系统能够这些需求相匹配呢?

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

1、SANRR方法论

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

ngoss sanrr methodology

 

它包括五个实现步骤:

  1. 定义范围(Scope):通过对当前环境的描述和实现目标的设定,明确定义系统演进需实现的业务和功能的范围、边界。
  2. 分析(Analyze):分析新增业务或功能与原有业务或功能的关系,并用模型化语言对新增业务或功能加以定义和描述。
  3. 规格化(Normalize):分析新增业务或功能对原有业务流程、功能模型、信息模型、业务规则等的影响,将新增部分加入到原有模型中,形成一个统一的新模型。
  4. 合理化(Rationalize):通过检查和验证,进行差异分析、冲突分析和冗余分析,列出和标明出现的问题。
  5. 纠正(Rectify):针对上个步骤列出的问题,对产生问题的模型进行修改,重复4)和5)直到全部完成。

    NGOSS方法论不是重新创建的一套全新的方法,而是当今软件领域各类知识有机融合的产物,反映了当前一些最新的软件工程思想,因此,有些方法还在不断发展中,并未成熟。同时,NGOSS方法论中提出的一些方法还需要相应的可操作性的模板和工具的支持。因此,在方法论的应用上,首先要遵循的原则是充分领悟方法论所包含的思想原则、工作方法。只有在深刻领会其思想原则的基础上,才能有效利用市场上一些成熟的工具,协助电子商务系统的开发和建设。其次是不断积累相关知识,包括各种在电子商务系统开发过程中产生的中间结果和元素,为需求的不断改变和扩充提供可重用的组件,缩短业务部署和提供的时间,真正做到适应市场的变化。 

 

2、NGOSS 架构视角

ngoss views

clip_image002

    该模型提供了从两类NGOSS应用者看系统的视角,一类是业务提供者的视角,一类是系统开发者的视角。两类应用者又分别从逻辑的和物理的两个层面看系统。逻辑层面关注解决方案中技术无关内容的定义,如业务流程、业务规则、信息模型等。物理层面关注解决方案中技术相关内容的定义和具体实施,如具体实现技术选择,COTS产品选择,运行方案等。
    这样构成了四个视角,分别是业务视角、系统视角、实现视角和部署视角。

  • NGOSS业务视角:

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

  • NGOSS系统视角:

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

  • NGOSS实现视角

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

  • NGOSS部署视角:

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

  • NGOSS知识库:

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

NGOSS的视角实际上来自于RUP用于描述系统架构的4+1视图模型:

  • 逻辑视图(Logical View):设计的对象模型(使用面向对象的设计方法时)。与ngoss的系统视角对应
  • 开发视图(Development View):描述了在开发环境中软件的静态组织结构。 与ngoss的实现视角对应。
  • 进程视图(Process View):捕捉设计的并发和同步特征。 ngoss没有直接单独为一个视图
  • 物理视图(Physical View):描述了软件到硬件的映射,反映了分布式特性。 与ngoss的部署视角对应。
  • 用例视图(Use Cases或Scenarios):描述业务需求及场景。与ngoss的业务视角对应。

image002 

    软件架构 "4+1" 视图模型

3、eTOM业务分层模型

image

eTOM所定义的三大流程区域:战略、基础设施和产
;运营;企业管理

五大经济实体

  (1)客户:企业通过销售产品向其提供服务的对象,是业务的焦点。

  (2)供应商:向企业提供所使用的产品或资源,直接或间接地支持企业的业务;合作伙伴,企业与其共同享有的业务区域的合作对象。

  (3)股东:为企业投资从而拥有企业的股份,SP从股东处获得财务资源。

  (4)雇员或员工:为企业工作,为企业追求和实现业务目标;SP获得雇员的服务来执行企业的流程。

  (5)其他企业利益相关者:不是以股票拥有者身份与企业签有协议或承诺,包括监管者、媒体、当地社团、政府、竞争对手等。

层次结构分解

对大量内容和细节进行组织的最好方法就是以多个层次或层面来构建信息,这样层面高的视图代表着概要视图,而且每一高级层面可以分解成更详细的低一级层面,即:层次结构分解。

通过把eTOM划分成多级层面,使框架应用者可以参照eTOM不同的框架层面来安排其企业框架或流程实施,比如,根据第一级和第二级层面或根据第一、二、三级层面来安排。

eTOM是按以下方式来进行层次结构分解的:第0级层面——企业总体视图(也就是,eTOM的全部);第一级层面——每一纵向流程群组(端到端)、每一横向流程群组(功能);第二级层面——所有的流程元素,如,订单处理(它既出现在端到端流程群组中也在功能流程群组出现);第二级层面的流程元素可以分解成第三级层面的流程元素;第三级层面的流程元素可以分解成第四级层面的流程元素;在eTOM中所有流程分解的子层面只到第四级层面,因为流程分解不必解释从一个流程分解到另一个流程分解的同一层面的细节。分解所需的层次数量必须与流程的复杂性和所在层面的流程流向一起考虑才能有意义。

纵向流程(端到端流程)
纵向流程群组,代表端到端的业务流程视图,

横向流程(功能流程)
横向流程群组,代表与业务功能流程有关的功能视图

4、SID共享信息模型

    NGOSS提供了一整套的方法论来指导OSS/BSS的设计与建立,它的核心设计思想是利用“流程驱动”,系统设计时首先从流程分析开始,分析自己企业的核心业务流程;然后通过分析流程,提炼出所有关键的数据,利用共享信息模型将数据进行抽象,划分为不同的管理域建立共享的数据模型;最后根据共享的数据模型组建实际的OSS/BSS系统。数据是OSS/BSS设计中最重要的特性,成功建立OSS/BSS系统关键是有一个好的共享信息模型。因此,NGOSS提供出了共享信息模型的通用框架—SID。

    SID是NGOSS提出的建立共享信息模型的通用框架,SID分别从商业和系统两个视点描述了共享信息模型。一方面,SID从商业视点出发,以ETOM LEVEL 0定义的业务处理模型为基础,依据对商业过程中涉及的各种商业信息的抽象和分析,定义了各种可聚和的商业实体ABE以及各种商业实体BE,并将它们划分为不同的管理域,形成了系统和信息图SIM,从而最大限度地实现信息和数据的共享。另一方面,SID从组建OSS系统的视点出发,对各种商业实体的属性进行定义,并利用UML将它们有机地组合在一起,形成UML模型,从而为设计用于实现OSS系统实际使用的共享数据模型提供参考模型。综上所述,SID是商业和系统的实体定义和UML模型的有组织的集合。

clip_image002[6]

  • 客户域

    客户域指一个已获得或可能获得第三方支付提供商所提供的产品和服务,并具有承担法律责任能力的个人或者组织的客户信息及相关用户信息。用户信息包括用户识别信息、订购的产品信息、资源占用信息、用户评价信息。

    客户域包括:客户、用户。

  • 合作伙伴域

    合作伙伴域是指在第三方支付提供商业务活动中与支付提供商拥有共同的目标和利益并承担相应职责的组织的信息。根据合作性质可以分为:设备供应商、服务提供商、虚拟运营商等。

    合作伙伴域主要包括:合作伙伴信息等。

  • 市场营销域

    市场营销域是指第三方支付提供商进行营销和销售活动等方面的信息聚焦。

    市场营销域包括:营销方案、市场细分、竞争对手、营销活动、商机信息、报价/解决方案等实体信息。

  • 客户交互域

    客户交互域是指客户交互过程事件可能产生的多种数据信息聚集。

    客户交互域包括:客户接触数据、客户订单、客户服务请求,以及缴费/退费信息。

  • 产品域

    产品域是指第三方支付提供商如何面向市场组织产品提供及如何定义产品的信息聚焦。产品域实体定义了能够被客户购买/租赁的内容,其中包括产品、服务和资费,以及关于产品/服务的所有相关信息,包括品牌管理、产品目录、产品之间的关系、产品限制等。

    产品域包括:产品目录、产品、服务、资费等实体信息。

  • 帐务域

    帐务域(含计费)是指客户使用第三方支付提供商产品发生的清单、费用合计、优惠和收费销帐全过程信息及帐户余额管理所需的信息资料,是费用合帐、帐单生成、资金回收、欠费管理、帐户余额管理的基础。同时还包含合作伙伴及运营商的结算信息。

    帐务域包括:帐户、帐本、收支记录、帐目、帐单、清单、付费计划、帐务关系等实体信息。

  • 资源域

    资源域是指第三方支付提供商有形或无形的业务运营资源定义、开发和操作全过程的信息聚焦。资源域可以将资源关联到产品和服务,确保资源能够支持第三方支付提供商的服务交付。

    资源域包括:资源配置、资源使用、资源故障等实体信息。

  • 通用域

    通用域是跨越两个或更多主体域的业务实体信息的聚集。这些业务实体信息不是由任何一个主题域所单独拥有。

    通用域包括:协议、地域、组织、人员、知识、任务、工单等信息实体。

 

5、电子商务系统建设的实践

    以SANRR方法论为指导,已etom的分层模型来指导业务建模和产品生命周期管理过程,采用NGOSS的架构视角(4+1视图)来描述系统架构,建立其电子商务系统的SID(共享信息模型)。

5、参考资料

http://blog.csdn.net/quanhuang413/archive/2006/07/30/1001694.aspx

http://www-128.ibm.com/developerworks/cn/rational/r-4p1-view/

http://industry.ccidnet.com/art/71/20031229/78063_1.html

http://www.ccidcom.com/Technology/Support/200408/184.html

TMForum GB927_20041124_v13

Technorati 标签: ,,,,,
Tagged with: , , , , ,

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s

%d 博主赞过: