企业架构模型

《企业架构模型》由会员分享，可在线阅读，更多相关《企业架构模型（63页珍藏版）》请在金锄头文库上搜索。

1、企业信息化与企业架构模型 课程体系结构 企业信息化目标企业信息化目标 企业模型架构企业模型架构IT的作用的作用 软件系统的核心要素软件系统体系架构软件系统变革动力 软件系统模板体系项目管理核心要素项目过程管理与控制 可行性分析解决方案分析需求工程模型分析设计方法 系统构造与实现实施与上线系统维护与优化系统测试 引子 内容 第一节: 企业信息化 第二节: 企业信息架构模型 企业信息架构发展与概念 Zachman模型 其它架构模型 Capgemini的集成架构框架 微软企业架构 第三节: IT技术在企业信息化中的作用 第四节: 企业信息化的趋势与方向 “Enterprise architectur

2、e will never realize a return on investment” Gartner (June 2005) “A simple argument for Enterprise Architecture: every organisation needs it to survive.” “Organisations survive, even prosper, without an EA” Zachman (2001) Neil Lynch 成功的企业是“架构”出来的，而不是自由 发展而成的。战略决定做正确的事，业务架 构决定正确、高效地做事。企业架构是一个 涵盖业务和IT

3、的全面的企业蓝图设计工具， 它可以帮助企业的管理者了解企业的构成和 运营，发现问题并不断地改进。 很多大型企业中存在IT与业务各自为政的问 题，研究结果表明，IT架构的优化可以为企 业带来2%的业务增长；业务架构的优化可以 带来8%的增长；而如果业务和IT能够相互支 持，企业达到总体优化的话，则可以带来 20%的增长。可见，企业需要改变以往业务 和IT脱节的设计方法，通过使用总体架构的 理念可以达到1+12的效果。 SOA需从企业架构开始做起需从企业架构开始做起 http:/ 详细 1、为什么提出企业体系架构 为什么会提出企业架构？为什么会提出企业架构？ 随着随着IT应用的深入，应用的深入，I

4、T与业务的关联越来越紧密：与业务的关联越来越紧密： 市场变化对响应速度的要求越来越快市场变化对响应速度的要求越来越快: 业务复杂度越来越高业务复杂度越来越高 业务与IT间的鸿沟 适应变革的灵活性差 技术体系复杂混乱 技术标准不兼容 技术系统互操作性差 系统安全性脆弱 IT系统管理不规范 IT建设 缺乏从 组织角 度出发 的总体总体 架构规 划和设 计。 如何建立贯彻业务战略的如何建立贯彻业务战略的IT战略战略 和和IT体系？体系？ 如何实现如何实现IT系统的灵活性和互操系统的灵活性和互操 作性，以更快地响应业务需求？作性，以更快地响应业务需求？ 如何降低如何降低IT投资和运营成本，并投资和运营

5、成本，并 且从且从IT投资中获取更多回报？投资中获取更多回报？ 如何管理如何管理IT结构的复杂性？结构的复杂性？ 企业架构的目标：企业架构的目标： 能在对业务战略和流程理解的基础上，进行信息化顶层设计，形成灵活 稳健的IT结构，构建和谐的IT环境。 GARTNER: What does your EA program include? 69.3 % Technical Architecture 52.6% Security Architecture 71.7 % Business Architecture 36.8% Data Architecture 18.4% Process Archit

6、ecture 55.3% Architecture Program Management 44.7% Enterprise Architecture Consulting 15.8% Enterprise Performance Management 57.9% Project Management 现实中的IT问题与EA(一) 问题一：业务战略与技术鸿沟 症状：受业务战略驱动的IT技术 基础设施的规划和配置失败。 解决方案： 体系结构化方法提供了业务战略 与技术实现的连接，该方法在业 务和技术规划之间平滑连接，从 而通过具体的和战略的业务衡量 标准推动技术环境的发展。 利用技术体系架构开发和

7、维护方 法，保证业务需求在技术环境规 划与开发方面具有可描述性。 现实中的IT问题与EA(二) 问题二：信息不准确、不完整 症状：根据IT战略规划建立的业务系统无法保证业务所需 信息的准确性和完整性。 客户抱怨自己的信息没有得到及时更新； 某个系统中的信息在另外一个系统中以不同的样式显示出来； 管理信息似乎不能表达出实际的业务状态； 从外部资料来源得到的信息导致不正确输出； 随着组织业务系统的发展，业务支撑功能的添加、改进和更换， 会出现很多变化。系统的变化，必然会导致信息的不准确和不完 整，而且，由于低效的跨系统集成也加剧了这些问题。 解决方案：从较高层次上描述信息体系结构和业务系统， 确定

8、哪些功能是可重叠的，哪些可分割的，哪些领域是可 集成的，从而解决信息、方案、技术重叠和系统间的集成 问题,并为建立有效技术集成环境提供框架。 现实中的IT问题与EA(三) 问题三：基础架构错误 症状：基础技术的提供及构建方式限制了IT技术的整体运 作能力。 组织内部可以讨论是采用开发还是购买的方式获得所需要的应用 系统，但却较少地对支撑应用系统的基础架构进行分析讨论，对 基础架构往往不够重视，或不为其提供必要的资源。 由于基础架构很难证明会获得有形的效益，所以预算和采购很难 向基础架构直接投资。 基础架构被损坏了，应用程序/系统之间的互操作性也弱化了，从 而导致对业务过程的支持不足。 解决方案

