企业架构,业务架构,数据架构

我们将核心价值链上的端到端总结为两个核心,其一是供应链的端到端流程和业务;其二是产品研发的端到端和业务。各个企业由于类型不同往往对两条价值链各有 侧重。生产代工类企业没有自己的产品研发,那么只有供应链;高科技研发企业可以做到卖产品核心技术和专利,不做具体供应链方面事情。而更多的生产制造型企 业往往是1和2两者的一个有机结合。

再谈企业架构和业务架构:

企业架构本身强调的是业务驱动IT,业务和IT的匹配和融合而不是两张皮,在这里可以看到核心我们关注的点包括流程,活动,数据,组织,资源五个方面的内容。而每个方面基本都涉及到业务和IT两个方面的内容,包括业务到IT的转化和映射。

企业架构-分层和维度:

完整的企业架构包括了业务架构和信息系统架构两个方面的内容。

企业架构是一个多视图的体系结构,它由企业的业务架构、信息架构、应用架构和技术基础架构共 同构成。传统的Zachman企业架构框架更多的仍然是偏业务流程和数据,没有体现的特别清楚业务和IT的关系。而对于TOGAF框架,则是真正体现了业 务驱动IT,业务和IT的紧密集成,特别是提出了架构的三个层次,包括业务架构,信息系统架构和数据架构。而信息系统架构又包括了应用架构和数据架构。

业务流程和业务架构:

根据TOGAF方法论,在业务愿景建立后重要的一步就是展开业务架构方面的工作。 业务架构的核心仍然是业务流程架构,从业务流程架构的分析中如果关注业务活动的分析则衍生出业务用例模型,如果关注业务数据的分析,则衍生出业务数据架构。

再谈业务架构:

对于业务架构,仍然推荐大家下载IBM的CBM组件化业务模型白皮书,在网上很容易搜索到。对于业务的理解和分析仍然可以看到两条重要的主线,即业务流程 分析和业务架构分析,两者紧密结合。流程分析一般参考价值链分析的思路,由顶向下,逐层分解进行;而业务架构分析则更多的还是要依托流程分析,将流程分析 识别和发现的业务活动,识别和抽象为相应的业务组件。

CBM组件化业务模型:

对于企业架构思想融入到软件架构中,即真正对软件架构层面的工作进一步整合,减少在系统分析过程中从现实业务层面来抽象IT层面的脱节。改变传统软件架构仅仅考虑实现层面和技术层面的问题。对于引入方法和具体内容,还是从软件架构的一些核心内容来谈。

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

信息化架构一般有两种模式,一种是数据导向架构,一种是流程导向架构。对于数据导向架构重点是在数据中心,BI商业智能等建设中使用较多,关注数据模型和 数据质量;对于流程导向架构,SOA本身就是关键方法和技术,关注端到端流程整合,架构对流程变化的适应度。两种架构并没有严格的边界,而是相互配合和补 充。

信息化架构模式:

IT规划和IT咨询

 
对于IT规划,遵循的思路主要是:从业务到技术,从流程到IT,围绕价值链分析和优化的核心模型往前驱动。核心过程包括现状分析、差距分析、目标提出、蓝 图规划、实施规划等几个关键步骤。现状分析包括业务现状和IT现状,根据企业战略提出业务目标和发展规划,分析现状和目标之间的差距提出和整理问题集(定 义IT建设目标),根据差距和问题给出规划蓝图,根据目标和问题分解到的子目标和子问题以及蓝图规划内容,多维度评估和确定后续的实施规划,定义IT系统 建设实施的优先级。这就是IT规划的一般逻辑。

IT规划核心分析逻辑-整理稿:
再谈IT规划分析的核心逻辑:
 
首先看下业务架构映射到基于云计算的业务模式和流程,首先业务架构重点是业务流程和业务组件,是为后续识别应用架构和数据架构服务的,重点还是业务。云计算偏技术层面,即使是基于云计算的运营也是偏技术层面的内容而非真正地业务,偏运营业务模式和流程的分析eTom模型给出了很好的思路,可以参考下eTom的模型,其本身才能和云计算本身的分层高度吻合

