专栏首页智能计算时代「企业架构」VP:什么是企业架构?

「企业架构」VP:什么是企业架构?

  • 什么是企业架构?
  • 主要企业架构框架
  • 企业架构的层次
  • 为什么选择企业架构?
  • 什么是EA框架?
  • 企业架构词汇表

什么是企业架构?

企业架构(EA)通常与城镇规划或城市设计相比,是一种定义明确的实践,用于进行企业分析、设计、规划和实施,以成功地制定和执行战略。企业体系结构减少了冗余、复杂性、信息孤岛以及与IT投资相关的业务风险。因此,EA提供了一个有效IT战略的蓝图,并以一种以成本效益的方式提供业务利益的方式来指导IT的受控演进。

企业架构的实践者,企业架构师,负责对业务结构和流程进行分析,并经常被要求从收集的信息中得出结论,以实现企业架构的目标:有效性、效率、敏捷性,以及复杂业务运营的连续性。

主要企业架构框架

IT行业中不乏EA框架,Zachman是第一个将概念形式化并发布框架的人。从那时起,许多其他的EA框架已经发布并被许多组织使用。他们试图解决根据技术需求和策略(如Zachman框架、开放组架构框架(TOGAF)、NAF、DoDAF、MoDAF等)评估、调整和组织业务目标的基本挑战。每个框架都有不同的优势和劣势。

企业架构的层次

企业架构对每个组织都是独特的,但是也有一些共同的元素。自1993年Stephen Spewak的企业架构规划(EAP)以来,也许在此之前,将企业架构划分为四个架构域是正常的。

企业架构的四个普遍接受的领域是:

业务架构域-

描述企业是如何组织结构的,以及交付业务远景所需的功能性能力。业务架构解决了什么(What)和谁(Who)的问题:组织的业务远景、战略和目标是什么,它们指导业务服务或能力的创建?谁在执行定义的业务服务或功能?

应用程序架构域

-描述单个应用程序、它们的交互以及它们与组织核心业务流程的关系。应用程序架构解决了这样一个HOW问题:如何实现先前定义的业务服务或功能?

数据架构域

-描述组织的逻辑和物理数据资产以及数据管理资源的结构。通过数据分析了解您的客户,您可以改进并不断改进业务流程。

技术架构域

-描述实现业务、数据和应用程序服务所需的软件和硬件。这些域中的每一个都有众所周知的工件、图表和实践。

为什么选择企业架构?

企业架构的范围包括:企业的人员、业务流程、信息和技术,以及它们之间和外部环境之间的关系。企业架构(Enterprise architecture)应用架构原则和实践,通过这些架构域(业务、信息、流程和技术)的对齐来指导组织。这涉及到利用企业的各个方面,通过执行以下操作来识别、激励和实现这些更改:

  • 业务和技术协调
  • 联合环境中的一致性
  • 互操作性和信息共享
  • 投资回报率
  • 灵活性(Flexibility)和敏捷性(agility)

什么是EA框架?

架构(Architecture)框架建立了在应用程序或涉众社区的特定领域中创建、解释、分析和使用架构描述(视图和视点)的通用实践。它是企业架构描述内容的一种结构,根据IEEE 1471的定义,我们可以将EA框架描述为如下所示的模型:

利用企业架构框架可以简化在所有层(如企业架构、功能性业务部门架构、跨领域技术领域架构和解决方案架构)创建和维护架构的过程,并使组织能够最好地利用架构的价值实践。

企业架构框架提供了最佳实践、标准、工具、流程和模板的集合,以帮助创建企业架构和各种范围的架构。企业架构框架通常包括:

  • 常用词汇、模型和分类法
  • 过程、原则、策略和工具
  • 参考体系结构和模型
  • 规范性指导(EA过程、架构内容、实现路线图、治理)
  • 架构交付物和工件目录
  • 企业架构内容元模型

