学习交流

从需求工程的角度来看:业务架构、企业架构、IT项目实施

2017-08-18 11:42:21 | 来源:中培企业IT培训网
概要:提到TOGAF-ADM 大家的焦点通常会关注三个A上:BA-Business ArchitectureISA-Information System Architecture(Data Architecture,application Architecture)TA-Technology Architecture但是从ADM图上我们分析一下,它的核心是RM(Requirement Management),同时所有节点(除了Preliminary)都与RM具有双向箭头。因此,从这个角度来看,如果我们转换一下思路,以需求管理的角度来理解并运作EA方法,会得到意想不到的效果。为此,中培的谢老师借鉴BPM的BPA和IBM的CBM方法,结合面向对象的设计方法(组件化设计、设计模式)、DDD(领域驱动设计)等方法重新构建了一套EA业务架构模型,用来指导EA业务架构的实践。并在某些业务域的实践得到了比较好的效果。限于篇幅和某些信息比较敏感,部分涉及实际业务内容的图片进行了处理,只能看清轮廓。因此这里只从方法角度来讲解,关键是思路。本分分层五个部分:1、不同上下文的业务架构2、TOGAF ADM 与需求管理3、EA业务架构框架的设计思路4、从业务流程分析到业务组件的识别与定义5、利用EA业务架构框架的实践案例--领域应用规划简介一、不同上下文的业务架构:业务架构在不同上下文中具有不同的含义,本文关注的是企业架构上下文中的业务架构。二、TOGAF ADM 和需求管理提到TOGAF-ADM 大家的焦点通常会关注三个A上:BA-Business ArchitectureISA-Information System Architecture(Data Architecture,application Architecture)TA-Technology Architecture但是从ADM图上我们分析一下,它的核心是RM(Requirement Management),同时所有节点(除了Preliminary)都与RM具有双向箭头。因此,从这个角度来看,如果我们转换中心,以需求管理的角度来理解并运作EA方法,会得到意想不到的效果。---------------------------------------------------------------------------------------------------------------谢老师将TOGAF的ADM放平【并用中文术语描述】,并将需求分解为两类:业务需求、系统需求,从而形成下面的简图。【注意“预备”阶段没有放在下图中】方法集合中有两块:1、面向业务需求管理&企业架构部分--本文讲述2、面向系统需求管理&软件架构部分---不再本文讲述借助这张简图,我们重新按照需求工程的角度来对运用架构方法对需求进行管理。限于篇幅只用BA和ISA(AA/DA)来做一个介绍。三、EA业务架构框架的设计思路EA的业务架构的有三个主要目标:在理解整体业务需求之后,将业务需求进行结构化,从而形成良好可管理的结构,从而为ADM后续的阶段提供支持。同时在EA业务架构阶段建立IT应用系统与业务功能的关系,形成整体性的管理。让应用系统的规划和开发能够承接下去。很多公司中业务域不一定有业务架构模型,或者有也不一定比较适合作为信息系统架构的输入,因此需要构建一个适合信息系统架构的需求结构,从而比较容易转换为系统设计的输入。我们来看一下,业务域业务架构的常用方法:BPM流派的业务流程架构(BPA、ARIS)、IBM-CBM。这两种方法各有优缺点。其实这两种方法有很多相通部分,IBM-CBM方法也是从BPM推导过来的。只不过国内运用IBM-CBM方法的产出通常只有一张CBM地图,通常没有业务组件的下一个层级的具体描述。银行业的CBM是质量最好的,这得益于IBM在银行业大量的项目实践。其他行业也有,但是效果就不如银行业的CBM了。那么如何达成EA的业务架构的有三个主要目标呢? 谢老师借鉴BPM的BPA和IBM的CBM方法,结合组件/SOA的设计方法和DDD-领域驱动设计的方法重新构建了一套EA业务架构模型,用来指导EA业务架构的实践。目前在一个业务域的实践得到了比较好的效果。注意谢老师借用了组件化设计思想,但业务组件地图没有采用IBM CBM的横纵的分类框架,而是采用BPM经常采用的分类【管理、执行、赋能(将“支持”改为赋能)】谢老师的整个设计思想来自与下图,这个模型是谢老师提及次数最多的一个模型。主要策略:1、将要处理业务组织作为一个系统来设计。将业务组织、合作伙伴、客户看做一个SoS【System of System】2、利用BPM的流程分析方法【端到端流程/价值流、业务场景等】去识别需要哪些业务组件。--这样将整体的业务需求归纳到业务组件里,形成整体的需求管理。注意:--这里端到端流/价值流的分析,目的是从组织的对外创造价值(提供产品/服务给客户)的过程中识别所需的资源,从而作为业务组件分类的一个重要输入。--从目标管理来看,端到端流程/价值流的分析非常重要,它为组织提供了目标管理的依据,或者说这是组织作为整体存在的价值所在。--但是端到端流/价值流分析得到的业务功能仅仅占组织全部业务功能的一部分,而大部分业务功能不直接参与端到端流程/价值流。--通过识别业务组件,我们将要处理的业务组件的业务功能全部归纳到业务组件里。--从面向服务的角度来看业务组件提供的业务功能为价值流提供服务。 -- 分析中有两个重要部分:业务功能、业务信息---是信息系统需求的最重要内容。3、定义业务组件结构,重点是关注将哪些业务功能和业务信息归纳到业务组件中去;同时将组织元素和应用系统元素关联到业务组件。-----解决IT系统与业务的关联分析。4、业务组件的业务功能继续分解则得到低阶的业务流程,这级的业务流程活动通常与系统开发用例识别有非常紧密的关系;----从中导出系统功能需求。5、业务组件的业务信息的定义和数据项的定义,则是系统数据模型的重要需求输入。---从中导出系统数据需求。数据治理项目、主数据项目都可以从这个获得重要输入,或者说已经为数据类型项目提供了高阶主题域设计。EA业务架构模型EA业务组件结构【这个结构其实是ARIS房式结构的变种】四、从业务流程分析到业务组件的识别与定义这部分是整个EA业务架构部分最难的部分。难点在于:因为这里需要很强的业务领域的知识,充分理解业务的实际运作。同时由于是对整个业务域进行设计,因此需要相关理论知识的补充,比如管理学、组织设计、运营管理、行业实践方面的知识将有助于设计出比较好的架构。这些多为MBA课程或者为行业协会知识。谢老师把他在三个领域(市场、研发、供应链)的实践过程做了一个归纳供大家参考。我们可以按照TOGAF中企业连续体的方法来进行。要点有三个部分:1、、充分学习研究并理解业务的运作,并转化为高阶流程分析框架从而指导EA业务架构的设计。比如,APQC、SCOR、ITIL、汽车研发的VDP流程框架等。这类框架不是直接拿过来用的,很多是供设计参考的。首先学习这类流程框架时,你要读懂它的结构,或者说它是如何设计的,细节反倒不是重点。举个例子,比如整车厂物流运作,我们首先需要理解整个计划的层级以及关联关系,从可以构造一个整体的流程分析框架,获得整体的信息流要点。2、利用分析模式来进行设计。针对对不同的业务特点谢老师整理几个流程分析模式,指导实践的业务建模工作。这两年谢老师整理和设计了6个流程分析模型,比如:面向客户服务型流程的分析模式、面向计划驱动型流程分析模式等等。从实践来看,通过流程分析模式的运用,可以避免在沉浸在大量细节上分析的时间,而且可以获得较好的分析结果。3、多维度分析并能够贯通五、利用EA业务架构框架的实践案例--领域应用规划简介最后通过一个我们实践的一个案例,简介一下如何运用上述方法对一个业务域进行IT 应用系统规划。1、通过业务分析构建业务组件---业务组件地图模型展示2、识别和定义业务组件中的细节内容:业务功能、业务信息、信息服务、应用及数据的整体关联性---业务组件模型从而管理整体的业务功能需求和业务信息需求,这两部分最终派生出系统功能需求和数据需求。注意,应用规划只需第三层的业务功能和业务信息,以及整体的价值流及流程场景的分析作为输入就可以了。第四层的业务流程不需要在此展开。一个组件示例:3、将领域的所有业务信息进行整体管理---业务信息地图模型展示这部分可以作为数据治理项目、主数据项目、数据仓库项目的重要输入。【不在本文阐述】4、通过分析每个业务组件的所需的应用,结合技术架构的来确定最终的应用规划。----应用系统蓝图5、根据业务的战略优先级、组织能力、组织资源的投入进行实施和迁移规划。

想了解更多IT资讯,请访问中培伟业官网:中培伟业

标签: TOGAF-ADM

猜你喜欢