企业架构-分析的核心思路

标签: 随笔文章 | 发表时间:2012-04-27 14:38 | 作者:人月神话
分享到:
出处:http://blog.sina.com.cn/cmmi


对于架构分析的入口点,仍然推荐是从端到端流程分析入手,细化到业务域的端到端,再细化到3,4级流程,最终细化到EPC最底层流程图。EPC流程图既是流程,本身也是业务功能。还有一条线可能是直接从业务活动收集和组合入手,如根据业务部门,岗位角色划分,从组织架构和岗位职责直接收集业务功能点。第一种方法既看到面又看到点,从上到下;而第二种方法则是容易只看到点,仍然无法贯彻整个企业端到端流程。

要注意流程分析并不一定能够涵盖所有的业务功能点,因为有些业务功能本身就是最底层的EPC流程,往往并不是从高端的端到端流程分解而来的。如用章管理是一个业务功能和EPC流程,但是并不一定能够挂接到高端流程上面。这也是端到端流程分析要注意点,高端流程分析和分解是建立全局思维,但是仍然要借助第二种方法收集完整的业务和活动。

流程到子流程,再到业务活动,业务活动中承载的是业务单据和业务实体。需要对业务实体进行抽离,进行数据层面的数据建模和分析。分析在流程各个阶段和活动中产生的业务实体之间的关联和依赖关系。业务域对应到数据域和数据分类,EPC层面可以分析到具体的概念模型或逻辑模型。流程分析偏业务操作和事件,而数据又正式业务操作的对象。SOA中强调操作和数据解耦,刚好是分析的两个维度。

业务架构中的业务组件划分特别强调的是业务本身的高内聚和松耦合原则。对于任何一个业务域基本有两种类型,一种是数据驱动型,一种是工单任务型。如资源,资产,合同管理等。这些是核心数据对象,业务操作层面重点是对数据对象实现全生命周期管理。因此业务组件划分基本遵循底层为基础数据支撑层,上层为生命周期管理层,覆盖该数据对象的核心生命周期阶段。这是业务组件划分的一个基本思路。

对于业务架构的构建,特别是我们对某个业务域往往并没有深入的理解前,最好的方式就是流程驱动分析,抽离数据进行数据建模,然后进行CRUD矩阵分析,分析数据和业务功能的关系。对底层的业务功能进行组合满足高内聚松耦合的原则,然后从底向上的对细粒度的业务功能进行组合,形成高内聚的业务组件。当然在整个过程中往往我们会参考业界标准的业务架构参考模型,如供应链的scor模型,电信行业的etom模型等。

从ARIS企业架构分析中的Y模型可以看到,Y模型的左边为业务架构,右边为流程架构,而最底层够归集到EPC流程。整个分析顺序为端到端流程分析到EPC,结合数据建模和分析,通过CRUD矩阵分析等方法从底向上抽象业务组件形成高端业务架构。

业务架构完成后转应用架构相对简单,业务架构和应用架构基本来说是对应的。其中较大的差别点在于业务架构只关注业务,业务本身分为功能性需求,非功能性需求。非功能性需要中包括了平台层面的支撑需求,即应用的集成支撑和数据的集成支撑,公共平台层功能等。另外还包括了存技术层面的非功能性需求。对于前者需要体现到应用架构中我们往往会技术支撑平台和应用支撑平台,技术支撑平台包括了安全,管控等;而应用支撑包含了数据平台,集成平台和流程平台等。应用架构一般会分为支撑层,应用层和决策层。其中的应用层基本可以做到和业务架构一一映射。

应用架构完成后再来考虑集成架构,而集成架构需要考虑的是业务系统间的具体的集成点。这个集成点的分析我们期望的将端到端流程,结合应用架构中的业务系统,CRUD矩阵分析形成跨业务系统的跨系统交互流程图。这种流程图已经不是纯粹业务层面的流程图,而是做系统交互分析的跨系统交互流程图。所有的跨系统交互点则为流程驱动下的业务集成点。而CRUD矩阵分析则帮助我们分析出数据驱动的数据集成点。前者为业务服务为主,而后者即以数据服务为主。两周在分析完备后最终都体现到应用集成架构中。

业务中的平台级和非功能性需求转化到应用架构中的底层支撑层,对底层支撑层中的核心技术进行抽取,最终转化到一个完整的技术架构。技术架构和业务无关,提供的是底层技术支撑层能力。在我们经常的产品规划中也可以看到产品,平台和技术必须分离。产品和平台都会提出相关的技术需求,技术架构为上层提供完整支撑。

技术架构逐步转化到公共的平台层,提供核心的资源池能力。业务组件本身转化为能力单元,业务组件由平台资源承载,提供业务服务能力。业务服务最终又可以通过的灵活的配置形成完整的业务应用。因此我们所说的解耦不仅仅是业务组件间的横向解耦。还包括了业务组件到底层平台,业务组件到上层应用间的纵向解耦。