以TOGAF为指导的云计算规划:

首先来看纵向,为电信运营商的完整生命周期。如果是传统的制造型企业其对应的是核心价值链模型,前面来看都类似即战略,规划,产品,产品后对应到具体的交付和后续售后服务环境。对于运营型企业,产品即服务,用户要的不是产品而是产品提供的能力,因此对运营层面进行细化,包括了运营支撑,实施,保障和计费。以构成电信运营商完整的生命周期。

再转过来看eTom的过程框架,横向为供应链,资源,服务,产品四层。可以讲整个过程框架的精髓不在于纵向生命周期,纵向生命周期仅仅是价值链分析方法的 而一个延伸。而在于横向的分层,解耦和逐层递进关系上。底层的供应链为最底层的基础设施支撑层,最终形成的是价值维度的资产。

对eTOM过程框架的再认识:

对于架构分析的入口点,仍然推荐是从端到端流程分析入手,细化到业务域的端到端,再细化到3,4级流程,最终细化到EPC最底层流程图。流程到子流程,再到业务活动,业务活动中承载的是业务单据和业务实体。需要对业务实体进行抽离,进行数据层面的数据建模和分析。从ARIS企业架构分析中的Y模型可以看到,Y模型的左边为业务架构,右边为流程架构,而最底层够归集到EPC流程。整个分析顺序为端到端流程分析到EPC,结合数据建模和分析,通过CRUD矩阵分析等方法从底向上抽象业务组件形成高端业务架构。

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

整个IT规划始终围绕业务和IT两条主线,业务包括了业务流程,业务数据,岗位组织和角色,业务管控体系;而IT包括了应用架构体系,数据架构和模型,技 术架构和平台,基础设施建设。业务驱动IT,端到端业务流程最终落地到应用系统的功能上,业务数据最终沉淀到数据库中的数据模型,我们谈SOA重点也是业 务驱动IT,业务和IT走向融合,业务架构和应用架构本身就为一体,特别是业务组件的提出;而数据架构本身从传统的概念模型,逻辑模型,物理模型本身就是 业务数据和信息数据的融合和统一。

谈IT规划的思考逻辑:

对于IT咨询主要涉及到信息技术,业务,管理三方面的知识。企业架构给了我们比较好的IT咨询知识体系结构,业务流程,数据,系统,组织和人。方法,工具和技术。无论是从企业价值链分析,还是从各种行业的标准业务模型和数据标准模型,最终都会落到以上内容。

IT咨询-随想记录:

参考业界IT规划的参考模型和框架,结合IT规划方法论和实施,重新整理了IT规划知识体系。对于横轴主要考虑IT规划的方法论和步骤,具体包括了参考模 型,调研阶段,差异分析和匹配,目标架构,实施策略和管控治理六个方面的内容;对于纵轴包括了IT基础设施,业务基础设施,业务流程,数据,技术体系,应 用系统,集成架构七个方面的内容。

IT规划知识体系整理:

流程架构是基础之基础,流程是分解的,最高端的流程视图不会太体现流程,更多体现的是价值链思路。数据架构偏静态,从核心数据实体的角度进行建模。数据实体应该从EPC中进行抽取。高端应用架构和高端的流程视图对应。体现流程驱动IT,但是匹配和对应关系比较复杂。

IT架构规划:

流程驱动IT规划包含两个层面的内容。从理论层面来说,引入企业架构管理(EAM)思想,建立以业务流程为核心的架构体系,通过对架构体系的研究实现 企业IT规划;从技术层面上来说,此方案是由ARIS软件工具(流程管理平台)构成的; 应用ARIS流程模型化方法,实现企业流程的模型化管理,建立企业的IT战略,企业组织,IT基础架构和IT管理过程的模型化。通过模型关系的研究实现企 业的IT的“动态”有效规划。流程驱动IT规划在以下几个方面都具有较大的优势,笔者将逐一进行探讨。

流程驱动的IT有效动态规划:

