什么是企业架构
早在1987年,John Zachman就提出: “为了避免企业分崩离析,信息系统架构已经不再是一个可有可无的选择,而是企业的必需”。
从那时起,Zachman的企业架构理论就开始逐渐发展起来, 它现已成为许多大公司用来理解、表述企业信息基础设施的一个直观模型,
为企业现在的以及未来的信息基础设施建设提供了蓝图和架构。
Zachman的企业架构是一个全新的模型,为企业信息基础设施提供一种可以理解的信息表述。
Zachman没有把企业的流程简单视作一系列步骤,而是综合考虑不同角色的不同观点,提出了一个多视角、多维度的企业架构。
企业架构中的不同角色
1.企业拥有者。
2.业务管理者。
3.系统分析者。
4.系统设计者。
5.系统建设者。
6.系统本身。
下表的各行内容即反映了不同角色的不同关注点(角度)。
Zachman同时承认每个角色均关注相同的信息类别(维度),即下表各列内容。
|
数据(什么?)
|
功能(怎样?) |
网络(哪里?) |
角色(谁?) |
时间(何时?) |
动机(为何?) |
目标范围 |
列出对业务至关重要的元素 |
列出业务执行的流程 |
列出与业务运营有关的地域分布要求 |
列出对业务重要的组织部门 |
列出对业务重要的事件及时间周期 |
列出企业目标、战略 |
业务模型 |
实体关系图(包括M: M关系、N-ary关系、归因关系) |
业务流程模型(物理数据流程图) |
物流网络(节点和链接) |
基于角色的组织层次图, 包括相关技能规定、 安全保障问题。 |
业务主进度表 |
业务计划 |
信息系统模型 |
数据模型(聚合体、完全规格化) |
关键数据流程图、 应用架构 |
分布系统架构 |
人机界面架构(角色、数据、入口) |
相依关系图、数据实体生命历程(流程结构) |
业务标准模型 |
技术模型 |
数据架构(数据库中的表格列表及属性)、 遗产数据图 |
系统设计: 结构图、伪代码 |
系统架构(硬件、软件类型) |
用户界面(系统如何工作)、 安全设计 |
“控制流”图(控制结构) |
业务标准设计 |
详细展现 |
数据设计(反向规格化)、物理存储器设计 |
详细程序设计 |
网络架构 |
屏显、安全机构(不同种类数据源的开放设定) |
时间、周期定义 |
程序逻辑的角色说明 |
功能系统 |
转化后的数据 |
可执行程序 |
通信设备 |
受训的人员 |
企业业务 |
强制标准 |
企业架构的信息类别
数据(什么?)
功能(怎样?)
网络(哪里?)
时间(何时?)
角色(谁?)
动机(为何?)
企业架构理论术语
“企业”(Enterprise)是指由一整套可识别的、互为作用的业务功能构成的商业组织。 它有能力作为独立实体经营运作。
根据这一定义,就应该存在企业内的企业。 只要企业内部的事业部门能够独立运作,它或许就可以被当作一个企业。
在这里,这一企业概念也可以被看作为“扩展企业”(Extended Enterprise),它意味着企业架构框架也包括了企业与外部实体的相互关系。
例如: 供应商、商业伙伴和客户。
“架构”(Architecture)提供基础框架, 它定义和描述了企业实现经营目的和商业愿景的平台。 “架构”可以被具体定义为:
与企业经营战略、信息需求紧密相连的一整套原则、方针、政策、模型、标准以及流程,它结合企业未来发展方向,为企业各项解决方案的设计、选择和执行提供指导。
企业架构的组成
企业架构可以分为两大部分:业务架构和IT架构,大部分企业架构方法都是从IT架构发展而来的。
业务架构:是把企业的业务战略转化为日常运作的渠道,业务战略决定业务架构,它包括业务的运营模式、流程体系、组织结构、地域分布等内容
IT架构:指导IT投资和设计决策的IT框架,是建立企业信息系统的综合蓝图,包括数据架构、应用架构和技术架构三部分。
对比 RUP 和其他主要关注于实现的规程,企业架构领域原则上的关注点是企业范围内的业务需求的识别、规范,及优先级划分,感觉它也是一个做企业信息化规划的方法。我认为,做工具型产品和企业级产品有个差别,那就是做企业级产品需要由工具型产品的产品型公司向咨询类的服务型公司转型。
1. 业务流程的组织逻辑(包含所有信息和技术服务,流程)和IT基础设施,反映了该公司运作模式的整合和标准化的需求
(MIT Center for Information Systems Research)
2. 概念蓝图,定义了一个组织的结构和运作。企业架构的意图是确定组织如何能够最有效的实现其当前和未来的目的
(SearchCIO.com)
企业架构如同战略规划,可以帮助企业执行业务战略规划及IT战略规划。在业务战略方面,可使用TOGAF及其架构开发方法论(ArchitectureDevelopmentMethod/ADM)来定义企业愿景/使命,目标/目的/驱动力,组织架构,职能及角色。在IT战略方面,TOGAF及ADM详细描述了如何定义业务架构,数据架构,应用架构,和技术架构,是IT战略规划的最佳实践指引。企业架构是承接企业业务战略与
IT战略之间的桥梁与标准接口,是企业信息化规划的核心。
源于90年代美国的企业架构框架,到目前已经衍生出多种企业架构框架,如DoDAF(美国国防部体系架构框架
The Department of Defense Architecture Framework)、TOGAF等。
为什么需要企业架构[1]
有些人可能会问为什么要做要做架构,直接拿来需求就做不就行了,以前做些小任务都是这样的。就像搭个简易狗窝不需要请设计师来专门做个设计,但是建个大厦必须设计一样,我想对于不复杂的东西,你怎么做我都觉得很正常,但是一旦业务复杂、处理麻烦时,必须有一个清晰的架构才能保证做出来的东西是正确的。
中国的大多数企业在进行IT投资时都会跳过企业架构这个环节而直接进入了IT项目的建设,这要就回导致重复投资、信息孤岛等必然现象的出现。有时缺少规划,也会发现很多开发的功能被打入冷宫,这里列一个简单例子:如hr系统中的HR服务台的一个功能,我填写了一个问题,但是没有回复,估计这个功能就被打入冷宫了,这样满意度也就会下降了。
通过企业架构,我们可以达到:
企业内不同的人要对企业现状(as-is)和企业愿景(to-be)有一个整体的的理解
业务、信息、技术人员的共同愿景,是理解、沟通的基础
如果没有一个清晰的架构,就不能保证争取的决策和好的实现,EA是理解和实现企业IT建设的保障
TOGAF在国外的认知度很高,目前企业架构方法有很多,但TOGAF是最主流的,已经有超过15年的历史。不仅有80%的福布斯(
Forbes)全球排名前50的公司在使用,而且支持开放、标准的SOA参考架构。目前已得到国际主流厂商的推动,德国有SAP在推动,美国IBM、
HP、SUN等公司在推动,中国在企业架构方面并不是很成熟,以前讨论多半集中在软件架构或是单独的系统架构,在02年才有一个企业架构出现。金蝶在TOGAF
8.1成熟之后,引进9.0,因为它包含对SOA的支持,所以这个也是金蝶选择在这个时期把它导入的原因之一。金蝶加入The
Open Group,希望能够提升中国企业信息系统及业务架构的水平,并率领国内软件产业参与国际标准的制定。对金蝶而言,引进TOGAF和Open
Group的SOA参考架构及治理原则,将推动金蝶集团产品,开发过程及治理的国际化与标准化。未来金蝶ERP产品EAS、BOS及金蝶中间件等产品都将遵循TOGAF企业架构框架,架构开发方法论及SOA参考架构,以提升产品质量及全面SOA服务化。在金蝶产品获得成功后,将建议金蝶用户采Open
Group的TOGAF及SOA标准。在2009年11月份上海的金蝶年度客户大会及中国管理模式杰出奖颁奖典礼中,金蝶发布了EAS
7.0新版本,这是中国第一款使用TOGAF企业架构框架规划及SOA的ERP产品。
企业架构-架构原则[2]
架构原则
基于标准方法来做架构,如使用TOGAF架构方法
说不清的不做
没人上层持久推动的不做
达不成一致意见的不做
业务原则
业务持续性(对业务发展有长远计划,不能只考虑近期实现范围)
业务通用性(业务是否可以作为一个公用业务架构)
业务一致性
合法
数据原则
数据价值性>数据正确性>数据完整性
数据积累分析需要规范化数据
数据是安全的
数据不只是可以共享的数据,还包含业务规则和策略
应用原则
技术独立性,不绑定到特定厂商
易用
模块化设计
技术原则
响应变化
可扩展
解决方案架构、业务架构和企业架构的对比[3]
开发人员对于架构这个词一定不陌生,但是我们说的架构只是产品开发中的技术相关架构,真正要做好一个产品,在技术架构之上还有其他一些架构,本篇介绍一下三类主要的架构:解决方案架构、业务架构和企业架构。有时候我们把视野拓宽一些,多锻炼自己的大局观,对自己的思维和技能都会有很大的提高。在《TOGAF
或非 TOGAF:在 RUP 之上扩展企业架构》中对比几个不同的架构框架,让我对什么是架构更清晰了。我觉得不错,所以给大家分享一下。
解决方案架构
解决方案架构是“技术性的”,它们的范围内包括各种技术元素,如软件、数据和 IT 基础架构,这些领域都是由技术人员来处理
。
业务架构
业务架构在 90 年代作为单独的领域出现了,业务架构包含过程及信息、组织和绩效等方面内容
企业架构领域
企业架构领域原则上的关注点是企业范围内的业务需求的识别、规范,及优先级划分,EA 路线图可能比单路线解决方案包含更多内容(如上图所示),这可能会形成多个、同时的实现。
EA 环境是全局性的,其视点是组织化的,而解决方案架构是具体到实现的。EA 主要用于企业分析、计划和架构治理。
注意:来自解决方案架构规程中的一些主题(低层次的)不含在 EA 的范围内,而许多附加的(大部分是更高层次的)主题加入了。还要注意的是关键的业务架构主题完整地包含于
EA 规程之中了。
|