再谈业务架构

标签: IT咨询 | 发表时间:2013-08-28 20:12 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
要注意业务架构是一个完整的概念,是有多个架构文档,形式化的图形建模共同完成的。只要是企业内涉及到业务的方方面面,人,事,物,时间,环境等都可以在业务架构描述中找到详细的内容或者其父内容。业务架构不等同于流程架构,流程架构是业务架构的一个部分;业务架构不等同于业务建模,业务建模仅仅是形成业务架构的一种方法;采用形式化的方法清晰的描述清楚企业业务即业务架构要完成的事情。

业务架构的形式可以以价值链或端到端的流程分析为切入点,组织结构和岗位角色建模是业务架构的一个基础内容,在此基础上围绕流程和数据两条线相互交互融合而展开,流程涉及到子流程,业务活动和业务操作;数据涉及到数据域,数据主题和分类,具体数据的概念模型和逻辑模型等。或者可以简单的说为刚开始是基于价值链分析,端到端流程的高端流程建模;在流程分解到一定程度后进入到业务用例分析和建模,业务对象分析和建模。

在流程建模过程中,特别是到分解后的下级流程,仍然是推荐采用EPC事件流程链的方法进行建模。EPC流程图包含了流程活动,事件,岗位角色,业务对象等多个内容并形成一个整体。更加方面对企业内业务流程中的各个关联事物进行全面的理解。所以整个流程建模的思路可以是高端价值链-》传统的职能带流程图-》EPC流程图。

在前面这些过程或活动中,可以形成大量的输出文档和目录清单,包括了流程清单,每个流程的详细活动描述清单(活动,输入,输出,业务对象,岗位角色),业务功能或活动清单,组织信息清单,岗位和角色信息清单,业务对象详细描述清单等。如果仅仅是端到端流程分析来输出,那么这个清单不完整,因为有些业务功能或活动不在端到端流程上面,比如一些业务部门的日常例行管理工作,监控工作,统计分析工作等。这也是业务架构不能单纯的从顶向下完成的原因,为了弥补这个问题,还需要的就是对于企业内的各个业务部门进行业务调研和访谈,了解各个业务部门的业务目标,各个业务岗位的业务职责和工作内容,进一步识别出不在端到端流程和流程分解节点上的内容。由顶向下+由底向上才可能形成一个完整的业务架构需要的内容。

如果仅仅是上述这些内容,那还不是一个完整的业务架构,在ARIS流程建模或TOGAF中都没有专门提到CBM组件化业务模型,这实际是基于SOA的思路做业务架构的一个很关键的内容。业务组件化,组件能力化和服务化。业务组件是企业内部一个高内聚的能够完成核心的一个业务价值的业务能力单元,这个业务组件将以业务服务的方式朝外部提供服务能力。因此各个业务组件之间本身就应该是高内聚,松耦合的。

一个业务组件可以是代表一个业务域,一个业务单元,一个紧耦合的多个业务流程或业务功能的集合,企业价值链或某个业务全生命周期的某一个阶段等。业务组件构成一个完整的业务架构模型,该业务架构模型本身也可以逐层展开和细化。业务架构本身分层,包括IBM的CBM模型的分法(决策,管理,执行层),也可以参考价值链的分层思路(支撑层,核心价值层,决策层)等。

在进行企业架构建模的时候,应该分为哪些大的业务组件,或者说哪些业务功能应该放在一个业务组件里面以保证组件之间能够高效协同是业务架构建模必须关注的问题。在业务架构建模的过程中,特别是对于目标业务架构完全可以参考企业所属于的行业的涉及到的标准模型进行重构和完善,如供应链的SCOR模型,电信行业的eTom模型等。我们在构造这个业务架构图的时候一直强调的就是高内聚松耦合的思路,符合业界的相关参考模型和标准,但是实际执行的时候究竟该遵循什么思路?

在这里一个可行的思路仍然是回归到矩阵分析,这里涉及到矩阵分析比较多,一个个的说明:

业务组件交互矩阵:在该矩阵上横向和竖向都是业务组件,在内容单元格里面是具体的业务交互接口点,通过这个交互矩阵分析是可以全局的看到当前的业务组件划分是否会导致大量的业务接口存在。并分析每个业务接口产生的原因,以进行组件的合并,业务组件中业务功能的转移等。(后续应用集成架构分析的输入)

数据和业务交互矩阵:在该矩阵图上,横向具体的业务组件和业务功能,纵向是具体的业务对象,在内部是具体的CRUD信息,也即是传统的CRUD矩阵分析。在该矩阵分析中的重点是,对于同一个业务对象,CUD操作尽量减少分离,而读操作则可以共享。以减少业务对象数据的多头管理和维护。将统一业务表单和数据的维护尽量控制在同一个业务大组件中完成。减少数据间的交互和传递。

流程交互分析矩阵:在该矩阵上面横向是具体的流程信息,纵向是具体的流程活动信息,在这个矩阵图上可以看到同一个流程活动或流程片段往往存在于多个不同的流程。该分析的重要作用是对流程建模中可复用的流程片段或流程活动进行抽象和分析。(SOA服务建模时候需要)

功能业务组件分析矩阵:
在该矩阵上横向是具体的业务组件或模块,纵向是具体的业务功能,在该交互分析上重点是分析具体的可复用的业务功能,以对可复用的业务功能进一步进行抽取,形成可复用的服务。(SOA服务建模时候需要)