企业架构词汇表

  • 地址-查看解决问题
  • 敏捷——一种规划和指导项目过程的迭代方法。
  • 应用程序架构(Architecture)–将应用程序的结构和交互描述为提供关键业务功能和管理数据资产的功能组。
  • 应用程序组合管理——用于管理软件资产的规程,以证明和衡量每个应用程序相对于应用程序维护和操作成本的财务效益。
  • 架构(Architecture)–根据组件、组件之间的关系和环境来组织系统。
  • 架构描述(Architecture Description)–架构描述(Architecture Description)是用于表示某个感兴趣系统的架构的工作产品。该标准规定了对AD的要求。AD描述了系统的一种可能的架构。AD可以采取文档、模型集、模型库或其他形式(标准未定义AD格式)。
  • 架构(Architecture)原则——架构(Architecture)应满足的一种定性意图声明。至少有支持性的理由和重要程度。
  • 业务架构——对业务策略、组织、功能、业务流程和信息需求之间的结构和交互的描述。
  • 业务架构框架——业务蓝图、业务场景和业务架构知识库如何相互关联的概念视图,为建立业务架构提供了基础。
  • 业务能力——组织履行核心职能所需的能力、材料和专业知识的表达或表达。在我们的最终商业能力指南中了解更多!
  • 业务能力建模——一种表示组织业务锚定模型的技术,独立于组织的结构、流程、人员或域。学习如何在4个步骤中开始业务能力建模!
  • 业务能力路线图-能力路线图是一个计划,描述了一系列可行的、仔细界定范围的计划,以及为实现业务目标而应采取这些计划的顺序和估计时间表。通常以文档或架构模型的形式交付,描述业务能力的现状,以及在未来一段时间内计划的更改。请阅读我们关于业务能力的白皮书。
  • 业务能力分类法——业务能力分类法是业务能力的有序层次结构,其结构方式对涉众有意义,并用于在能力和业务单元之间创建关联。
  • 业务目标——目标是关于通过适当的手段将要实现或维持的企业状态或状况的陈述。一个目标放大了一个愿景,也就是说,它表明了什么必须在持续的基础上得到满足,才能有效地实现愿景。
  • 业务信息模型——一个说明组成业务文档的数据元素之间的分组和关系的模型。
  • 业务模型——业务模型描述了组织如何创造、交付和获取价值的基本原理。阅读这里的案例研究。
  • 商业政策-正式记录管理期望和意图。政策用于指导决策,并确保流程、标准、角色、活动、IT基础设施等的一致和适当的开发和实施。
  • 业务流程–一种事件驱动的端到端处理路径,从客户请求开始,到客户结果结束。业务流程通常跨越部门甚至组织边界。
  • 业务服务——通过显式定义的接口支持业务功能,并由组织显式管理。
  • 能力——一个组织、个人或系统所拥有的能力。能力通常用一般和高级术语表示,通常需要组织、人员、过程和技术的组合才能实现。
  • 变更管理——对系统组件的开发、推出和维护的自动化支持(即智能再生、包版本控制、状态控制、库控制、配置管理、移交管理和分布式影响敏感度报告)。
  • 云转换–将数据、应用程序或其他业务元素从组织的现场计算机移动到云,或将它们从一个云环境移动到另一个云环境的过程。请阅读我们的白皮书“企业架构如何为云铺平道路”。
  • 关注点-关注点是对系统的任何兴趣。这一术语源自埃德加·迪杰克斯特拉(Edsgar Dijkstra)最初创造的“关注点分离”一词。关注点示例:(系统)目的、功能、结构、行为、成本、可支持性、安全性、互操作性。
  • 数据对象-反映有关重要业务项的信息。这可能是帐户、员工或组织类型的数据。数据对象概况表可以链接到应用程序和接口,并存储有关数据敏感性的其他信息。当您希望管理数据敏感性或管理业务信息的一致性时,可以很好地使用数据对象。
  • 数字转换——从模拟形式转变为数字形式的过程,也称为数字实现。换言之,数字化需要一个模拟过程,并将其转换为数字形式,而过程本身没有任何不同的实物变化。请阅读我们的白皮书“数字化转型:精益企业架构管理案例”。
  • 企业架构(Enterprise Architecture)–通过识别和分析朝着期望的业务愿景和结果执行的变更,主动、全面地领导企业应对破坏性力量的规程。EA通过向业务和IT领导人提供针对调整策略和项目的签名建议来实现价值,从而实现利用相关业务中断的目标业务成果。
  • 企业信息架构(Enterprise Information Architecture)——企业架构过程的一部分,通过一组需求、原则和模型描述当前状态、未来状态以及灵活共享和交换信息资产以实现有效企业变革所需的指导。
  • 企业原则——企业决策的基础。这些原则通常被认为是协调整个组织决策的一种手段。尤其是,它们是成功的架构治理策略中的一个关键元素。
  • 环境——系统存在的环境或环境,包括社会、商业和技术方面。
  • 框架——描述特定应用领域和/或利益相关者社区内建立的架构的惯例、原则和实践。
  • 信息架构(Information Architecture)–一组规则,用于确定信息将被收集、存储、处理、传输、呈现和使用的内容、方式和位置。在互联网上,信息架构是指如何组织网站内容,并将其呈现给用户,以便于导航和搜索功能。
  • 看板——精益制造(即准时制)环境中使用的技术,通过管理流程来缩短流程周期时间。在这里学习敏捷、看板和Scrum之间的区别。
  • 关键绩效指标(KPI)–反映流程或特征的高级指标,通常在业务领导人的记分卡上进行衡量。
  • 精益——提供有效解决方案的集中方法,包括消耗最少的资源。
  • 模型-视图由架构模型组成。每个模型都是根据其模型类型(通常定义为其控制视图的一部分)建立的约定构造的。模型提供了在视图之间共享细节以及在视图中使用多个符号的方法。
  • 模型类型——模型类型定义了一种架构模型的约定。目的系统的目的是相关利益相关者关注的问题。
  • 项目组合管理——根据组织的战略目标和交付能力,对组织的项目和计划进行选择、优先排序和控制。在我们的权威指南中学习所有您需要了解的关于投资组合管理的知识。
  • 产品生命周期管理-软件支持的一种哲学、过程和规程,用于在产品生命周期的各个阶段(从概念到退役)对产品进行管理。作为一门学科,它已经从机械设计和工程的重点发展到应用于许多不同的垂直行业产品开发挑战。
  • 项目——为实现特定的业务成果,创造独特的产品、服务或成果而进行的临时努力。一个项目可以与一个项目中密切相关的项目排序或分组。每个项目都有一个生命周期,通常包括特定的项目阶段:启动、计划、执行和结束。
  • 质量保证-在服务或产品中保持期望的质量水平,特别是通过关注交付或生产过程的每个阶段。
  • 资源——完成一项活动所需的经济或生产要素,或作为开展一项企业并实现预期结果的手段。最基本的三种资源是土地、劳动力和资本;其他资源包括能源、企业家精神、信息、专业知识、管理和时间。
  • 风险-业务模型评估的要素之一,风险是一种对组织的潜在影响,应视为业务判断的一部分。业务模型评估由一个或多个业务判断组成,并将视角放在所评估的一个或多个模型上。
  • Scrum——一个项目管理框架,强调团队合作、责任制和朝着明确目标的迭代过程。
  • 服务水平协议(Service Level Agreement,SLA)–服务水平协议是两个业务单元之间签订的合同,其中一个业务单元向另一个业务单元提供服务。该合同描述了衡量服务提供商业绩的具体措施,以及消费者认为可以接受的这些措施的可接受范围。
  • 面向服务架构(Service Oriented Architecture,SOA)–一种帮助IT满足业务需求的设计范式和规程。一些组织使用SOA实现了显著的好处,包括更快的上市时间、更低的成本、更好的应用程序一致性和更高的灵活性。SOA减少了冗余,提高了可用性、可维护性和价值。这产生了可互操作的模块化系统,更易于使用和维护。SOA创建了更简单、更快的系统,提高了灵活性并降低了总体拥有成本(TCO)。
  • 软件即解决方案(SaaS)–由一个或多个提供商远程拥有、交付和管理的软件。提供商提供基于一组通用代码和数据定义的软件,这些代码和数据定义在一对多模型中由所有签约客户在任何时候以按需付费的方式使用,或作为基于使用指标的订阅使用。
  • 解决方案体系结构—特定解决方案的体系结构描述。解决方案架构结合了来自不同企业架构视角(业务、信息和技术)以及来自企业解决方案架构的指导。
  • 利益相关者——利益相关者是对利益体系持有关注的个人、团体或组织。利益相关者示例:客户、所有者、用户、消费者、供应商、设计师、维护者、审计师、CEO、认证机构、架构师。
  • 工作说明书(SOW):一个目标部分,允许客户强调要达到的期望的最终状态或性能指标。它还要求对每个任务订单的过去性能、技术方法和成本进行评估。客户确定每个标准的相对重要性。
  • 供应链管理:创造和满足商品和服务需求的过程。它包括一个贸易伙伴社区,致力于满足最终客户的共同目标。
  • 技术参考模型-对标准、规范和技术进行分类的基础,以支持在组件或面向服务架构中使用和使用的业务和应用组件(服务组件)的构建、交付和交换。
  • 技术过时-一项技术或产品停止使用、生产或兼容的时间和状态。
  • 技术风险-任何可能导致技术故障而中断业务的可能性,如信息安全事件或服务中断。在我们的权威指南中学习所有您需要了解的技术风险管理知识!
  • 总体拥有成本(TCO)–对信息技术(IT)或其他跨企业边界的成本随时间变化的综合评估。对于IT部门,TCO包括硬件和软件采购、管理和支持、通信、最终用户费用以及停机、培训和其他生产力损失的机会成本。
  • 价值主张——商业模式的核心概念,价值主张描述了企业如何通过其活动为消费者或市场增加价值。价值主张将客户需求、所需能力、收入模式和业务伙伴关系的概念结合在一起。它是从目标客户的角度出发的一种陈述,告诉每个人“为什么”企业的产品和服务是有价值的。
  • 价值流——业务流程的序列,其边界通常由业务事务定义。它们表示端到端的序列,如“订单到现金”或“想法到可用产品”。
  • 视图-AD中的架构视图从一个或多个利益相关者的角度来表达感兴趣系统的架构,以使用由其视图建立的约定来解决特定的关注点。架构视图由一个或多个架构模型组成。
  • 视点-架构视点是一组用于构造、解释、使用和分析一种类型的架构视图的约定。视点包括模型类型、视点语言和符号、建模方法和分析技术,以构建一组特定的关注点。视点示例:操作、系统、技术、逻辑、部署、过程、信息。
  • 面向Web架构(WOA)–利用Web架构的面向服务架构(SOA)的子样式。它通过五个基本的通用接口约束强调接口(用户接口和api)的通用性:资源标识(例如,统一资源标识[URI])、通过表示(例如,HTTP)对资源的操作、自描述性消息(例如,多用途因特网消息传递扩展[MIME]类型),超媒体作为应用状态(如链接)和应用中立性的引擎。