9、： 在体系结构化方法中，基础架构被认为是技术体系架构中的重点。 要想构建能够很好支持业务过程的应用系统，必须从整体上统筹 规划所需的基础架构。 症状：许多组织不能确保自己组织的IT环境是可靠的。 不同信息系统需不同的身份认证机制 管理层要求信息系统能够通过网络互联 技术与业务脱节 内部安全管理机制不健全 现实中的IT问题与EA(四) 问题四：安全性： 解决方案： 信息系统的战略规划指明了宏观技术体系结构的方向。 技术体系架构通过规划，规定了组织对当前和未来的安全性要求。 在技术体系架构规划中安全性问题是其重点 ，可在宏观规划的指导 下，进行具体的安全性规划，给出如何在具体的技术开发中增强安 全

10、性的方法。 信息安全 安全政策安全标准安全步骤 安全职责 安全监督 安全调查 安全责任 安全建议 安全部门 应用系统安全 应用截面 软件工具 接受测试 变更管理 安全研发 信息分级 分级标签 安全存储 安全销毁 安全获取 信息档案 网络安全 地址管理 入口控制 网络监测 安全通道 无线网络 实体安全保护 外围控制 环境安全 硬件安全 文件安全 外围监测 业务连续与灾难恢复 关键档案 连续计划 连续测试 紧急方案 应急备份 安全审计与测试 安全审计 攻击测试 整改方案 长期审计 定期测试 身份认证与系统准入 身份认证 系统准入 事故调查 事故报告 安全监测 人员安全 安全职责 事故报告 调查协助

11、 安全知识 安全操作 现实中的IT问题与EA(五) 问题五：技术兼容性 症状：IT环境存在多个不同的技术平台，不能进行有效 的互操作，导致不能对业务过程提供有效支持。 解决方案：使用技术体系架构规划解决IT环境的互操作 问题。 业务伙伴业务伙伴 验证验证 订单订单 信用信用 检查检查 分配分配 库存库存 安排安排 发货发货 发货发货 订单订单 报单报单 客户客户 更新更新 服务服务 信用信用 (ASP)部件部件 (VMI)后勤后勤 (3PL) CRMERP采购采购SCM账户账户 内部应用内部应用 业务流程业务流程 SiebelSAP本地生成i2CICS 实时信息 数据可视化数据可视化 例外处理

12、 工作流工作流 呼叫中心呼叫中心 销售销售 客户客户 网站网站 客户客户 Web 服务器服务器 门户门户 服务器服务器 应用开发应用开发 应用测试应用测试 应用部署应用部署 门户开发门户开发 应用开发应用开发 Web 服务 EDIebXML 数据中心数据中心 硬件硬件 基础结构管理基础结构管理 服务服务 现实中的IT问题与EA(六) 问题六：问题六：IT成本难控制 症状：症状：对组织的IT成本控制效率低下或不清楚成本控制。 类型类型1: 往往按照竞争优势的收益考虑采用新技术的风险，它们早在新 技术被认为稳定或商品化之前就采用了该技术，并尽可能地发掘对业 务具有决定性作用的技术。在现实中，只有很

13、少组织属于该类型。 类型类型2: 关注所采用技术的整体价值。在某些领域它们具有创新性，而 在另一些领域就显示了保守性。它们倾向于当技术成为主流时再采用。 这种类型的组织占据了大多数。 类型类型3: 关注IT驱动业务所带来的成本效益。它们一般在等到技术商品 化后才采用相关技术，并且在技术使用前进行详细的成本效益分析。 解决方案：解决方案： 技术体系架构要求了解组织类型并采用合理的方法构建能够反映成本控制 的模型。大多数组织关于其IT支出存在着分歧，对IT成本的理解取决于组 织的性质、组织关于技术驱动业务的观点、组织的业务战略及其对IT支出 的历史处理方式。 要解决要解决IT成本控制问题，首先要确

14、定组织类型。成本控制问题，首先要确定组织类型。 Cisco example 小结: 技术体系架构并不仅仅是一套 标准，确切讲，它是一种组织 能力的体现，这种能力不仅体 现在文档方面，还反映了技术 专家、IT管理员、规划设计人 员以及实施人员的知识与经验。 体系架构通常会建立一个共有 的远景，然而，简单地设定远 景是远远不够的，必须和构建 人员、客户和其他相关人员进 行沟通以达成共识，在构建过 程中要维护该体系架构。它在 一个横跨于客户需求、构建人 员的要求以及客观世界约束的 沟壑之间架构了一座桥梁。 2、企业体系架构发展与概念 企业架构的发展历程企业架构的发展历程(1)： 企业架构的雏形来自企

15、业建模的理论和思想 20C 80S中期，John Zachman首先引入“信息系统架构 框架”的概念。（IPNPTP + SCLPCF） 1989年美国国家技术标准研究所发布NIST框架 1996年美国的Clinger-Cohen 法案=“IT架构” 1999年9月，美国联邦CIO委员会出版了联邦企业架构框 架（FEAF） EA Origin John Zachman Mr. Zachman focused on architecture since 1970. His 1st article and the original framework was published in 1987 (“A Framework for Information Systems Architecture,” IBM Systems Journal, vol. 26(3), 1987. http:/ 63/ibmsj2603E.pdf ). In 1992 John Zachman and John Sowa wrote another article (“Extending and Formalizing the Framework for Information Systems Architectu