从需求工程的角度来看：业务架构、企业架构、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资讯，请访问中培教育官网：中培教育