ESB项目实施过程.docx
- 文档编号:13041055
- 上传时间:2023-06-10
- 格式:DOCX
- 页数:21
- 大小:70.83KB
ESB项目实施过程.docx
《ESB项目实施过程.docx》由会员分享,可在线阅读,更多相关《ESB项目实施过程.docx(21页珍藏版)》请在冰点文库上搜索。
ESB项目实施过程
ESB工程实施过程
提交人:
军丰
提交日期:
Mar30,2013
版本号:
v1.0
文档控制
变更记录
日期
作者
版本号
变更参考文件
Mar27,2013
军丰
V1.0
创立文档
审阅
日期
**
职位
Mar1,2013
MangerName
审阅
甲骨文公司声明
本文件是由甲骨文(中国)软件系统**〔以下简称:
Oracle公司〕向**〔以下简称:
**〕免费提供,其容专供**用于评估Oracle公司为其提供产品及效劳的能力,仅供参考。
本文件所包含的信息所有权属于Oracle公司。
由于本文件包含Oracle公司**资料,因此要求〔**〕在收到本文件后三年应为Oracle公司**;除非根据法律要求,不得出于除本工程评估之外的任目的,以任形式向任第三提供本文件容;并同意采取所有合理的步骤,保证其接触本文件的人员不对外披露或散布本文件容。
本文件的容将可能且应该根据(**工程)的具体实施情况及阶段的变化而变化。
本文件对硬件规格、型号、性能的分析与估计并没有考虑操作系统、网络资源或任其它在同一效劳器上运转的应用软件对硬件的消耗。
具体的硬件配备必须根据硬件厂商的推荐来决定。
对本工程硬件最终选择的决定权应由客户掌握。
本文件中对硬件规格的估计也不对客户形成任具有约束性质的述或担保。
请注意:
如果您不同意上述声明,请不要阅读本文件,并立即将其返还给Oracle公司;否那么,Oracle公司将视为您承受并同意遵守上述声明。
1概述
目前,很多银行根据自己的实际情况,选择ESB工程作为基于SOA进展IT架构整合的落地工程。
然而,在实施过程中,由于ESB类工程实施过程具有自身的特征,尤其是涉及到效劳如定义,行或者工程组往往会有一些困惑和疑虑,在工程初期对工程整体缺乏把握和信心,感觉难以落地。
本文的主要目的是为客户和实施提供ESB工程的参考实施过程。
通过介绍ESB工程的实施过程和特征,为用户提供工程的参考实施路线图。
本文的组织式将按通用“瀑布〞工程模型进展描述,从工程启动到工程上线,在各个过程中描述该阶段主要的工作、流程和特点,涉及到的角色和主要任务,也会包含局部模板,供用户参考。
具体模板需要根据工程实际情况进展调整,以更符合实际工程的特征。
对符合一般工程过程的知识点不在该文档描述。
2ESB类工程实施过程
2.1ESB工程特点简述
ESB工程整体实施过程和其他工程在大的阶段划分上相似,然而,不同于一般业务系统的实施,ESB工程更多表现为一个技术类工程的实施,或者说是集成类工程的实施。
ESB工程往往需要集成多个系统,各个业务系统对应的开发商、业务部门甚至技术部门部的小组和人员都不同,因此,ESB工程的协调沟通类工作远远大于普通的业务类工程,这对ESB工程的工程经理、需求分析人员和架构师提出了更多的要求。
同时,由于涉及到到的系统多,而各个系统的开发方案、上线点并不完全一样,因此,ESB工程总体上表现为“瀑布〞模型,而具体实施过程往往表现为“迭代〞模型,这在ESB工程实施二期表现尤为突出,因此,在制定工程方案时,一期可能是“瀑布〞加“迭代〞,二期往往就是“迭代〞,假设二期上线系统多时,由于每个系统上线都要执行完整的上线流程,工程组将面临很大的上线压力,当然,这是二期及以后才会面临的压力。
另外,由于ESB工程是一个架构类工程,而企业很难在短的期完成大量系统的调整,因此,ESB工程的工程期也会较长,需要工程组和行制定合理的总体规划和推进路线。
在后续的章节,将按阶段描述ESB的实施过程。
2.2工程启动
2.2.1工程围和估算
工程围的重要性和作用不在此赘述,在此需要说明的是,ESB的工程围主要是接入的系统,集成的系统数量不同、复杂度不同,工作量会有较大的差异,因此,接入系统是工程首先需要确认的问题。
当接入的系统确认之后,我们可以初步了解系统的情况、包含通讯协议、报文类型等,作为工作量估算的依据,主要是估算接入的连接器是否需要定制、接入的特殊要求、接入的难度等,以估算接入系统需要的工作量。
以下是一个估算文件,供参考,具体的基数需根据实际情况而定。
另外,该工作量主要是效劳定义、开发的工作量,未包含系统自身功能的开发工作量,工程总体工作量需要综合考虑质量管理、性能测试、上线等。
另外,接入系统的多少也涉及到接口的数量,接口数量将是需求分析主要的参考依据,因此,在工程开场阶段会要求收集这类信息。
以上都是比拟容易确认的信息,或者说是客户能够明确给出的信息,但有一点需要注意的是,在制定工程围时,涉及到平台功能如监控功能、管理功能、流水功能、冲正功能等,各行往往会有不同的要求,而这些要求在工程启动时难以确认会有哪些,因为客户对产品功能还没有深入的了解,因此,该局部围将难以确认,工作量也较难估算出来。
一个方法是:
由于ESB工程的期将分为多个阶段,因此,这局部可以做的粗一点,在工作说明书中说明未完善局部在二期完成,与客户达成一致意见;同时,在工程启动后,尽快向客户演示这些功能,与客户就这些容进展沟通与确认,再制定具体的资源方案和开发方案。
工程启动前,尽早完成接入系统的调查,以便进展开发工作量和需求分析工作量的估算。
接入系统调查表可以参考以下容,根据工程和行实际情况调整:
该表的目的是确认存量系统的技术、接口现状,能否修改,是否在本次修改,后续是否有改造方案等,这些信息将影响工程的方案安排,也会影响到对存量系统实施策略。
系统的接入式,是否修改等策略,需要在架构文档中进展描述和说明,当然,之前也跟客户达成一致意见。
一般而言,新系统的开发,或者改造较大的系统,一般要求按照标准Webservice式实现和接入,实在有困难的,可考虑作为效劳提供和效劳请求采用不同的式;对存量系统,需要考虑改造难度、是否有开发团队、能提供什么样的支持等,决定具体的通讯式和报文是按照标准格式还是按照原有格式,这需要跟行一起,与原有的开发商进展沟通协调,因为这可能会带来预算的增加。
工作量的估算,业务系统往往会按照功能点估算,ESB工程除了系统本身功能是按照功能点外,需求分析是按照接口的数量进展估算,开发是按照新增connector的数量、报文格式的数量等估算,另外需要考虑集成的工作量。
系统集成的工作量将是ESB工程特别注意的一点,往往会消耗较多的资源投入。
在估算工作量时,需要根据工程组人员技能情况,给出适宜的估算单位值,如每个效劳从接口分析、效劳定义、效劳开发实现、效劳测试、完成集成测试、功能测试等给出单位人日数,以此为基准给出具体的数值。
在该数值估算过程中,可以参看以下章节中具体的效劳定义过程,结合对ESB产品的掌握、报文的类别〔是否标准SOAP报文,是否需要报文格式转换、是否需要字段映射〕、开发人员技术集成等综合评定。
同理,系统集成的连接器开发等也需要根据类别进展估算。
完成以上工作后,考虑工程管理工作量、质量管理工作量、性能测试工作量、知识转移工作量等等,加上工程风险的预留Buffer,可以得到工程工作量估算。
2.2.2工程角色
ESB的工程角色和其他工程角色一样,然而,由于ESB工程工程特性,需要的技能有所不同,以下给出主要工程角色的技能要求。
工程经理:
如前所示,由于涉及到多个同时实施〔开发或改造〕的工程,ESB工程的工程经理需要具有工程群经理的技能,虽然不是直接收理各个工程,而只是负责管理ESB工程,但应该从工程群管理角度,发现可能存在的风险和问题,从工程群角度综合考虑工程进度、工程风险,协调对应的工程方案,并积极寻求行的理解和支持,推动整体工程群的上线。
ESB工程的管理者需要谨记:
只有所有相关系统上线,ESB工程才算成功上线,否那么,只是局部完成了任务;虽然责任可能并不在ESB工程组自身,然而从客户角度来看,工程并没有到达预期的目标。
因此,ESB工程经理需要极强的推动力和执行力。
架构师:
ESB工程的架构师更关注整体集成架构,而不仅仅是单个工程的架构,因此,需要架构师具有较强的集成架构设计经历。
能够把SOA的理念和具体执行传到达其他相关工程组,制定技术规并指导其他工程组按照ESB的技术规完成系统开发和集成。
需求分析人员:
ESB工程的需求分析人员和常见业务系统的分析人员不同,分析的对象是原有的系统和接口,对原有接口进展梳理和抽象,结合自己的行业经历和专业经历,整理和发布为效劳。
因此,要求ESB的工程分析人员对要接入ESB的业务系统的业务比拟熟悉,必要时,能够与该系统的业务人员直接交流,收集该业务的开展向,以保证提供的效劳具有较长的生命力,能够支持未来业务的开展,具有较好的扩展性。
同时,还具有一定的技术背景,能够对原有接口的合理性进展分析,给出修改建议,以便更符合效劳定义的要求〔主要是存量系统;但实际开发过程中,往往实施商已经有对应的产品或者产品原型,外部接口已经定义好,此时,对新系统的接口同样要进展分析和调整〕。
开发人员:
开发人员主要工作分为两类,一是完成对应的系统连接器开发;完成产品功能与客户期望差异的实现;二是完成具体效劳的配置和实现。
其中,第一类技能要求较高,要求对产品比拟熟悉,且具有一定的设计能力;第二类要求较低一些,主要使用工具完成效劳配置,完成字段映射及局部效劳组合逻辑,相对要求较低一些。
在ESB工程第一期,对第一类技术人员需求稍多一些,而在一期之后的二期,只需要极少的第一类员工即可,甚至架构师可以直接兼任该局部工作,只配置第二类人员即可。
其他工程角色没有特殊的要求,此处不再赘述。
需要特别指明的是,ESB工程组不需要专门的功能测试人员,因为没有具体的业务功能〔产品自身的管理功能、监控功能、客户特色功能除外〕,因此,可以由开发人员完成功能测试,但需要做好测试案例的设计和管理。
2.2.3工程方案
在工程围确定后,需要明确各个工程的上线时间点,在很多情况下,各个工程的上线时间点不完全一样,需要采用分批上线的策略。
局部工程群实施过程中,也可能在初期设定同样的上线时间点,但随着工程的进展,个别工程出现风险,也会出现调整为分批上线,因此,在工程初期,需要制定对应的应对案和策略。
对于同一上线点的工程实施,可按照“瀑布〞模型制定工程方案,一般包含工程启动、需求分析、架构设计、概要设计、详细设计、开发及单元测试、集成测试、FAT测试、UAT测试及上线试运行。
其中,在需求分析和集成测试阶段,由于该阶段的进入条件对其他工程组的输出物有依赖关系,因此,需要特别注意其他工程组的工程方案之间是否匹配,如:
需求分析需要对系统间接口进展收集和调研,而在工程初期,个别工程间调用关系尚未确定,需要在概要设计才能确认,这样需要调整ESB工程中涉及该工程对应的方案和资源,以降低带来的工程风险和资源浪费;或者要求对应工程组采用分批次提供交付物的式,以防止出现达不到对应进入条件,而无法进入工程下一阶段的问题。
另外,需要特别关注工程集成阶段。
理论上,各工程将在同一时间点开场工程集成,并共同完成工程集成阶段,实际过程中,工程集成阶段往往是工程风险最大的点,经常出现工程进度远远落后于集成时间的问题,该问题在同一个工程的不同开发组之间出现的概率就极高,在多个不同开发商实施的工程之间出现的概率会更高,原因有多个,但常见的问题是基于工程时间的压力,各工程组有意无意的会选择性忽略系统间集成,或者只给出2-3天这样很短的时间,以为开发阶段留出更多的盘旋余地〔集成延期,由于涉及到多个工程组,客户往往难以判断具体的原因,工程延期的责任往往是共同分担,弱化集成阶段是工程经理常见的小手段〕。
ESB工程经理需要特别关注各工程组的集成方案是否合理,各效劳或者接口的集成时间是否匹配,因为不可能同时开发各个效劳或接口的集成,而是排在不同的时间集成,很容易出现A工程安排的集成方案和B工程组不一致的情况。
另外,各工程组也可能采用分批完成效劳功能的开发,分批次进入集成阶段的策略,此时,各工程组经常只按照自己的资源安排,给出对应的功能开发和联调方案,而不关注对应工程组的进度,此时出现不匹配的可能更高,需要ESB工程的工程经理掌握各个工程组的工程方案,发现存在的风险和问题,并协调各工程组进展修改以匹配总体的进度方案。
2.2.4组织构造
出于ESB工程涉及到的系统多,往往需要取得客户高层的支持,因此,在建立PMO时,建议客户PMO的高层人员同时兼任工程群的客户工程总监或工程经理,一般建议客户人员为科技部总经理。
这样,当出现需要协调各工程组的时候,可以借助客户的推动力推动工程按预期执行。
在此过程中,ESB工程的工程经理需要主动协助工程群管理者,监控工程群中各工程进展、及时发现风险和问题,给出应对策略。
2.3工程需求分析阶段
ESB工程的需求分析主要分为两个局部:
对产品或平台自身功能与客户期望差异的分析与效劳定义。
差异化分析与不同工程一样,重点还是效劳的定义。
和其他业务系统不同,ESB工程并不会直接与客户业务部门发生联系,然而,由于需要完成效劳定义,却需要需求分析人员参与各业务系统的需求分析,获取业务部门的第一手资料,了解业务部门的预期,同时,在此过程中也是熟悉业务知识的最有效途径,对效劳的抽象、效劳的分析与定义有很大的帮助。
ESB工程组或者客户经常面临的问题是如定义效劳.粒度如划分.以下章节将详细描述效劳定义的法和相关流程。
2.3.1ESB工程与其他SOA工程的差异
ESB工程虽然也是按照SOA法构建系统,然而,在实施过程中,ESB工程往往呈现为一个系统整合工程,主要的问题是其他相关系统可能并不是按照SOA式进展设计和开发,而且,其他工程也并不是从零开场构建,一般会有产品或者产品原型,实际开发过程中我们也很难要求其他工程完全按照SOA的思路对系统进展大的改造,因此,ESB工程在是实施过程中面临的处境是:
虽然其他相关新系统也是同步开发和实施,实际上和存量系统的整合非常类似,只是我们可以要求新系统按照标准的报文格式和通讯式进展修改,对输入、输出报文可以要求按照定义的效劳进展修改。
换一句话说,我们只能要求系统间的交互按照效劳的标准进展,系统部的实现是很难干预的。
因此,虽然我们有对应的效劳设计原那么,如:
Ø标准化效劳契约
Ø效劳松耦合
Ø效劳可重用性
Ø效劳自主性
Ø效劳的无状态性
Ø效劳可发现和组合
实际执行过程中,其实是分析各工程组提供的系统间交互接口,对这些接口尽可能按照以上原那么进展调整,并要求原系统进展修改,具体表现就是对接口进展分析,对没有完整业务含义的多个技术接口进展合并,对相近接口进展整合和扩大,调整为一个效劳,对个别由多个系统共同完成一个完整业务的进展架构调整,调整为一个系统提供效劳〔常见场景是核心系统和前置系统各完成局部功能,由前端进展接口组合调用〕。
另外,这些大的原那么由于缺乏具体的操作说明,在实际过程中还是常常不知道该如把握。
2.3.2效劳分析步骤
在操作过程中,我们可以按以下步骤进展效劳分析:
各个步骤主要工作如下:
第一步:
接口分析,主要是收集各系统间交互的接口信息;
第二部:
效劳识别,主要是判断是否有可用效劳、是否需要调整之前的效劳,是否需要新建效劳;
第三步:
更新效劳分析文档,主要记录接口分析的结果;
第四步:
编写效劳规映射文档,主要是定义效劳的输入输出信息;
第五步:
编写效劳规映射文档,记录原接口字段与效劳定义字段的映射关系〔字段转换〕;
第六步:
更新数据字典,定义全行规的词汇表;
第七步:
编写接口映射文档,记录效劳与接口的映射关系;
第八步:
发布效劳规
以下介绍每步的具体操作,并给出模板作为参考。
2.3.3接口分析
接口分析的首要工作是收集各系统的需求文档,通过需求文档,了解、熟悉系统的功能说明,以便效劳分析人员理解行业的业务容,为后续的效劳定义奠定业务根底。
否那么,在效劳定义时,会出现缺乏行业知识,导致效劳类别无法判断、效劳字段定义缺乏扩展性、对接口的调用系统缺乏敏感,不能及时发现其他系统对该接口的使用,带来效劳定义稳定性、扩展性较差的问题。
接口分析的原那么是按照使用哪个接口,对该接口进展分析的原那么。
比方,在该阶段需要集成核心系统、信贷系统、网银系统,那么对核心系统贷、网银使用的接口进展分析,其他接口暂不分析。
这样的优势是,不用花费太多的精力完成全部外围系统对核心系统的调用关系分析,可以快速构建ESB平台并上线,且给出的效劳都会被使用和验证。
缺点是当效劳定义人员缺乏经历时,往往不能发现被信贷使用的接口实现的业务功能,基金或者IC卡系统也要使用,可能使用的是功能相近的其他接口,造成定义的效劳缺乏局部字段,稳定性差,后期需要不断的调整。
接口分析是按系统收集该系统与其他系统的访问接口信息,要求各系统按照模板填写,其中包含报文格式描述〔银行一般会有固定的几种报文格式,一般由核心系统的实施商制定,其他系统相互访问也按照该格式;具有国际标准如8583、SWIFT或国行业标准如PBOC2.0那么按该对应标准执行〕,接口的功能描述、接口处理逻辑和流程,接口的输入输出字段的详细描述、使用的代码的描述、冲正或反交易的描述、异常的描述等信息。
接口收集的模板可参考如下文件,根据自身需要作调整。
获取接口文件的同时,尽可能拿到该系统的系统架构,因为在实际分析过程中可能涉及到功能实现的调整,如将前置的支付功能剥离出来,改造为支付平台实现,这也是前面提到效劳分析人员最好具有技术背景的原因,因为涉及到架构调整,需要说服相关人员调整的必要性、合理性和先进性。
另外,对需求文档中得业务背景、不清楚的局部需要跟业务人员沟通,明确具体的业务要求。
对新系统,那么需要参加该系统的分析过程,以掌握第一手资料和详细的业务信息,这些业务背景信息可能在形成的需求文档中并没有描述和表达。
2.3.4效劳识别
拿到接口文件之后,即可开场对接口进展分析,首先从已有的效劳中查看是否已有该对应效劳;假设没有,确定是否可通过效劳组合的式提供;再确认是否可通过扩展原有效劳满足该功能;假设还没有发现,那么需要新建效劳,此时,需要对效劳进展业务归类,是金融类、查询类、通用类、冲正类还是其他类别。
这其实也涉及到效劳的粒度划分问题,之前我们提到效劳设计的原那么,其中一个重要的特性是重用,除此之外,还要强调业务完整性,也就是不能依赖其他效劳才能提供完整的业务含义。
举一个例子,对公对私客户新增时,由于需要的字段信息有很多不同,假设强行定义为一个效劳,那么该效劳字段可能超过100个,且对公对私要求的字段属性如“是否必输项〞很难描述,在ESB平台进展报文有效性判断时,也需要设定大量的逻辑验证规那么〔如客户类型为对公,那么公司名称、营业执照号、注册资金、法人代表名称、注册地等不为空〕,实际使用过程中也非常不便,虽然是复用度很高,但这是无意义的复用,而可取的做法是整合各系统对客户信息的不同字段要求,整合为对公、对私客户信息维护,如整合核心系统、信贷系统〔过程可参考CIF的客户根本信息整合〕,这才是有意义的复用。
另外,比方账户交易明细查询,假设原有接口为对公一个接口、对私一个接口,此时,那么可以完全合并,因为对应的接口非常相近,完全可以整合为一个。
效劳的粒度划分非常难以掌握,也缺乏统一的标准和操作指导,经常会成为争论的焦点。
我们先看下面一段引用的文章:
Ø业务效劳如果是是否存在可重用的原子效劳,如果有那么应该先做原子效劳再做组合效劳。
Ø原子效劳存在的意义在于存在多个业务效劳复用,如果不存在不识别为原子效劳。
Ø从业务出发,为了保证事物完整性和效劳设计的无状态原那么,应该如设计,哪些能拆,哪些不能拆。
Ø根据BPEL流程编排,会增加业务校验类细粒度效劳,应从满足多个业务编排需求来考虑可重用性。
Ø根据平安性原那么,哪些效劳需要拆分,根据拆分效劳提供不同属性类别的效劳
Ø根据性能原那么,哪些粗粒度效劳当不满足性能测试要求时候需要拆分为多个细粒度的效劳
什么是效劳的颗粒度.一般的说法,效劳颗粒度〔servicegranularity〕就是指一个效劳包含的功能大小。
举个例子,对于电信九七系统中的营业受理来说,提交客户订单就是一个典型的粗粒度的效劳,而实现这个提交订单效劳的一系列部操作,比方说创立客户资料,生成客户订单,记录产品属性,更新帐务关系等等就可能成为一系列细粒度的效劳。
细粒度的效劳〔fine-grained〕提供相对较小的功能单元,或交换少量的数据。
完成复杂的业务逻辑往往需要编排大量这种细粒度的效劳,通过屡次的效劳请求交互才能实现。
相反,粗粒度的效劳〔coarse-grained〕那么是在一个抽象的接口中封装了大块的业务/技术能力,减少效劳请求交互的次数,但相应也会带来效劳实现的复杂性,交互大量的数据,并因此而不能灵活更改以适应需求的变化。
就像任事物都有两面性一样,效劳粒度不能太大或者太小,而应该大小适宜。
一个良好的SOA架构设计,必须在效劳粒度设计上维护一种平衡,以获得本钱降低,灵活响应的好处。
尽管没有一本Bible让我们可以依此正确地设计效劳的粒度,但我们还是能从与之相关的多面利弊权衡的设计实践中,总结出一些能够帮助正确选择效劳颗粒度的经历法那么。
识别并设计一个粒度适中的效劳,我们可以主要从以下三个面权衡考量。
x重用性
所谓重用性,就是指效劳能够应用于不同上下文的能力。
重用可以说是SOA的核心思维,通过重用获得降低开发维护本钱,缩短应用交付期,提升质量等种种好处。
与任基于分解的例相一致,颗粒度的大小直接影响到效劳的可重用性。
一个简单的经历法那么就是细粒度的效劳更容易被重用。
换句话说,就是颗粒度越粗,效劳越少被重用或者越难以被重用。
因为随着颗粒度增加,越来越多的业务规那么和上下文信息被嵌入到业务逻辑中,效劳逐渐变得具有特定的业务意义。
要使用它,我们必须首先了解它到底封装了哪些规那么,否那么我们无法确信这个效劳正是我们所需要的。
这并不意味着我们就不要构建粗粒度的效劳,事实上粗粒度的效劳往往还停留在〞business-grained〞层面,它让业务用户和IT人员可以直接对话,对业务有直接的意义,应该暴露出来。
同时,如果我们仅仅机械地考虑重用性,将导致大量颗粒度很小的功能单元,这将对系统整体性能和容量带来重的影响。
就拿大家常用来描绘SOA的乐高玩具为喻,一个最小尺寸的1x1的乐高积木,带有一个标准的凸起接口,通过它几乎可以与任其它乐高积木拼装出任意可以想想的物体,其广泛的重用性是不言而喻的。
但是当你真正尝试用这种粒度的积木完成一个复杂物体拼装的时候,你可能会感慨:
“Oh,MyGod!
It’smissionimpossible!
〞,因为,为此付出的时间和本钱的代价几乎是不可承受的。
因此,我们在一心希望构建美好的重用世界之前,需要先掂量清楚效劳颗粒度的选择。
x灵活性
所谓灵活性,就是能够容易地因情形做出改变的能力。
SOA的目标之一就是让IT变得更灵活,能够更快地适应持续变化的业务环境。
因此,灵活性作为设计良好的效劳的重要考量,理所当然地也是选择效劳粒度的重要标准之一。
众所知,细粒度的效劳可以更容易地组装,为交付新的业务功能或改变业务流程提供了更多的灵活性。
但是,仅仅考虑灵活性将导致大量的细粒度的效劳,带来昂贵的开发本钱,并使得维护变得困难。
因此,在考虑业务流程灵活性的同时,考虑后台效劳的良好组织、效率和开发维护本钱,对于识别和设计粒度适中的效劳是至关重要的。
我们知道,效劳识别法之一就是top-down的一级级流程分解,直到不能或者不需要进一步分解为止,其中识别出来的的业务活动就是候选的业务效劳。
因此,一个有效的经历法那么就是区别对待不同的业务流程,因为并不是每一个业务流程都需要一样的灵活性。
如确定哪些流程需要更多的灵活性,哪些流程不需要,可以参
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- ESB 项目 实施 过程