原文:https://www.visual-paradigm.com/guide/enterprise-architecture/what-is-enterprise-architecture/

本文:http://jiagoushi.pro/what-enterprise-architecture

本文分享自微信公众号 - 首席架构师智库(jiagoushipro),作者:南极真君

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-05-07

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 「企业架构」企业架构框架图

    企业架构框架图是架构的分类方案(治理架构,业务架构,信息架构,技术架构,人力资本架构,安全架构,系统架构,软件架构,基础架构架构等)及其重要工件。企业架构框架可...

    首席架构师智库
  • 「演进架构」架构在实施之前是抽象的

    这是一个思想实验。拿一台计算机,在其上安装主流操作系统,以及各种软件(数据库,应用程序服务器,Web服务器等)。一切正常后,拔下电脑并将其放入壁橱中一年。在这一...

    首席架构师智库
  • 「敏捷模型」敏捷架构:规模化敏捷开发的策略

    与流行的看法相反,架构是敏捷软件开发工作的一个重要方面,就像传统的工作一样,并且是扩展敏捷方法以满足现代组织的现实需求的关键部分。但是,敏捷专家的架构方式与传统...

    首席架构师智库
  • 「企业架构」企业架构框架图

    企业架构框架图是架构的分类方案(治理架构,业务架构,信息架构,技术架构,人力资本架构,安全架构,系统架构,软件架构,基础架构架构等)及其重要工件。企业架构框架可...

    首席架构师智库
  • 小钢的架构思考:什么是架构

    最近在思考架构方面一些最基本的问题,比如什么是架构?如何评价一个架构的好坏?是否有一些通用的基本原则指引架构设计?在面向对象设计方面,有单一职责、里氏替换、依赖...

    Keegan小钢
  • 什么才是真正的架构设计?

    在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前,我们先讨论架构的概念定义,概...

    xcbeyond
  • 架构设计《一》谈谈架构

    https://blog.csdn.net/hguisu/article/details/78258430

    搜云库技术团队
  • 跳出“误区”,学着如何打造“最好的架构”。

    “架构”是我们这行业种一个很常见的词,表明其必然也是经历了很长的岁月打磨所形成的一个词。架构的这个词出现的意义是什么?为了解决什么问题?只有把这2个问题想明白了...

    Java架构技术
  • 工作多年,我对架构的一些理解

    每一个程序员都听过架构这个词,每一个程序员都有自己对此的理解和看法,本文分享我对架构的理解。

    Frank909
  • 架构如何为业务和技术“服务”(1)

    前言 为提升架构对于项目,产品的贡献度,更好的服务于业务和技术,本文将探讨架构的现状和规划未来架构的目标。 在讨论架构、业务、技术的问题前,请耐心的阅读完本文有...

    用户1177503

扫码关注云+社区

领取腾讯云代金券