企事业IT架构是由数据架构、应用架构和技术架构共同构成的。其中,数据架构是企事业IT架构的核心,因为信息系统支撑下的企事业业务运作状况,是通过信 息系统中的数据反映出来的,数据是信息系统管理的重要资源。因此构建企事业IT架构时,首先要考虑数据架构对当前业务的支持。理想的企事业IT架构规划逻 辑是数据驱动的,即:首先根据业务架构分析定义数据架构;然后根据数据架构结合业务功能定义应用架构;最后根据数据架构与数据架构的定义,来设计技术架 构。

IT规划-数据是核心的核心:

如果说到智慧企业,那么简单点还是在企业内部各种信息能够全面快速的收集,信息能够高度共享和协同传递,能够对信息进行知识管理层面的加工创造,形成有价 值的专家经验库,指导后续的持续改进。企业本身在智慧架构和信息技术下能够高度的自适应和自调整,达到高度协同和快速响应,以高效的满足企业的各种业务目 标并实现价值。具体还是从可感知,可协同和可智能三个方面来谈智慧企业。

谈智慧企业:

企业2.0本身融合传统web2.0和SNS核心思想,企业2.0本身融合web3.0的核心思想,企业2.0本身就是无边界和融合的思想,企业2.0真正将知识管理融入到企业业务目标。

再谈企业2.0的核心逻辑:

可以说方法论的形成必须做两个层面的抽象,一个是对实际问题的抽象,一个是对解决方法的抽象,这样才能够让方法论具有较为普遍的适用性。但是我们注意到当在追求普遍适应性的时候,不可避免的牺牲了特定适用性。方法论是类,而最佳实践是对象。最佳实践是针对特定的问题,采用方法论中提到的特定方法工具技术的结合,是对方法论的一个实践验证。

方法论和最佳实践:

时间: 2024-10-29 10:46:35

企业架构,业务架构,数据架构的相关文章

企业架构:现代数据架构的特征

企业数据架构,很多朋友在尚未了解时总会将它定义为组织用于管理数据的一组标准产品和工具,但它的性质远不止于此.数据架构定义了捕获.转换以及向业务用户提供可使用数据的过程,最重要的是它也确定了使用该数据的人及其独特要求. 欣思博根据现代数据架构的特征进行总结,并为正在开发适应当前时代要求的新型数据架构的组织提供指导. 1. 以顾客我中心 现代数据架构不是专注于提取.摄取.转换和呈现信息所需的数据或技术,而是从业务用户及其需求开始向后流动.客户可以是组织的内部或外部,他们的需求因角色.部门和时间而异.

什么样的基础设施适合快速和大数据架构?

为大数据和较新的快速数据架构提供基础设施并不是一个饼干切割的问题.两者对硬件和软件基础设施都有着显著的调整或改变. 较新的快速的数据架构与大数据架构有着显著区别,并且快速数据提供了真正的联机事务处理工具.理解大数据和快速数据需求的变化能够帮助你做出正确的硬件和 软件选择. 大数据架构 相比企业在以往通常收集数据的方法,大数据是通过更大的数据容量,分析和获得更大的洞见的过程,大部分的数据(例如,社会媒体有关客户的数据)是可访问的 公共云.这一数据,反过来,强调快速访问,不再强调一致性,也造就了如H

微服务开发中的数据架构设计

本文来自作者 陈伟荣 在 GitChat 分享的文章[微服务开发中的数据架构设计] 前言 微服务是当前非常流行的技术框架,通过服务的小型化.原子化以及分布式架构的弹性伸缩和高可用性,可以实现业务之间的松耦合.业务的灵活调整组合以及系统的高可用性.为业务创新和业务持续提供了一个良好的基础平台.本文分享在这种技术架构下的数据架构的设计思想以及设计要点,本文包括下面若干内容. 微服务技术框架中的多层数据架构设计 数据架构设计中的要点 要点1:数据易用性 要点2:主.副数据及数据解耦 要点3:分库分表

大数据架构的典型方法和方式