相关 [企业架构 分析 核心] 推荐:

企业架构-分析的核心思路

- - 人月神话的BLOG
对于架构分析的入口点,仍然推荐是从端到端流程分析入手,细化到业务域的端到端,再细化到3,4级流程,最终细化到EPC最底层流程图. EPC流程图既是流程,本身也是业务功能. 还有一条线可能是直接从业务活动收集和组合入手,如根据业务部门,岗位角色划分,从组织架构和岗位职责直接收集业务功能点. 第一种方法既看到面又看到点,从上到下;而第二种方法则是容易只看到点,仍然无法贯彻整个企业端到端流程.

再谈企业架构

- - 人月神话的BLOG
本篇为杂谈,谈下最近关于企业架构的一些思考. 对于企业架构有很多定义,简单来说的话可以说企业架构包括了三个方面的内容,一个是业务的现状和建模,一个是IT的现状和建模,还有就是业务和IT的匹配. 业务重点是流程和数据,IT的重点是应用和技术. 所有的企业架构基本都包括了这三个方面的内容,只是前面增加了企业愿景和业务目标驱动,后面增加了可落地的实施策略和计划.

企业架构-分层和维度

- - 人月神话的BLOG
在企业架构思考中,价值链一定是一个核心的维度,价值链展开包括核心的企业业务线条,如包括内部,外部物流,产品研发,生产制造,市场,销售,售后等核心业务价值链,也包括人力,财务,综合,安全等支持业务线条. 在从业务到IT转换过程中,一般涉及到概念,逻辑,物理三个阶段,也是从业务规划到建设实施落地的过程,这个也是我们在分析核心的架构域的时候必须考虑的内容,包括业务,应用,数据各个方面基本都会涉及到这三个方面的内容.

再谈企业架构-业务架构

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

企业架构和IT规划咨询

- - 人月神话的BLOG
企业架构,业务架构,数据架构. 我们将核心价值链上的端到端总结为两个核心,其一是供应链的端到端流程和业务;其二是产品研发的端到端和业务. 各个企业由于类型不同往往对两条价值链各有 侧重. 生产代工类企业没有自己的产品研发,那么只有供应链;高科技研发企业可以做到卖产品核心技术和专利,不做具体供应链方面事情.

企业架构-应用架构构图

- - 人月神话的BLOG
在这里要谈的是在传统的企业架构-应用架构的基础上进一步体现SOA和企业私有云平台的思想,而非传统意义上简单的原有企业各个业务系统功能架构的堆砌. 这个思想包括两个方面的内容,一个是集中化和平台化,一个是SOA服务化和业务能力组件化. 对于该构图模式考虑两种,首先第一种是充分考虑平台层独立和平台层能力的体现:.

谈企业架构和SOA的融合

- - 人月神话的BLOG
本篇讲主要强调下在常规的企业架构规划和顶层设计中与SOA规划设计之间的融合. 再次强调下SOA的核心思想是解耦,在首先满足解耦的要求下实现共享,协同和复用. 一个完整的业务系统被拆分了应用,服务和资源层能力三个方面的内容. 资源层的能力最终以粗粒度的服务方式暴露出来,应用的构建需要大部分的借助于共享服务层抽取和接入的各种服务能力.

文章: 为什么企业架构如此重要?

- - InfoQ cn
【编者按】企业架构之道是InfoQ中文站新推出的一个专栏,旨在分享技术社区中企业架构的各种挑战、解决方案、案例研究等. Sybase在线课堂:ASE15.7——SYBASE数据管理的革新(12月21日 下午). 保持业务与信息技术(Information Technology,IT)对齐是今天所有组织面临的一项基本挑战.

Java数字抽奖游戏核心代码及分析

- - BlogJava_首页
最近,正在看《core java 8th》这本书. 自己按照书上作者一段代码的思想,自己动手写了一个小代码,深刻的感觉到作者Horstmann超高的代码思想. 《core java 8th》真的确实是一本好书,值得慢慢品读,会给人带来无穷的惊喜. 自己写的代码与注释如下,废话不多说,上代码.  * 一个简单的数字彩票游戏类 .

企业架构思想在软件架构设计中的引入

- - 人月神话的BLOG
很多时候我们在谈企业架构的时候都是正对跨流程,跨业务和跨应用系统的总体规划和分析,企业架构核心好处就是真正体现业务驱动IT,将业务和IT能够真正的匹配起来思考整个企业层面的架构问题. 而很多时候我们谈软件架构的时候仅从软件实现层面来考虑问题,针对一个业务系统的开发,我们有业务建模和软件架构,但是这两个却进行了分离而缺少了系统性的思考,所以原来我们喜欢用系统分析师这个词来综合业务分析师和软件架构师两个岗位的工作.