本文作为TOGAF业务架构各个产出工件形成和交互关系的一个补充,具体TOGAF的业务架构建模很多仍然是停留在标准方法论基础上,而没有具体的操作性指南。反而是类似联邦企业架构FEA给出了些可以更方便实践操作的方法和案例。

  青春就应该这样绽放   游戏测试:三国时期谁是你最好的兄弟!!   你不得不信的星座秘密

相关 [业务 架构] 推荐:

再谈企业架构-业务架构

- - 人月神话的BLOG
前面已经谈到过企业架构的层次和维度方面的问题,在这里简单谈下企业架构中的业务架构和业务价值链方面的内容. 随着企业不断的发展和演进,各个业务功能单元会逐步成熟,也会形成多个端到端的流程,这些流程涉及到工程项目管理,供应链,财务,人力资源,产品研发等多个方面的内容. 我们再进行高端业务架构建模的时候采用的方法也基本是参考业界标准的价值链模型进行展开.

再谈业务架构

- - 人月神话的BLOG
要注意业务架构是一个完整的概念,是有多个架构文档,形式化的图形建模共同完成的. 只要是企业内涉及到业务的方方面面,人,事,物,时间,环境等都可以在业务架构描述中找到详细的内容或者其父内容. 业务架构不等同于流程架构,流程架构是业务架构的一个部分;业务架构不等同于业务建模,业务建模仅仅是形成业务架构的一种方法;采用形式化的方法清晰的描述清楚企业业务即业务架构要完成的事情.

业务架构、信息架构、技术架构三位一体

- -
        客户天天打电话要修改产品功能,简单的一个需求可能要做一个月. 产品越改越笨重,为了赶工期bug越来越多.         产品从初级版到现在已经四个年头,相关的程序员来去换了三批,在补丁上打补丁是常有的事,很多功能只是开了个头,换个项目经理就被遗忘. 我们总是害怕客户在这个产品上提出新的需求,只要客户还用得过去,能不改就不改.

架构 - 业务流程管理介绍(BPM)

- - 博客园_知识库
  最近公司准备采用外部的开发平台,其中就有BPM厂商. 以前也看过一些BPM相关的资料,为了加深对BPM的理解,本篇我将对以前对BPM的理解进行一个简要的整理,也希望能给大家一个参考.   维基百科中说,业务流程是为特定的对象(客户) 创造价值的过程,这一过程由一系列 相关联、有组织的 活动或任务组成.

MySQL 高可用架构在业务层面的分析研究

- - CSDN博客数据库推荐文章
相对于传统行业的相对服务时间9x9x6或者9x12x5,因为互联网电子商务以及互联网游戏的实时性,所以服务要求7*24小时,业务架构不管是应用还是数据库,都需要容灾互备,在mysql的体系中,最好通过在最开始阶段的数据库架构阶段来实现容灾系统. 所以这里从业务宏观角度阐述下mysql 架构的方方面面.

微服务架构-数据中台和业务中台(3.27)

- - 人月神话的BLOG
首先我们看下阿里巴巴Aliware团队对企业中台的定义. 即企业中台是由业务中台和数据中台构建起数据闭环的运营体系,实现以数字化资产的形态构建企业核心差异化竞争力. 在原来我谈企业中台的时候,很少专门谈到数据中台和业务中台,更多谈的是技术中台和业务中台,技术中台类似我们原来说的技术平台层和业务不相关.

有赞保险业务的分析与架构设计

- - 有赞技术团队
有赞微商城为商家提供了全行业全场景的电商解决方案,帮助商家在社交电商、直播电商等场景下快速布局. 在整个交易流程中,对退货时运费减免的支持已成为了电商场景的标配. 有赞也提供了 “退货包运费” 产品来满足消费者及商家在此场景下的诉求. 本文从“退货包运费”这个产品出发,分析保险业务的特征,介绍有赞保险业务系统的架构设计.

业务分析师和业务架构师角色的对比引发热烈争论

- - InfoQ cn
Nick Malik是微软的企业架构师,他最近写了一篇 博客,讲述了业务分析师和业务架构师的区别,而且很快就有人批评他的立场. Malik力主:业务分析师与业务架构师的工作有本质上的不同. 但是国际业务分析师协会(International Institute of Business Analysts,简称IIBA)的Kevin Brennen 强烈反对,并指出这两种角色的相似之处.

小米架构再调整:成立软件与体验部、互联网业务部、业务中台部

- - 雷锋网
雷锋网消息,12月18日,小米集团进行了新一轮组织架构调整,成立软件与体验部、互联网业务部、业务中台部三大部门. 据悉,新成立的三个部门资源整合涉及此前五个互联网部门,以及电视、笔记本、带屏音箱、小米移动、大数据和云平台等业务,并分别由金凡、马骥、仇睿恒为三大部门总经理,直接向CEO雷军汇报. 此前,小米在2018年9月13日进行架构调整,并成立了十个新业务部,形成了支撑小米随后业务发展的基本企业架构.

指数级增长背后,滴滴出行业务系统的架构升级

- - 运维派
成立四年,估值已超260亿美元,公司指数级发展、业务爆炸式增长,在此背景下,滴滴出行业务系统的架构升级是怎样进行的. 本文根据滴滴出行平台产品中心技术总监——杜欢在2016ArchSummit全球架构师(深圳)峰会上的演讲整理而成. 杜欢,滴滴平台产品中心技术总监. 2015年加入滴滴,负责公司公共业务、客户端/前端架构和新业务孵化,致力于用技术手段解决业务痛点和提升研发效率,曾作为技术负责人主导公司技术架构升级以支撑公司业务快速迭代的需求.