大量的IT组织如今都已自己的数据架构,因为都依赖于传统的数据架构.处理多数据源已不再新鲜:这些架构已经连接了多维度的数据源例如 CRM 系统,文件系统和其他商用系统.主要运行的关系型数据库有 Oracle, DB2和Microsoft SQL. 如今,一般的数据分析周期是运行一些周期性脚本直接从数据库提取和处理数据.这些主要由 ETL工具如 Informatica 或者 Talend. 目标是将这些提炼的数据加载到数据仓库用于将来的分析. 不幸的是,这一方法在周期结束后可能不适合商务的需要了.这

系统架构师-基础到企业应用架构-业务逻辑层

一.上章回顾 上章我们主要讲述了系统设计规范与原则中的具体原则与规范及如何实现满足规范的设计,我们也讲述了通过分离功能点的方式来实现,而在软件开发过程中的具 体实现方式简单的分为面向过程与面向对象的开发方式,而目前更多的是面向对象的开发设计方式.并且我们也讲述了该如何通过设计手段去分析功能点及设计分离 点,应该如何在设计的过程中分析的角度及如何去满足设计规范与原则.首先我们通过下图来回顾下上章要点: 二.摘要 本文将已架构的方式去分析分层结构中的业务层的设计,如何写出来内聚度,高耦合的业务逻辑层

传统企业IT架构如何能更好的支撑企业互联网业务的转型

阿里巴巴董事局主席马云在2016年11月16号在乌镇召开的第三届世界互联网大会开幕式上发表演讲时提出了以下观点: "最近两百年三次技术革命,每次技术革命的周期都是大约50年,而且有一个规律,前20年是技术研发的革命,新技术层出不穷,一批批涌现:后30年进入技术应用期,新技术开始和传统产业相结合,新产业不断出现,真正影响生活方方面面." "今天互联网刚好走过20年,未来的30年,是人类最关键,最需要重视,最需要把握的30年.是新技术融合到传统行业的方方面面,是人类社会天翻地覆的

大数据架构和模式(一)——大数据分类和架构简介

概述 大数据可通过许多方式来存储.获取.处理和分析.每个大数据来源都有不同的特征,包括数据的频率.量.速度.类型和真实性.处理并存储大数据时,会涉及到更多维度,比如治理.安全性和策略.选择一种架构并构建合适的大数据解决方案极具挑战,因为需要考虑非常多的因素. 这个 “大数据架构和模式” 系列提供了一种结构化和基于模式的方法来简化定义完整的大数据架构的任务.因为评估一个业务场景是否存在大数据问题很重要,所以我们包含了一些线索来帮助确定哪些业务问题适合采用大数据解决方案. 从分类大数据到选择大数据解

大数据架构和模式(三)——理解大数据解决方案的架构层

摘要:大数据解决方案的逻辑层可以帮助定义和分类各个必要的组件,大数据解决方案需要使用这些组件来满足给定业务案例的功能性和非功能性需求.这些逻辑层列出了大数据解决方案的关键组件,包括从各种数据源获取数据的位置,以及向需要洞察的流程.设备和人员提供业务洞察所需的分析. 概述 这个 “大数据架构和模式” 系列的 第 2 部分 介绍了一种评估大数据解决方案可行性的基于维度的方法.如果您已经使用上一篇文章中的问题和提示分析了自己的情况,并且已经决定开始构建新的(或更新现有的)大数据解决方案,那么下一步就是

大数据架构和模式(二)——如何知道一个大数据解决方案是否适合您的组织

简介 在确定投资大数据解决方案之前,评估可用于分析的数据:通过分析这些数据而获得的洞察:以及可用于定义.设计.创建和部署大数据平台的资源.询问正确的问题是一个不错的起点.使用本文中的问题将指导您完成调查.答案将揭示该数据和您尝试解决的问题的更多特征. 尽管组织一般情况对需要分析的数据类型有一些模糊的理解,但具体的细节很可能并不清晰.毕竟,数据可能具有之前未发现的模式的关键,一旦识别了一种模式,对额外分析的需求就会变得很明显.要帮助揭示这些未知的未知信息,首先需要实现一些基本用例,在此过程中,可以