作为中台倡导者，百度如何利用“搜索中台”实现月级别孵化新产品

https://www.infoq.cn/article/tlB*k1aXYfXMpMhJEpIA

白话中台战略（一）：中台是个什么鬼？

https://www.infoq.cn/article/cG-DHodbHjRcv92W6tYh

白话中台战略（二）：中台到底长啥样？

https://www.infoq.cn/article/I_QyoXJO0KFBWoKmNXuK

白话中台战略（三）：中台的定义

https://www.infoq.cn/article/Mh_Qmji7w0R4lB9ETFAA

白话中台战略（四）：从互联网巨头变阵看中台战略

https://www.infoq.cn/article/Izi6-VLssZlkrj4b3uLh

 

中台之上（一）：重视业务架构，不要让“业务的归业务、技术的归技术”

https://www.infoq.cn/article/Cs*cvPvLbhpuEBzUhqaY

中台之上（二）：为什么业务架构存在 20 多年，技术人员还觉得它有点虚？

https://www.infoq.cn/article/th-QkbHEr82MaxS9BMof

 

这些流行和新兴的 EA 工具为企业提供了支持企业架构和数字化转型所需的一切。

企业架构系统并不总是必不可少的。 据推测，在 1940 年代，国际商业机器公司的一位领导人小托马斯·沃森 (Thomas Watson Jr.) 曾说过：“我认为大约有 5 台计算机的全球市场。” 没有人需要定制软件来跟踪这么短的列表。

然而，现代企业则大不相同。 一些员工仅在他们的办公桌上就有超过五台计算机。 即使是小型组织也可能拥有数千台机器； 有些人可以轻松拥有超过一百万。 那是在考虑构成物联网的传感器和智能设备之前。 企业架构 (EA) 系统跟踪所有这些机器和在其上运行的软件——更不用说这些软件层如何交互了。 因此，EA 工具是管理这些新兴虚拟世界的唯一真实来源。

EA 工具市场状况

EA 市场很强大，有几十个严肃的竞争对手。有些专门研究特定平台或云。其他提供与商业智能和业务流程管理软件的更深层次的集成。有些开始时是通用建模软件；其他的则是专门为企业架构而构建的。所有这些都编译一长串机器，并提供各种表格和图形仪表板来跟踪它们。

EA 系统以多种方式收集设备和软件信息。最手动的过程涉及要求利益相关者和开发人员填写表格，详细说明谁拥有什么机器。最自动化的工具直接登录到公司的云端，计算机器本身。大多数使用这些方法的混合。有些提供拖放小部件，以便开发人员、架构师和管理人员可以创建所有机器、这些机器运行的软件以及数据如何从一台机器流向另一台机器的模型。

从 CIO 到快速响应团队的每个人都可以使用 EA 仪表板中的图表来查找流程并跟踪数据流。有些人想注意坏机器或过载的管道。他们可以通过跟踪一连串的故障来修复问题。其他人则希望通过寻找瓶颈或捷径来规划未来。所有人都依赖系统中的数据作为快速决策的跳板。

许多工具使用 ArchiMate，这是一种开放式建模标准，旨在捕捉企业架构的大部分复杂性。它旨在与 TOGAF 开放框架密切合作。视图和可视化的创建方式类似于 UML（统一建模语言），这是另一种可视化设计的通用方法。

一个重要的考虑因素是与本地堆栈中软件类型的集成级别。所有 EA 工具都支持可以从特定云或操作系统收集数据的大量模块，但有些工具比其他工具更好地支持各种云和操作系统。有些人专注于计算世界的特定角落。

为您的办公室选择最佳解决方案意味着查看与您的特定堆栈的集成量，然后权衡软件生成的图表和表格的有用性。以下按字母顺序概述了当今可用的顶级企业架构平台。

18 大企业架构工具

• Ardoq
• Atoll Group SAMU
• Avolution Abacus
• BOC Group ADOIT
• BiZZdesign HoriZZon
• Capsifi
• Clausmark Bee360
• EAS
• LeanIX Enterprise Architecture Suite
• Mega Hopex
• Orbus Software iServer
• Planview Enterprise One
• QualiWare Enterprise Architecture
• Quest Erwin Evolve
• Software AG Alfabet
• Sparx
• Unicom System Architect
• ValueBlue Blue Dolphin

Ardoq

Ardoq 旨在通过一系列简化表格从整个企业的各种用户、开发人员和利益相关者那里收集信息。目标是让了解各种系统角色的人参与进来。这些数据为每个人创造了一个更加“民主”的机会，可以使用网络和数据流的可视化来支持和现代化支持其角色的系统。该工具提供与主要云的集成以及可通过所有主要语言（Python、C#、Java 等）进行定制的 API。

Atoll Group SAMU

Atoll Group 创建了 SAMU，通过与云层和业务流程管理工具的深度连接来跟踪企业架构。它提供与监控工具（Tivoli、ServiceNow 等）、云虚拟化管理器（VMware、AWS 等）、配置管理数据库（CA、BMC）以及服务组织工具（BMC、HP）的集成。这些集成提供了一个集中的数据模型，该模型增加了利益相关者的输入。

Avolution Abacus

Avolution 的主要工具 Abacus 提供了一组数据收集集成例程，用于构建图表驱动的仪表板。与 SharePoint、Excel、Visio、Google Sheets、Technopedia 和 ServiceNow 等办公工具的核心集成简化了使用它们的工作流的使用。该工具最近开始添加机器学习层，现在用户可以尝试训练一个模型，该模型可以帮助回答诸如哪个工作人员负责特定系统等问题。

BOC Group ADOIT

BOC Group 的 ADOIT 是一个广泛开放的工具，可将每个系统或软件包映射到一个对象。系统之间的数据流使用可定制的元模型转换为对象捕获的关系。业务流程也由集成良好的配套产品 ADONIS 进行类似建模。基于 Web 的工具还与 Atlassian 的 Confluence 等工具集成，以加快数据捕获和演化。

BiZZdesign HoriZZon

BiZZdesign 的主要工具称为 HoriZZon，它提供了一个基于图形的模型，用于从所有利益相关者那里收集数据，因此其分析引擎可以生成说明系统当前状态的图表。管理变更和规划未来是 BiZZdesign 的重点，HoriZZon 旨在帮助管理重新设计的风险。该工具集支持 ArchiMate、TOGAF 和 BPMN 等主要标准。

Capsifi

Capsifi 的 Jalapeno 在其基于云的平台中创建商业模式。目标不仅仅是在模型中捕捉工作流，而是让领导层能够充分理解以通过创新推动转型。该软件允许用户将“客户旅程”或“价值流”等建模概念结合在一起，并将其与从 Jira 等工具收集的数据集成。这些数据可以生成通过一组图表和仪表报告的指标，这些图表和仪表旨在衡量进度或“燃尽”。

Clausmark Bee360

Clausmark 的旗舰产品 Bee360（以前称为 Bee4IT）旨在提供有关企业工作流程的简单事实来源，以便许多角色可以做出更明智的决策。该系统还提供了使用 Bee360 FM（财务管理）跟踪和分配成本的能力。

EAS

Enterprise Architecture Solutions 的 Essential 包最初是一个开源项目，后来演变成一个商业可用的云解决方案。它创建了一个描述系统和业务流程之间交互的元模型。商业版本包括用于跟踪一些常见业务工作流程的软件包，例如数据管理或 GDPR 合规性。

LeanIX Enterprise Architecture Suite

LeanIX 工具集包括企业架构套件以及其他几个工具，例如用于跟踪云部署和在其上运行的服务的云智能和服务智能。它们一起收集有关您的 IT 基础架构的数据，并将其呈现在其 Fact Sheet 模型中，这是一种用于基本信息的直接交付机制。该工具与几个主要的云工作流工具紧密集成，包括 Confluence、Jira、Signavio 和 Lucidchart，这对于已经使用这些工具来规划和执行开发策略的团队来说是一个优势。

Mega Hopex

Mega 构建了 Hopex 平台以支持对企业应用程序进行建模，同时了解它们支持的业务工作流程。数据治理和风险管理是等式的重要组成部分。该工具建立在 Azure 之上，并依赖于一系列开放标准，包括 GraphQL 和 REST 查询，以从组件系统中收集信息。报告与 Microsoft 的 Office 工具以及 Tableau 和 Qllk 等图形解决方案集成。

Orbus Software iServer

Orbus 在 Microsoft 堆栈上构建了它的 iServer 工具，它的产品对于任何与 Microsoft 工具紧密结合的团队来说都是熟悉和可用的。报告出现在 Microsoft Word 中。数据被格式化为 Excel。一切都在 Azure 上运行良好。这些工具不仅限于 Microsoft 环境，因为它的模块集合支持主要的、开放的集成标准来收集数据。

Planview Enterprise One

Planview 提供了一系列用于跟踪团队合作、流程和企业架构的产品。其 Enterprise One 创建机器和软件层组合，为经理和团队成员提供基于角色的视图。该工具与常见的工单跟踪系统（如 Jira）集成，用于创建工作流分析和报告。 Planview 还提供了类似的工具，例如 Daptiv、Barometer 和 Projectplace，用于跟踪业务工作流程和流程的发展。

QualiWare Enterprise Architecture

QualiWare 的企业架构工具是一系列旨在捕获所有业务流程的建模工具的一部分。它为构建可以记录客户旅程进展情况的数字双胞胎提供了一个全新的条件。该公司正在整合各种人工智能算法，以增强文档和流程发现。

Quest Erwin Evolve

Quest 的 Erwin Evolve 工具最初是一个数据建模系统，后来发展为提供企业架构和业务流程建模。团队可以使用定制的数据结构来捕捉现代、联锁软件系统和他们管理的业务工作流的复杂性。基于 Web 的工具创建模型，生成基于角色的图表和其他可视化，为所有团队成员形成仪表板。这些也可以转换为定期报告以进行分发。

Software AG Alfabet

Alfabet 是用于管理 API、云计算和支持物联网设备的应用程序的大量产品之一。该系统从各种界面收集信息，并生成数百甚至数千个充满生命周期地图、图表、排名和地理坐标的潜在报告。传统上，Software AG 提供与 IBM 产品紧密结合的 ADABAS 等工具，而 Alfabet 提供与所有主要平台的紧密集成，包括 Microsoft Teams 等协作空间。其最新版本将包括一个声音选项 Alfabot，它提供“对话式用户界面 (CUI)”。

Sparx

Sparx 创建了四个级别的工具，以便各种规模的团队可以处理各种规模和复杂性的项目。所有这些都提供基于 UML 的建模，以跟踪日益复杂的系统的各个部分。模拟引擎可以进行兵棋推演，并了解故障如何传播和级联，这是灾难规划的重要组成部分。 Sparx 认识到可以出于各种原因构建模型，包括纯粹的分析、软件开发或战略规划，并且他们提供了数百种潜在的预构建设计模式来指导建模。

Unicom System Architect

联通 TeamBlue 的最新产品之一是 System Architect，这是一种使用元模型自动收集有关运行系统的尽可能多数据的工具，有时通过对数据流进行逆向工程。这个系统范围的数据模型可以在用户可定制的仪表板中呈现给所有角色的团队成员。有远见的管理者也可以开始模拟以帮助优化资源分配。

ValueBlue Blue Dolphin

ValueBlue 的 BlueDolphin 以三种方式收集数据。 首先，它依赖于标准驱动的自动化（ITSM、SAM）来导入基础数据。 其次，它以 ArchiMate 或 BPMN 等文件格式与架构师和系统设计师合作。 最后，它使用由可定制模板驱动的问卷调查其他利益相关者。 所有这些都是在一个跟踪系统历史演变的视觉环境中提供的。

有关推进企业架构的更多信息：

• https://jiagoushi.pro/enterprise_architecture

原文：https://www.cio.com/article/196069/top-enterprise-architecture-tools.ht…

本文:https://jiagoushi.pro/node/2105

企业正在使用企业架构来改善产品交付、风险管理，甚至员工保留，以及其他关键业务用途。

企业架构 (EA) 学科经常被批评为迫使业务用户选择技术或产生无人使用的软件分析。

但是今天 EA 的实践正在蓬勃发展，任何描述的架构师都很难找到并且“非常昂贵”，Gartner 研究副总裁 Marcus Blosch 说。

Forrester Research 已确定其客户使用的 20 多种企业架构角色。他们的范围从定义业务和运营模型的组织架构师到项目、平台和数字架构师。 Forrester 的首席分析师 Gordon Barnett 说：“这份名单越来越多，从只关注应用程序和基础设施的 EA 转变为真正的企业。您需要一个由主题专家组成的生态系统。你可能不会称他们为建筑师，但他们仍然扮演着建筑师的角色。”

以下是精明的 EA 从业者如何帮助企业应对当今最紧迫的三个业务挑战。

弹性和适应性

随着从 COVID 关闭到经济制裁破坏运营和供应链的一切，企业正在转向 EA 的洞察力，以更快、更有效地预测和响应问题。

Barnett 表示，虽然弹性一直是 EA 的重点，但“现在的重点是主动弹性”以更好地预测未来风险。他建议扩展 EA，不仅要映射企业的技术资产，还要映射其依赖供应商的所有流程，以及可能因流行病、制裁、自然灾害或其他中断而无法使用的兼职和合同工。

Barnett 说，企业还希望使用 EA 来预测问题并规划工作负载平衡或按需计算等功能，以应对需求激增或系统中断。这需要企业架构师与风险管理和安全人员更紧密地合作，以了解架构中组件之间的依赖关系，从而更好地了解中断的可能性和严重性，并制定应对计划。

他说，例如，EA 可以帮助描述哪些云提供商共享相同的网络连接，或者哪些托运人依赖相同的端口，以确保“备用”提供商不会遭受与主要提供商相同的中断。

规划供应链中断

Mike Small 是工程和数字解决方案公司 AKKA & Modis（即将成为 Akkodis）北美地区的负责人，他表示 EA 正在帮助汽车制造商等企业了解他们是否以及如何在没有完整的难以交付的产品的情况下交付产品。 - 寻找半导体等组件。

他的一些客户将企业架构师与产品、分析和供应链专家聚集在一起，询问“我是否仍然可以在没有 100% 的物料清单的情况下安全地销售该产品？如果答案是肯定的，那么当我的系统设计为与产品规格零偏差时，我该怎么做呢？”他说。他说，这可能需要对 ERP 系统进行分析，以了解引用物料清单的所有依赖项和功能。

Radicle Science 提供在线服务来衡量健康和保健产品的有效性，它使用 EA 来跟踪其数据供应商使用的 API 和数据格式，因此变化不会破坏业务，首席技术官 Sheldon Borkin 说。 “我们对第三方物流供应商的建模越深入”，Radicle 就越意识到不仅需要映射每个供应商使用的 API，还需要映射他们存储提供给 Radicle 的数据的格式。 “我们需要为每个 API 编写一个适配器，并在 EA 中构建对此类适配器的需求以及跟踪它们的能力，”他说。

员工招聘和保留

随着员工短缺使全球各行各业步履蹒跚，改善员工体验以留住重要人才已成为一项战略当务之急。企业使用 EA 不仅可以提供更好的应用程序和服务，还可以提供能够吸引和留住员工的工作体验。

在过去几年中，AKKA & Modis 对从其网络到身份验证工具的所有内容进行了改造，“以在实体办公室或远程位置提供相同的体验，”Small 说。 “远程工作促使我们的客户重新配置他们的企业架构计划和战略。 EA 对于确保这些远程工作和协作工具具有可扩展性和安全性至关重要，”他说。 “这是我们在招聘和留住人才方面看到的关键差异化因素。”

Small 说，EA 还通过了解新员工在第一天需要哪些应用程序和服务并确保他们拥有访问权限，“在确保新员工能够尽快、轻松地入职”方面发挥着关键作用。他说，让新员工快速感受到工作效率对于留住他们至关重要。

Barnett 说“人员架构”是一种不断发展的 EA 形式，旨在了解外包、裁员和自动化等变化如何影响员工以及如何帮助他们适应。例如，近年来，网络工程师完成的大部分工作已经自动化。他说，了解这些变化如何影响他们，以及如何在新领域使用他们的技能，对于留住员工和最大限度地提高他们的生产力至关重要。

改进的产品和服务交付

跨行业，灵活的公司需要将其 IT 工作集中在客户最需要的产品和服务上，而不是为了自身的利益而实施技术。

Small 看到了将以前在独立团队中从事云或数据分析等技术工作的员工重新部署到“基于项目的 pod 以解决紧急需求”的趋势。企业架构是将这些单元粘合在一起的粘合剂，着眼于整体业务需求”并确保他们开发的产品或服务运行良好，他说。

在 Wells Fargo，EA 提供云参考架构，支持这家金融服务巨头迁移到云、敏捷软件开发，并提供更多新“产品”，例如指导首次求职者创建银行账户并获得他们的银行账户的应用程序。第一张信用卡，首席企业架构师 Manish Vipani 说。

EA 还帮助 Wells Fargo 集成面向客户的和后台应用程序，以跨渠道（如面对面、Web、电话和移动应用程序）创建更一致的体验。 Vipani 说，它的 EA 实践正在帮助它从点对点连接的“意大利面条式”架构转变为更多通过 API 连接的具有明确定义层的“千层面”类型架构。

例如，其数百个 EA 的工作帮助富国银行使用此类数据集成，通过将一些数据预填充到客户的应用程序中来实现房屋抵押在线申请流程的现代化。他说，类似的方法有助于将信用卡申请流程从平均 25 分钟缩短到 4 分钟。如果改进后的集成可以告诉信用卡应用程序客户在银行有直接存款，它可以对他们进行信用卡资格预审，并通过单击鼠标处理应用程序。

“我们通常希望快速推出产品，如果成功，就更大规模地推出，”他说。 “这需要了解所有通过 API 公开的系统，无论是核心银行平台还是财富管理。”

跟踪数据和 API

随着 Radicle 致力于更快地完成更多健康产品的虚拟试验并向客户证明其结果，“我们的软件平台需要对人员、参与者和用品进行编排，以使其具有可扩展性，”Borkin 说。

为了实现这一目标，它正在重新定义其衡量的 EA 组件，以了解例如哪些数据必须以何种格式存储，以便随着时间的推移对其进行研究。 “重要的是技术团队和进行试验的研究团队之间的沟通，”他说。 “作为一家公司，我们同意我们收集的关键数据及其组织方式。”

Radicle 还使用 EA 洞察力来确定要维护的数据库的数量和类型，以及何时应该通过点对点 API 交换数据，通常是在内部开发的服务或一次性集成之间，而不是通过公共服务层旨在随着时间的推移而扩展。

“由于我们正在建立一个多年的研究数据存储库，仅仅说‘我们有 API’是不够的，”他说。 “您可能不知道连接到新数据源或服务所需的所有 API，例如需要与研究存储库交互的数据规范化。” Radicle 使用 EA 来“确保构建此关键数据资产以扩展广度和深度，同时保持易于访问以发现新的健康见解。”

本文：https://jiagoushi.pro/five-areas-where-ea-matters-more-ever

今天的内容构成了名为“谁仍然对企业架构感兴趣？”系列的六个部分中的第六部分，也是最后一部分。在本系列中，我将就当今企业架构的足迹、企业架构师角色的潜在死亡、大型参与者（例如 The Open Group、AWS 或 Azure 的 TOGAF）以及EA 工具提供商的角色以及其他相关证书和市场上的发展。

在今天的第六部分中，我们从前面的部分中得出结论，并预测这对未来意味着什么。

无论您是在阅读本文还是在收听播客版本，请务必同时查看本系列的前五个部分！

谁仍然对企业架构感兴趣？ — 第 6 部分，共 6 部分

1.企业架构活动由不同的角色承担

EA 不再总是被称为 EA，但这种做法仍然高度相关。当今大多数为现代 EA 提供最佳实践的行业和思想领袖不再称自己为企业架构师。这就是为什么这种做法在今天被认为不那么重要的原因。

但是，有一些新的头衔和角色涵盖了企业架构方面，它们过去并没有成为传统企业架构模型的一部分。此外，企业架构活动通常由 IT 架构师负责，他们同时承担一些 IT 和一些企业职责。结果是企业架构和 IT 架构变得更加一致，有时由同一个角色来处理。

2. 新的企业架构管理框架

由于框架和方法的相关性和紧迫性增加，新的参与者进入了企业架构领域。

传统的、著名的企业架构组织的结构似乎太慢了，无法对数字化转型引发的破坏做出反应。

因此，新工具和技术的供应商，尤其是来自云领域的供应商，开发了他们自己的框架和方法来应对他们组织的多重新挑战。

3. 企业架构框架是推动成功数字化转型所必需的

数字化发展仍会引发定期中断和强劲增长（例如，新的云服务提供商和支持技术）。

因此，有许多新兴市场参与者提供了新的和多样化的解决方案，导致企业架构最佳实践分散。

因此，EA 针对不同的实践和部门以及不同的参与者，例如工具提供商、大型云提供商、敏捷框架、组织和社区。

企业架构的未来

虽然在许多领域，多样化的解决方案和竞争是有益的，但对于旨在提供标准和可比性的企业架构而言，情况并非如此。此外，多样化的市场解决方案可能会使 IT 和企业架构师的工作在未来更具挑战性，因为他们需要保持概览并完全一致。

因此，近年来发展起来的多样化格局可能会在涵盖企业架构的关键活动和目标的新（甚至旧）总称下巩固和协调。

这是“谁仍然对企业架构感兴趣”系列的结尾。如果您喜欢它或它对您有帮助，请喜欢，分享，并在下面的评论部分告诉我您的反馈！

原文：https://digitalroadmap-management.medium.com/why-enterprise-architectur…

本文：https://jiagoushi.pro/why-enterprise-architecture-activities-are-more-i…

你在开玩笑吗？

当涉及到想象力时，生活总是胜过小说。最近，一家大公司要求我展示再次实施 EA 功能的 ROI 证明。

这家公司过去曾聘请过架构师，但在他们选择大型企业资源规划 (ERP) 解决方案作为公司的运营信息系统 (IS) 主干时，他们就被淘汰了。这在某种程度上是有道理的：IS 是围绕所有 ERP 功能组织的。那么在这种情况下，企业架构师的需求是什么？此外，我们可能认为公司的 EA 架构师实际上是 ERP 编辑的。

没有企业架构师的公司会获得默认的企业架构。因此，在这种情况下，此默认 EA 由 ERP 编辑器的策略驱动。只要公司的战略以卓越的商品服务实施为基础，它就可以奏效，而且在这种情况下也奏效了。这意味着公司的竞争优势基于成本削减和运营生产力。再加上最终在 ERP 之外的孤立的 IS 中管理的一两个业务创新。

这家公司最近完成了一项业务和 IT 审查，发现 ERP 是部署新业务线和所需 IT 推动力的瓶颈。因此，他们决定在许多 IS 战略领域推翻 ERP。但是他们现在缺少企业架构师。项目和项目负责人现在有一个长期的习惯，主要是为了他们自己的需求而做架构，并且不想改变这种做法。因此，EA ROI 证明的问题是为了有机会获得一些高水平的赞助，以应对变革的运营阻力。

我的回答不是“你在开玩笑吗？”但听起来很像。我失去了这笔交易。

危险

想大点。快速失败。我尝试了几个不成功的想法。

• 第一个是：如今，信息系统是每个业务战略运营实施的核心。如果没有人来推动 IS 架构，你怎么能想象取得成功的战略成果？答案是：“到目前为止，我们已经没有架构师了，一切都很好。这个论点并不能证明 EA 的价值”。客观地，由于情况会改变，答案并不真正适用……但它是客户，我不能这么说。
• 第二个论点是关于迄今为止从 ERP 编辑器自己的 EA 中受益。既然 ERP 的使用打算减少为非战略性商品服务，那么 ERP 架构师将不得不被公司的架构师取代。相同的答案：项目负责人不会让架构师对他们的业务嗤之以鼻。
• 第三个论点：让我和 C 级的人谈谈，我相信他们知道 EA 的价值，并且会支持再次将其引入内部。没有反应。也许我的对话者尝试过但没有被倾听。或者很可能他们不敢尝试没有数字。

然后光来了。危险。 EA 的答案是什么？为什么又要 EA 回来？当你想到它时，这不是一个笑话：你确实想要 EA，为什么？

EA成本太高的想法是怎么来的？

越抽象的事物，就越难以将独家收益与它联系起来。所以 EA 投资回报率的回报部分肯定是难以阐述的。我们大概可以粗略计算出公司新业务战略部署的预期投资回报率。但是很难（委婉地说）隔离它的一部分，这要归功于企业级别的良好架构方法。即使使用不好的或默认的 EA 方法，我们仍然可以获得一些收益。并且，如果管理良好的 EA 实施，收益会更大，这一事实可能（委婉说法）永远不会被评估。

计算成本很容易（似乎是这样，但让我们从简单的角度来看）。企业架构的成本是多少？主要是花费时间的劳动力成本：架构工作、架构组合学、架构治理、架构支持和传播。最终还与架构工具相关的成本。此外，延迟上市时间的间接成本也可能被视为收入延迟过多（我们可以说安全工作流也是如此）。

即使使用默认 EA，也会发生这些成本！如果不做出架构决策，任何人都无法构建信息系统。问题是：我们是否想以一种有管理的方式组织这些决策？还是我们想让个人在每个决策点做出决定？考虑或不考虑其他地方做出的架构决策？在这种“默认”方式中，不会编译 EA 成本，因此我们看不到它们。

对 EA 的误解

EA 最大的错误当然是认为架构师必须做所有的架构工作。架构师是唯一能够使用架构材料来讲述“真相”的人，因为架构很复杂。

这种情况被称为象牙塔综合症。在这种情况下，架构师一起工作并生成仅供架构师使用和使用的架构文档。最终他们产生了一些转型影响分析：通常生产成本为 80% 的 20% 的部分。这些架构工件需要经常与“现实世界”保持一致。使用昂贵的工具。

总成本的 20% 的 80% 部分，对于其他任何人来说都足够了，要么由架构师或其他人生产，要么甚至不生产或部分生产。这一切都取决于利益相关者对架构问题的看法。碰巧的是，核心架构描述是在没有架构师负责的情况下做出的，并做出了相关的决定！

我们不想再去那里了。可以理解。这种没有重大影响的“无底井”成本来源是对 EA 不信任的主要原因。

如何让 EA 再次伟大？

让我们尝试以仅 20% 的 EA“大图”成本获得 80% 的 EA 收益。

这个想法是在战略/组织级别上重新控制架构决策。并避免让这些决策在本地子级别或全局元级别做出。

让我们来说明这个想法。
在进行任何重大战略转型之前，最好先解释一下我们想要做什么、为什么、如何等。企业架构如何在构想中发生？
让我们用 5W2H 方法来说明这一点：

• 什么？ ：我们将改变什么到IS组织（架构）？
• 为什么？ : 我们怎么会改变 IS 架构？
• 在哪里？ ：IS的哪一部分会受到关注？
• 什么时候？ : 有没有设想的路线图？
• 谁？ ： 什么构建组织将操作更改？ （以及如何在构建组织和 IS 构建块之间获得精益映射）
• 如何？ ：是否有任何 IT 推动者可以实现更轻松的更改？
• 多少？ ：与减少建筑债务相关的成本是多少？设置新的 IT 功能？

是的，这与 TOGAF 架构开发方法中的阶段 A：架构愿景非常相似。相似但不一样。在这里，我们不关注架构的架构，但我们希望将架构作为整体的一部分来关注。架构与任何其他考虑因素一样参与转换。

这里的想法是：让我们与大家分享架构愿景。就像我们对业务愿景、产品愿景、组织愿景所做的那样……

企业架构是业务需求、运营业务的 SI 产品以及人员和其他资源的组织之间的粘合剂，以帮助公司实现其下一个战略目标。

原文：https://medium.com/@vhanniet/the-return-on-investment-roi-of-enterprise…

本文：https://jiagoushi.pro/node/2177

有几个角色与企业架构以及团队/项目级别的架构相关。请记住，这些是角色，而不是职位。小型组织可能有一个人担任这些角色中的每一个，而大型组织可能有几十个细粒度的职位。请记住，上下文很重要。我们为 Disciplined Agile® (DA™) 企业架构定义了以下角色：

• 企业架构师 (EA)。企业架构师负责构想、沟通和发展组织的企业架构。企业架构解决了关键的企业方面——包括组织结构、业务流程和战略、价值流、数据和信息以及支持技术——以及它们如何组合在一起并随着时间的推移而发展。
• 首席企业架构师。首席企业架构师或首席 EA 领导组织内的企业架构团队。此人通常是具有额外领导职责的企业架构师。
• 架构所有者 (AO)。 AO 在架构/解决方案决策中指导团队，特别是解决方案交付团队。 AO 将与企业架构师密切合作，甚至可能同时担任这两个角色。 AO 是一个团队级别的角色，有时被称为敏捷解决方案架构师或简称为敏捷架构师。
• 首席架构师 (CAO)。 CAO 是项目级别的角色，领导整个项目的架构工作。 CAO 通常是具有领导职责的高级 AO。 CAO 与 EA 密切合作，也可能是 EA。
• 专业架构师。对于专注于企业架构特定方面的架构师来说，这是一个“元角色”。表 1 列出了您组织中可能存在的潜在专业架构师。

表 1. 专业架构师的类型。

 

专业建筑师的类型	架构重点
业务架构师	组织业务流程 使业务战略与价值流和产品战略保持一致 组织架构 企业数据
信息/数据架构师	人工智能 (AI) 数据/信息安全 企业数据 信息流
领域架构师	业务架构师，进一步专注于您的业务领域的一个方面，例如金融机构中的经纪或土木工程中的水文。
基础架构架构师	IT网络和系统 物理设备 物理基础设施（建筑物，……） 机器人技术
信息技术 (IT) 架构师	人工智能 (AI) 数据/信息 IT网络和系统 信息安全 机器人技术 系统集成
网络架构师	基于云的计算 IT系统 电信
产品/服务架构师	单一产品或服务的所有方面
安全架构师	网络/信息安全 物理安全
价值流架构师	价值流的所有方面 工艺流程
Web架构师	系统集成 用户体验

 

原文：https://www.pmi.org/disciplined-agile/process/enterprise-architecture/e…

本文：

今天的内容构成了名为“2021 年谁仍然对企业架构感兴趣？”系列的六个部分中的第一个部分。在这个系列中，我提供了我的观点

• - 当今企业架构的足迹，
• - 企业架构师角色的潜在死亡，
• - 大玩家，例如 The Open Group、AWS 或 Azure 的 TOGAF，
• - 以及 EA 工具提供商的角色和
• - 市场上的其他相关证书和发展。

在今天的第一部分中，我分析了 Google Trends 上常见企业架构术语的搜索词 attention。我将重点介绍当今最重要的 EA 框架 TOGAF 和 Zachman 的起源，并分享我的求职结果。我推断企业架构可能是一种死法。

无论您是在阅读本文还是在收听播客版本，请务必尽快查看该系列的其他部分！

2021 年谁还对企业架构感兴趣？

– 第 1 部分，共 6 部分
似乎，尤其是在现代科技公司中，企业架构 (EA) 实践的重要性正在下降。一些组织甚至可能认为这是一种无关紧要的做法。在下文中，我们分析了这些意见的来源。在本系列的后面部分，我们将提供反对这种推理的论据并提供分析，这表明这并不是企业架构作为一种实践的终结。然而，企业架构将经历转变为一组经过调整的活动、新的优先事项和新的所需技能。

传统的企业架构术语、角色和框架变得无关紧要

对 EA 的关注度似乎在稳步下降：根据谷歌趋势摘录的图 1，主题集群“企业架构”的搜索请求数量自 2016 年以来下降了 50% 以上，自 2004 年以来下降了 75% 。此外，图 1 显示了 2004 年至 2021 年期间对“业务架构”、“应用程序生命周期管理”、“数据管理”和“技术管理”等相关 EA 术语的搜索请求的相对数量。所有随着时间的推移，他们的注意力逐渐减少。

图1

此外，与几十年前相比，EA 博客和网站也少了很多。由于缺乏更新，很多关于最佳实践的过时 EA 内容在搜索引擎中的排名仍然较高。

TOGAF 和 Zachman 已过时

进一步的证据来自最重要的行业标准框架，例如 TOGAF 和 Zachman。 TOGAF 于 1995 年首次发布。它由 The Open Group 的几家成员公司开发，包括 IBM 或 Oracle 等主要参与者。 TOGAF 标准每隔几年更新一次，最新版本是 2018 年 4 月的 9.2 版。虽然最新版本旨在更好地针对数字化转型这一主题，但整体内容并没有太大变化。此外，经过认证的从业者不需要在次要版本之间更新他们的认证，当前的主要版本于 2011 年上线。在持续数字中断的时代，十年前的内容不再完全相关。

第二个最重要的框架是 Zachman 框架。随着 1987 年的初始版本和 2011 年的最新主要版本，它与 TOGAF 具有相同的年龄。因此，我们可以说，最重要的企业架构框架在过去十年中没有收到任何重大更新，因此——至少部分地——已经过时了。

许多大型科技公司不寻找企业架构师

除了上述论点之外，还有一个额外的观察结果，这在许多不同的组织中都很常见：组织拥有的旧世界/遗留 IT 越多，组织中的企业架构师就越重要。同样，在拥有旧世界和新世界 IT 的组​​织中，企业架构师负责管理旧世界的架构。但是，它们对新世界IT的发展影响甚微；数字区。如果他们干涉（例如，试图调整事情），他们通常被视为减慢进程，并成为项目成功的障碍或威胁。尽管这肯定有例外，但有一个明确的模式是，很少或没有遗留 IT 的公司没有企业架构师的角色，也不为他们的组织寻找这样的职位。在 Netflix 或亚马逊寻找“企业架构师”的工作似乎证实了这一趋势。

这是否意味着企业架构已死？ 2021 年的企业架构是否还有相关性？它在当今的数字时代扮演什么角色？在本系列的下一部分中，我们将回答这些问题。

您喜欢“企业架构的相关性”系列的这一部分吗？你能确认观察和分析，还是你不同意？很高兴听到你的想法！

原文：https://digitalroadmap-management.medium.com/what-is-today-s-relevance-…

本文：https://jiagoushi.pro/what-todays-relevance-enterprise-architecture-pra…

EA 软件可以为您企业庞大的技术运营的内部运作带来秩序。 这是制图和编目的好处——以及关于真正魔力所在的一些注意事项。

企业架构旨在为企业 IT 的广阔领域及其蓬勃发展的机器和软件集合带来秩序，这是几十年前无法想象的聚宝盆。台式机、平板电脑、手机——一目了然的屏幕。这还不包括无屏幕设备，如传感器、响应“Alexa”的音频设备，以及所谓的物联网中的所有其他东西。

唉，数字丰富并不总是一份礼物。毕竟，这一切都伴随着责任。机器、算法、软件升级和科罗拉多农场似乎成倍增加，需要有人看管和照顾它们。

在其核心，企业架构 (EA) 工具以数据库表的形式维护资产的主列表，该数据库表对设备进行编目。然后它添加了一系列功能，以易于使用的方式显示此信息。魔力来自部署软件、用数据填充软件、然后使用它做出更明智决策的团队。

所有这些制表、策划和跟踪都值得吗？大惊小怪值得麻烦吗？以下是您的组织值得投资企业架构解决方案的六个原因——以及在依赖 EA 工具时需要牢记的一些问题。

秩序很好

任何事情都比运行未知软件的庞大计算机网络要好，这些计算机运行由可能不再为公司工作或不再为公司工作的未跟踪工人编写的未知软件。写在纸上的清单将是一个开始。电子表格会更好。企业架构工具远远超出列表。它们为世界增添了秩序，提供了大量关于通过您企业无穷无尽的硬件收集的大量比特的信息。

然而，重要的是要记住，工具不提供秩序。人们这样做。企业架构工具只是提供建立秩序的手段。想象一下，例如，一张纸条说在没有与客户获取团队交谈的情况下不要关闭服务器。如果该团队在 3 次重组前被分散，并且没有人更新该注释怎么办？

软件开发人员经常发现，当文档偏离代码时，文档可能会导致问题。突然间，人们在假设一件事，而代码却在做另一件事。企业架构工具仍然是解决方案，但它们并不神奇。他们承诺维护数据。它们只是您的团队带来秩序的途径。他们不会自己带来秩序。

企业架构打破孤岛

随着差异的增加，组织可能会遭受孤立。一个团队选择技术 A，而另一个团队选择 B。安装企业架构软件不会解决这些深刻的差异，但它会更容易发现这些差异。在企业架构工具中对企业资产进行编目的过程揭示了许多区别，这是建立某种统一性的第一步。中央数据库是变革的催化剂。

当然，仅仅因为 EA 工具可以发现不一致，并不意味着它们都应该得到解决。我们可能会直截了当地谴责那些拼凑出几乎无法通信的软件包集合的傻瓜，但这些差异通常提供了一点安全性和弹性。单一文化更容易受到攻击，更容易受到灾难的影响。影响一个角落的问题将影响所有角落。这并不是说不和谐的软件集合的精神杂音是令人愉快的或可取的。只是它有一些优点。

指标识别问题

商学院的教训很清楚：你无法管理你无法衡量的东西。 EA 软件带来了一系列工具，用于衡量数字领域的运作方式。现在有一种方法可以相互比较团队、部门和部门。 EA 可以发现落后的服务器、过载的数据库和负载过重的网络。

但请记住，指标会带来噪音。数据就在那里。它可以被聚合、清理并显示在一个光滑的仪表板上。但仅仅因为这些位可用并不意味着它们带来任何真正的洞察力。这些工具提供了有关企业资产的大量信息，但需要专业知识才能了解这些数字的含义。

自动化节省时间

许多 EA 工具都为它们能够连接到计算机网络并自动收集大量信息而感到自豪。我们已经达到了一个开发水平，已经通过 API 和调试工具提供了相当多的遥测。这一切都可以归结为一个有用的界面，这样我们就可以看到发生了什么。

当然，自动化很少是万无一失的。迈克尔克莱顿的小说侏罗纪公园的情节取决于计算机程序未能对岛上的恐龙进行准确的人口普查。它只被编程为跟踪它所知道的恐龙，因此它忽略了恐龙正在繁殖的事实。这种盲目性也是 EA 系统的危险。他们只能跟随集成到其中的计算机。

单一的事实来源至关重要

花费太多时间搜索正确的信息。企业架构工具充当节省时间的单一信息源。构建基础设施可能会很昂贵，但一旦运行，就很容易找到真相。

同时，重要的是要知道，尽管 EA 软件承诺提供单一事实来源，但很少存在单一事实来源。即使他们这样做了，他们也可能是错的，而且没有办法知道。只有一种意见，就没有共识，也没有分析的机会。

尽管如此，手电筒，无论多么微弱，总比在黑暗中摸索要好。与其纠结于软件如何无法完美地映射您的企业，不如放下这些犹豫，继续完成对您的企业交付的数据处理的聚宝盆进行编目和跟踪的艰巨任务。

 

原文：https://www.cio.com/article/191560/6-reasons-to-invest-in-enterprise-ar…

本文：https://jiagoushi.pro/node/2111

 

敏捷组织正变得越来越普遍，因为人们越来越欣赏他们的转型收益。 通过这一运动，我们正在协助出现一种新型的企业架构师，这些架构师在使他们的公司更加敏捷方面发挥着重要作用。 它需要重大的文化转变，企业架构师需要经常与组织内的不同利益相关者协作。

太多的企业架构师仍将自己限制在编写封闭的“解决方案架构定义文档”并躲避实际行动。然而，我们看到了一种新的趋势。越来越多的业务和企业架构团队正在参与并融入其组织的业务优先级战略规划、投资组合管理、路线图优化、产品管理、以客户为中心的计划、敏捷项目微调、更新和更现代的面向业务的 KPI 定义等.

简而言之，我们正在协助新一代企业架构师的出现，这些架构师在使他们的公司更加敏捷方面变得非常重要。

敏捷组织

敏捷组织正变得越来越普遍，因为人们越来越欣赏他们的转型收益。但要实现敏捷的运营模式很困难，尤其是对于成熟的和更传统的公司而言。 “敏捷组织之旅”一文很好地解释了成功的敏捷转型如何在其敏捷转型中共享共同元素：

“传统组织是围绕静态的、孤立的、结构化的层次结构构建的，而敏捷组织的特点是在快速学习和决策周期中运行的团队网络。传统组织将其治理机构置于最高层，决策权沿层级向下流动；相反，敏捷组织灌输一个共同目标，并使用新数据将决策权授予最接近信息的团队。敏捷组织可以将速度和适应性与稳定性和效率完美地结合起来。”

这种转变包括跨越两个广泛阶段的几个元素：

• Aspire、设计和试点
• 扩展和改进

企业架构师通常主要参与第一阶段。

在这个阶段，转型始于高层管理人员的战略理解和抱负（Aspire），制定蓝图以检测敏捷将如何提供价值（设计）并使用敏捷试点（Pilot）进行学习，通常通过提供至少在一种快速和迭代的方式，为组织提供足够的指示来继续测试其设计。

下面的图 1 更详细地描述了企业级的敏捷运营模型，包括五个维度：

• 目标和价值
• 结构
• 敏捷团队
• 骨干
• 制定路线图和项目

首先，“目标和价值”维度应包括明确的战略和可衡量的目标，解释可以在哪里创造价值以及组织如何与竞争对手区分开来。其次，敏捷运营模型的迭代“结构”不是根据经典的组织结构图交付的，而是通过围绕共同使命和可衡量目标分组的具有清晰报告线的几个团队来交付的。第三，需要识别和建立迭代的“敏捷团队”，确保每个团队都有明确的目标，并且他们已经定义了他们的最佳工作流程。第四，迭代的“主干”需要包括对基本流程、人员和技术的概述要求，以实现最大的敏捷性。第五，需要详细说明高层次的“路线图”，其中包含项目的积压清单，以及它们在哪些方面被优先考虑以立即进行下一步。

企业架构和敏捷组织

在“使用架构微调 SAFe”中，我展示了架构和敏捷团队之间的协调如何有助于交付成功的项目，尤其是针对 Scaled Agile Framework (SAFe)。它展示了企业架构师和敏捷团队应该如何停止在孤岛中工作。他们的方法是互补的，而不是冲突的。架构和敏捷团队之间的协调有助于交付符合公司战略的成功项目。

“站在 SAFe 方面：业务架构和敏捷如何结合在一起”，还表明：

“业务架构不会妨碍敏捷团队，而是与他们一起工作以帮助他们最好地专注和做好准备——这可以加快工作速度而不是减慢速度。而且，它确保团队的敏捷性和成功应用于业务的最高价值部分。”

上面的图 1 还更详细地描述了企业架构在企业敏捷运营模型的每个阶段的影响。

• 首先，在“目标和价值”期间，至少需要详细说明关键价值流。商业动机模型也将非常有助于确定战略、战术及其相应的目标和目的。至于商业模式画布，它通常是确定一个组织如何与竞争对手区分开来的最短路径。
• 其次，在“结构”阶段，关键价值流按具有共同使命的团队进行分组。识别每个关键价值流/阶段的启用和有问题的能力。需要确定拥有关键价值流支持能力的组织单位。
• 第三，企业架构师应该包括在“敏捷团队”中。他们应根据战略目标和目的，定义关键战略举措及其可衡量的成果。
• 第四，在“主干”阶段，企业架构师可以帮助定义需求并使用他们的业务架构模型元素微调业务流程。目标价值流/阶段的使能能力与其相关的应用程序和数据库相关联。
• 第五，企业架构师将敏捷的“路线图和项目”与战略计划联系起来，这些计划基于关键和目标价值流/阶段及其支持和问题能力。项目将优先考虑财务比率和风险因素。

企业架构的新生态系统

在敏捷企业中，企业架构师在数字化转型计划的规划、架构和交付过程中需要与许多不同类型的协作者合作。 正如“使用业务架构的数字化转型”中所解释的，五个步骤可以描述如何使用企业架构完成敏捷的数字化转型，如下图 2 所示。 这些步骤包括：

• 制定目标和战略
• 业务和企业架构
• 制定路线图
• 敏捷交付解决方案
• 衡量绩效

对于这些步骤中的每一个，企业架构师都需要与不同类型的内部和外部协作者进行交互。

• 在第一步“制定目标和战略”中，企业架构师需要收集公司目标和战略，以便在组织的较低级别将其传播为有意义的目标和策略。他们可能与 CXO、总部战略家、业务部门经理、业务经理和/或变革经理互动。一次有几个计划，企业架构师需要构建一个详细的业务和企业架构模型，以尽可能多地反映他们企业的当前状态以及他们期望的与预期计划相关的未来状态。
• 在第二阶段，企业架构师通常需要与至少其中一些利益相关者合作：客户/合作伙伴、主题专家、业务经理、变更经理、产品经理、营销人员、应用程序架构师、解决方案架构师、数据架构师、商业智能架构师、IT 架构师和/或软件架构师。在这个阶段，企业架构师的主要目标是找到需要解决的支持和有问题的能力，以优化关键的战略价值流并使期望的未来状态成为现实。
• 在第 3 步中，企业架构师应与财务分析师一起协助 CIO、项目经理和/或投资组合经理交付高级路线图，该路线图可以详细分解以供以后交付。
• 一旦选择了路线图，企业架构师还应该参与第 4 步“解决方案的敏捷交付”，通常是客户、合作伙伴、用户、敏捷专家、业务流程专家、业务分析师、软件开发人员、IT 架构师和/或软件建筑师。
• 最后，在第 5 步中，企业架构师可能会参与需要完成的测量，以检查目标、目标和结果是否已达到。

对于许多企业架构师来说，这需要重大的文化转变，他们的任务变得更加多样化，并且他们需要能够以更高的频率与组织内的外部和内部利益相关者进行协作和沟通。

它涉及了解如何与那些提供解决方案的人建立技术对话，并与那些需要战略变革的人进行业务对话，正如“业务和企业架构师的 7 个令人信服的品质”中所解释的那样。这是并且不会是容易的。为了保持相关性，越来越多的企业架构师需要适应、变得更加灵活并接受这一挑战。

原文：https://www.cio.com/article/220107/the-enterprise-architects-ecosystem-…

本文：https://jiagoushi.pro/node/2106

谁说 EA 对于转型来说太死板了？ 现代敏捷企业架构师从小处着手，快速交付价值，并与产品团队协作。

当 Adrian Jones 在 2018 年成为快速发展的诊断巨头 SYNLAB 的唯一企业架构师时，他知道他过去看到的传统的、官僚主义的 EA 方法行不通。

SYNLAB 企业架构组负责人 Jones 需要快速收集和分析足够的信息，以便在 40 个国家/地区的数百个站点和 20,000 多名员工中部署新系统，并将实验室测试等服务数字化，以使其客户更轻松访问。

在 15 个月内，琼斯认为传统 EA 流程所需时间的一半，来自 SYNLAB 的 EA 工作的见解正在帮助这家价值 26 亿欧元的公司更好地管理其应用程序和技术风险，并评估其技术债务（未决工作所需的成本维护其应用程序和 IT 基础设施）。琼斯说，EA 洞察力还帮助 SYNLAB 推出了新服务，例如 COVID 测试计划，以帮助欧洲足球联赛安全地重返赛场。

这是敏捷时代的企业架构。敏捷的 EA 从业者和供应商不是花费数月或数年时间对企业的技术和业务流程进行建模和编目以执行产品标准，而是寻求与开发“产品”（例如为员工或客户的应用程序）的团队更紧密地合作.他们试图快速交付价值，与产品团队密切合作，并制定架构原则，而不是允许产品开发人员使用的平台的僵化列表。

不是你父亲的 EA

EA 旨在识别、理解和最大化 IT 基础设施公司在从大型机到分布式计算的过程中创建的成本效益。这需要有关其 IT 基础架构及其支持的应用程序和业务流程的信息中央存储库。但是，根据批评者的说法，EA 往往专注于削减成本和控制创新，描述技术而不是利用它的业务流程。在这个企业必须更快地改变的时代，它的步伐常常成为转型的障碍。

Forrester Research 的一项调查发现，55% 的客户仍在使用旧形式的 EA，其中包括“将企业架构视为美化的资产管理，专注于成本控制，而不是为了员工、客户和业务合作伙伴的利益最大化 IT 能力。”

Gartner 的副总裁 Marcus Blosch 说，传统的 EA “非常关注技术架构”，“试图以命令控制模式控制一切。”传统的 EA “自找麻烦，很多用户还是这么想的”。

快速交付价值

Forrester 的首席分析师 Gordon Barnett 说，敏捷 EA 的一个原则是在提供见解或建议之前，不要通过收集有关组织的每一点信息来沸腾海洋。为了加快流程，敏捷 EA 从业者会参考“最小可行架构”或“刚好够用架构”来解决紧急业务问题，并根据需要对 EA 流程进行频繁更改。但是，Barnett 警告说，关键是要选择正确的元素来包含，以确保这样一个最小的架构不会限制其未来的用途。

对于严重依赖 SaaS 应用程序和云的组织，“最小可行架构有助于将分布式生态系统与技术标准和更具协作性的治理模型结合在一起”，即使它没有提供分布式资产的中央存储库，现在Gartner 的 Blosch 补充说，支持业务。

在 SYNLABS，Jones 开始专注于“我们在应用程序组合方面了解业务所需的关键信息”，并将他的搜索范围缩小到最多“关于应用程序的 20 条信息”。然后，他使用 Ardoq 的 EA 工具中的调查功能来捕获额外的数据，例如他们的业务所依赖的系统的成本和风险“让 [用户] 参与......立即给他们一些回报。”

他还利用这些调查让用户提供有关他们自己的技术和流程组合的信息，并使用 Ardoq 将这些数据输入到存储库中，即使在采访用户时也是如此。他说，这很快让用户“非常清楚地了解他们现有的架构，他们可以用它来模拟未来的期望状态”。

一个例子是检查一个国家的血液样本采集过程。 “我能够向他们回放，‘这就是我们对你们系统的理解，’”琼斯说。 “他们完全被那件事震惊了。这是他们第一次对整个过程有自上而下的看法。”

教练，不要强制

自从两年半前开始敏捷转型以来，咨询公司麦肯锡公司的 EA 与其说是“标准的执行者和度量和图表的维护者”，不如说是“推动者”和合作伙伴，跨敏捷团队专注于业务成果，企业架构总监 Michael Sioufas 说。

“我们不一定要以规定的语气说，‘团队必须这样做或那样做’。我们为他们提供工具（例如最佳实践框架）、指导并帮助他们尽可能地利用这些工具，”他说。

Forrester 的 Barnett 表示，EA 团队鼓励的原则可能反映了，例如，“一个组织是否在一个对价格非常敏感的市场中运营”，这意味着“我们将把成本置于我们所有架构决策的中心”。他说，对于不同的企业，质量可能是一个驱动原则。

这些原则还使产品组或业务部门能够选择最能满足其需求的工具。例如，Barnett 说，“对于大容量 [商业智能] 数据仓库，您可能应该使用 Oracle，但如果是小型办公室，则可能是 Excel 数据库。你可能有混合云，有人们应该何时使用每一个的标准。”

但是，如果“EA 不想授权交付团队，交付团队不想接受 EA 的指导”，这种努力可能会动摇。 EA 流程可以让他们获得更多的咨询角色。

Vale 的全球企业架构经理 Marcelo Menard 说，敏捷 EA 的另一个特点是“数字实验室”，在全球矿业公司 Vale，它作为机器人和物联网等领域的实验来源。这些实验室以及为满足特殊需求而开发的全球 IT 供应商网络是新 EA 方法的一部分，该方法帮助 Vale 的 EA 团队从“一种警察”转变为“推动创新的主要团队之一”，他说。

产品组的权力

Sioufas 说，麦肯锡的 EA 小组已经取消了传统的企业架构审查委员会，转而采用去中心化模型，该模型检查敏捷团队正在处理的史诗（用户故事的集合），专注于“哪里最需要帮助，哪里需要帮助”。架构产品团队内部有很多重叠或协同作用。”

使组织的 IT 资产清单保持最新可能是一项重大挑战，特别是对于由容器和 API 构建的基于云的可组合应用程序，这些应用程序仅在需要时使用。 Blosch 说，业务部门可以负责执行这些更新，并且可以根据该部门的需要自由决定要更新哪些组件。

工作中的敏捷 EA

Sioufas 是该咨询公司人力资源和财务部门的领域架构师，他说麦肯锡的分散式 EA 结构以及对各种工具和框架的使用“帮助我们对我们所从事的不同业务领域有更多的洞察力。”

当团队发现 API 安全性薄弱、进行系统整合或管理技术债务等问题时，他们会通过专家“架构群”来解决这些任务，这些专家聚集在一起就像敏捷团队应对挑战一样。 “我们将其视为一个小冲刺——一个快速的问题陈述：问题是什么，我们需要找哪些人，我们试图实现什么结果，以及我们如何衡量成功？”苏法斯说。

Vale 的 EA 实践使用 LeanIX 的企业架构管理来帮助它快速响应由 COVID 驱动的突然变化，例如启用对设备的远程检查和向远程工作的转变。 Menard 说，EA 帮助 Vale 确定了“我们需要改进的能力和流程”以及自动化所需的流程。他说，用 IT 资产和应用程序的“单一事实来源”取代以前由各个业务线维护的孤立的架构信息存储库，有助于 Vale 避免重复并确定 IT 项目的优先级。

支持者说，无论过去有什么缺点，EA 都不会消失，因为它不能。无论组织多么敏捷，它都有一个以硬件、软件和工作流形式驱动业务的企业架构。通过采用敏捷的 EA 原则，EA 从业者可以快速而清晰地跟踪、描述和推荐对该架构的更改，以使其适应不断变化的业务需求。

原文：https://www.cio.com/article/302381/enterprise-architecture-in-the-agile…

本文：https://jiagoushi.pro/node/2114

今天的内容构成了名为“2021 年谁仍然对企业架构感兴趣？”系列的六个部分中的第二部分。在本系列中，我将就当今企业架构的足迹、企业架构师角色的潜在死亡、大型参与者（例如 The Open Group、AWS 或 Azure 的 TOGAF）以及EA 工具提供商的角色以及其他相关证书和市场上的发展。

在今天的第二部分中，我将深入了解第一部分的 Google 趋势分析，并对 The Open Group 的认证环境进行更深入的调查。两者都证实，尽管许多企业架构术语变得不那么重要，但实际内容仍然是最新的。

无论您是在阅读这篇文章还是在收听我网站上的播客版本，请务必尽快查看该系列的其他部分！

2021 年谁还对企业架构感兴趣？

– 第 2 部分，共 6 部分
本系列的第一部分以一些关于 EA 是否已死的问题结束——基于几个不同的发现。第二部分反对这种观点。

一个主要论点来自谷歌趋势的结果，该结果显示对一些关键 EA 搜索词的兴趣明显下降。将这一点放在上下文中，重要的是要了解谷歌搜索已经从一般术语转移。架构层的一般管理就是此类通用术语的一个示例。如今，人们对企业和 IT 架构的更具体的主题和概念感兴趣。

对特定企业架构术语的高需求

图 2 再次以蓝色显示了“企业架构”一词的搜索请求数量。这一次，它与术语“主数据”、“规模化敏捷框架”、“云原生计算基础”和“微服务”进行了比较。虽然这些关键词显然也与 EA 领域相关，但它们显示出过去几年搜索量的强劲增长。

有趣的是，子主题越具体，它们的表现就越普遍。例如，作为应用程序环境子集的“微服务”具有更高的搜索量。此外，作为数据管理子集的“主数据”总体上优于“企业架构”的搜索量。

 

换句话说，来自 Google 趋势的见解表明：通用 EA 术语的兴趣降低，而更具体的搜索术语——也是 EA 的核心——兴趣增加。

新的 TOGAF 战略

第一部分的第二个主要论点是 TOGAF 标准的更新不足以回答数字时代的组织所面临的问题。

令人惊讶的是，降低 TOGAF 的重要性甚至可能是 The Open Group 战略的一部分。在这样做的过程中，他们为加强新开发产品和指南的市场占有率留下了空间。示例包括数字从业者指南、TOGAF 业务架构指南和系列指南。

此外，The Open Group 还建立了几个新证书。其中一些涵盖了新主题，但其中一些还涵盖了人们期望成为 TOGAF 标准的一部分。将此类内容从 TOGAF 标准中剔除表明，The Open Group 的战略是实现认证多样化，而不是仅仅关注 TOGAF。

在极端情况下，它也可能意味着“TOGAF”一词作为认证可能会慢慢消失。同时，内容将转向更多和新的认证，这些认证听起来现代且更合适。然而，TOGAF 标准将不再收到显着的更新。

如果您想了解更多相关信息，请务必查看下面提供的我的其他文章的链接。

另外，非常感谢您对本系列第一部分的积极反馈和评论。你同意还是不同意第二部分的主要论点？很高兴在下面的评论部分继续讨论！

原文：https://digitalroadmap-management.medium.com/new-enterprise-architectur…

本文：https://jiagoushi.pro/new-enterprise-architecture-terms-and-certificate…

领先的 CIO 正在构建“刚刚好”的企业架构，以平衡速度与长期战略洞察力，以实现更好的业务价值。

在 Vault Health，首席技术官 Steve Shi 开始企业架构 (EA) 工作，他对整个 IT、应用程序、系统和数据基础架构进行了现场调查，但将其限制在两周内，并针对每个功能进行一小时的采访。

Shi 说，客户，无论是员工还是为产品或服务付费的人，都必须“喜欢”这种最低可行的 EA 方法的结果。 “如果你没有得到客户的认可，你就会失去动力，如果你失去动力，在最小可行的发布之后继续迭代就更难了，”他说。

像许多 IT 领导者一样，施正试图在未使用的复杂架构研究和缺乏足够范围和深度以提供持久价值的简陋 EA 报告之间取得平衡。找到这种平衡需要紧贴业务需求，削减繁重的工作，适当地确定项目范围，并设置和执行正确的架构标准和原则。以下是熟悉该流程的 CIO 推荐的五个步骤。

贴近业务

与业务利益相关者保持密切沟通是了解最小可行企业架构在哪里可以最好地帮助业务并随着业务需求的变化为持续的 EA 评估提供资金的唯一途径。

在 Carrier Global Corp.，CIO Joe Schulz 通过业务指标来衡量 EA 的成功，例如员工生产力如何受到应用程序质量或服务中断的影响。

Schulz 说：“我们不会将企业架构视为一群看门人，他们在本质上对某件事情应该如何工作有更多的理论性。”他使用 EA 工具 LeanIX 生成的报告和见解来描述生态系统的互连性以及整个产品组合的系统功能，以识别冗余或差距。这使得智能建筑和冷链解决方案的全球供应商能够“使许多决策民主化……（以）在我们的组织中发挥所有最佳思维和投资能力。”

破产技术和服务公司 Stretto 的首席技术官 George Tsounis 建议使用 EA 来“建立信任和透明度”，方法是告知业务领导者当前的 IT 支出以及平台与业务战略不一致的领域。他说，这使得未来与 EA 相关的对话“比企业架构师在孤岛中工作并且没有这种关系要容易得多”。

修剪繁文缛节

冗长的问卷调查和模板驱动的访谈是 EA 工作中常见但通常不受欢迎的一部分。最低可行的 EA 从业者建议消除任何不能提供基本信息并允许用户反馈的问题。

云超大规模企业 Amazon Web Services 的企业战略总监 Gregor Hohpe 建议从“重量级、主要是单向”的 EA 流程转变为与业务用户进行更简单、更快和迭代的对话。

在金融服务公司 State Street，全球首席架构师 Aman Thind 试图通过只提出精确且相关的问题而不是 EA 模板中的所有问题来简化 EA 流程。他说，专注于最重要的问题可以将架构审查和提交所需的时间减少至少一半，并使流程更加有效。例如，SaaS 应用程序用来提供用户界面的框架不如确定用户如何与其交互的身份和访问管理程序重要。

除了使用自动合规检查和自助服务平台外，Hohpe 还建议消除“大量被忽略的标准列表”，召开审查会议，所有文件都根据各自团队的首选结果进行逆向工程，“调整”会议增值主题，以及“从从未用于决策的重量级 EA 工具生成巨大的挂毯”。

在数字医疗保健公司 Vault，Shi 发现应用程序可观察性工具 New Relic 通过提供对整个架构的即时可见性，在加速 EA 工作方面很有价值。

 他还使用新的术语和流程来避免常见的减速，并让人们意识到他的新颖方法。一个例子是“网站报告”，它要求用户设想最终的 EA 产品。这有助于定义关键要求，例如应用程序必须支持的事务数量和流程类型，“来自客户端并向后工作”。 Shi 没有使用要求用户预先就关键技术决策达成一致的“一次性完成”流程，而是要求他们确认或修改“开发假设”，例如系统每天必须支持的数据库调用数量。他说，这种方法可以加快就数据库等组件的选择达成一致。

在应用程序推出期间，Shi 避免使用通用项目计划，而是采用他所谓的“特定宏排序计划”，即围绕里程碑（如 alpha 和 beta 测试及其相关的验证里程碑）构建的步骤。这为部署的每个阶段定义了业务方面的成功，例如收入或用户采用率以及从降低持续支持成本的支持流程中吸取的经验教训。他说，这也提醒每个人，“在我们知道架构已经交付了可衡量的客户价值之前，项目不会结束。”

范围正确

在一个最小可行的 EA 项目中承担太多，在完成之前它就会过时，交付结果太晚，无法满足并从商业领袖那里获得未来的资金。将其缩小太多，将无法提供充分利用 IT 投资所需的技术和业务的全面视图。达到适当的平衡通常需要专注于业务中的一个应用程序或痛点，或者由于新的业务或监管需求而导致需求快速变化的领域。

Gartner Inc. 副首席分析师 Nolan Hart 将适当的 EA 范围称为“最少数量的可交付成果，例如观点、参考模型和设计模式，有助于确保及时、合规地交付产品和解决方案。”他建议，与其花太多时间了解当前架构，不如“首先了解你想要的结果”。他说，“永远、永远、永远地迷失记录你当前功能失调的架构”是没有价值的。

Shi 建议最小可行的 EA 考虑“从用户界面到将系统链接到数据架构的 API 的所有内容，而不是单个孤立的组件或服务。”他说，提议的架构还必须能够在生产规模上进行测试，并且能够处理与它所取代的系统相同的峰值需求。

适当的范围也适用于 EA 组织。 Carrier 不是专门的 EA 团队，而是为 CRM、现场服务、ERP、分析和数字工厂功能等关键需求创建了卓越中心。 Schulz 说，这些中心提供了核心组件的简化基础，使其能够快速创新，而无需进行 EA 练习来评估每个业务部门的单独平台。

如果企业中的一个小组对最小可行的 EA 项目不感兴趣，“还有很多其他人会花时间，”Hart 说。将该需求与 EA 团队的技能相匹配，以确定“您可以提供的三到五种服务，以用最小可行的方法交付这些业务成果”。

制定和执行标准

Tsounis 说，实施设计原则以及关注业务需求有助于缩短“关于哪种解决方案最佳的哲学争论”。他鼓励的原则包括“始终尝试创建尽可能简单的解决方案，不要过度设计，允许在整个组织中最大限度地重用，在构建新东西之前利用已建立的架构设计模式以及基于云的服务。”

Thind 说，网络安全、数据治理、生产管理和部署最佳实践等领域的参考架构和标准提供了“现成的剧本”，可以有效地构建健壮、合规和弹性的可组合应用程序。此类架构由“定义非常明确……在 API、可扩展性和互操作方式方面”的微服务构建，允许企业在不影响任何其他微服务的情况下替换任何微服务，从而创建面向未来的设计。

Hohpe 说，一些标准扼杀了创新，而另一些则促进了创新。例如，统一接口对于创建易于适应的架构至关重要。然而，过于严格的标准会导致糟糕的技术选择。他记得有一个应用程序团队选择 XML 作为组件接口而不是更快的通信协议。当被问及原因时，该团队回答说架构团队需要它，显然没有考虑 XML 解析对应用程序性能的不利影响。

从某个地方开始

如果不出意外，Thind 说，任命一名“......首席架构师，一名高管评估整体标准、整体治理、整体平台和应用程序设计的整体纪律。仅仅担任这个职位就表明了架构对整个公司的重要性，并灌输了我们创建高效和创新 IT 组织所需的正确行为。”

开始一个最小可行的企业架构可以从简单地“盘点”开始，Thind 说，识别超支，例如“为什么我们有六个不同的应用程序用于相同的流程，五个不同的合同（用于）相同的 BI 工具，多个市场数据合同范围相同，24×7 Hadoop 集群用于月度报告，等等。”但即使是这种最低限度的可行努力也能带来巨大的好处。 “只要确保将正确的工具用于正确的工作，并且围绕它们的使用进行标准化和最佳实践，就可以对底线产生相当大的影响，并减少技术债务，减少支持需求，并允许更快的创新，”他说。

原文：https://www.cio.com/article/307187/5-steps-to-minimum-viable-enterprise…

本文：https://jiagoushi.pro/node/2103

颠覆性时代需要有弹性、前瞻性的企业架构。 不要让错误的框架破坏您的组织实现当前和未来目标的能力。

企业架构为成功的业务 IT 计划奠定了基础。如果设计和实施得当，企业架构将帮助业务领导者实现他们的目标，使组织变得更具响应性、效率和竞争力。

不幸的是，仅仅几个常见的错误就会使企业架构无法满足其设计者的预期目标。事实上，随着时间的推移，有缺陷的企业架构可能会将企业引向完全错误的方向。

在开发或更新您的企业架构时，请退后一步，确保它没有落入以下七个陷阱中的任何一个。

1. EA 工作与业务需求不一致

企业领导者可能会设计一个连贯、详细的架构，但除非它专注于现实世界的业务需求，否则它不会在长期内取得成功。

在计划开始之前，通信基础设施服务提供商 Zayo 的首席信息官 Ginna Raahauge 建议收集企业最具影响力的用例，以对现有企业架构进行压力测试，以发现潜在的漏洞。她建议，确保用例是相关的。 “如果您遇到订单准确性方面的挑战，[例如]，请务必考虑导致前端和后端出现这种情况的原因，以及架构的变化如何解决这个问题。”

Raahauge 认为企业架构永远不会真正完成。 “它是活生生的，”她说。 Raahauge 建议至少每五年重新审视一次企业架构。 “随着技术的发展速度越来越快，我们需要能够在五年的技术变革中幸存下来，”她解释道。

2. 不采取客户至上的方法

商业和 IT 咨询公司 Capgemini 的副总裁 Phillip Hattingh 表示，在设计企业架构时，将设计计划与以客户为中心的方法保持一致非常重要。他说，应在整个设计过程中启用以客户为中心的目标和结果 KPI，促进真正的全渠道客户旅程，解决数字和物理相互作用。 “设计将如何实现组织的预期结果应该是明确的，并且可以很好地沟通，以支持成功的转型。”

以客户为中心的企业架构设计方法标志着对传统以产品为中心的模型的重大改变。 “客户至上的方法将挑战传统模式，并有可能导致未来的运营模式发生变化，”Hattingh 指出。 “如果不采用以客户为中心的设计，组织也可能会失去市场竞争力。”

3. 忽视集中核心目标和能力

无法集中核心业务目标和能力的企业架构注定会产生或保留孤岛。

Adobe 前首席企业数字政府解决方案技术总监乔纳森·贝内特警告说：“当不同的办公室和部门遇到相同的挑战并部署经常重叠的解决方案时，他们会陷入冗余、低效的系统中，从而阻碍实现业务目标的进展。”美国农业部建筑师。 “此外，一旦工作流被孤立，实施任何企业架构都会变得越来越困难。”

Benett 说，在担任政府机构企业架构师期间，他目睹了孤岛的破坏性影响。 “拥有预算和人力资本来解决当前问题的办公室将开发自己的应用程序和方法，而不是构建具有多种用途并满足跨机构需求的应用程序的平台，”他说。 “当办公室和部门分开工作时，他们倾向于反对精简……因为他们缺乏对整体业务目标的好处的可见性。”

拆除孤立的企业架构的一种有效方法是邀请代表主要业务功能的团队对他们所有的数字工具进行分类，包括应用程序、网站和劳动力管理程序。然后包括企业范围的流程和策略。 Benett 说，一旦创建了这个包罗万象的目录，就可以识别并建立差距和优势。 “从那里，能力驱动的业务架构可以开始形成，”他指出。

4. 将技术置于灵活性和业务目标之前

医疗数据和软件公司 Arcadia 的首席技术官 Jonathan Cook 表示，在开发企业架构时，很容易陷入以技术为中心的世界观，而忽略了商业价值模型。 “业务需求在不断变化，作为技术领导者和专业人士，我们需要支持、支持和加速这种变化。”

当被以技术为中心的前景蒙蔽或束缚时，企业领导者可能会发现自己陷入了争论各种技术方法的优越性，而不是专注于如何支持当前和未来的业务需求。 “如果我们不能提供灵活、有弹性的架构，我们可能会阻碍我们的组织有效竞争，”库克警告说。 “在这场大流行的过去 18 个月中，我们看到能够迅速适应不断变化的市场条件的企业能够生存甚至蓬勃发展。”

5. 困在当下

在没有预见未来增长需求的情况下开发的企业架构可能最终会失败。保险经纪公司 World Insurance 的首席信息官/首席信息安全官 Liz Tluchowski 说：“如果没有路线图，您将遇到创造效率的限制，以及支持业务目标的限制。” “当你发现你所构建的东西不能满足企业的运营需求时，你还将面临重新发明轮子的额外费用。”

Tluchowski 建议在构建任何随着企业发展和/或业务需求变化而可能需要可扩展性的系统时保持开放的心态。 “使用以其开放式架构而闻名的平台和服务，因为技术永远在变化，即使您制定了计划，也有很多不可预测的事情。”

6. 安全漏洞

随着网络威胁形势的发展，企业架构在过去几年中被迫改变。网络安全技术公司 Deep Instinct 的网络安全倡导主管 Chuck Everette 说：“在过去，安全是一种附加或事后的想法。 “安全性现在是企业架构和设计的核心和前沿，”他指出。 “其他一切都建立在它之上或周围。”

哈里斯堡科技大学网络安全管理研究生项目的负责人 Bruce Young 警告说，在企业架构设计阶段开始时不包括安全是一个危险的错误，因为系统、应用程序和数据可能会受到威胁。 “网络威胁不断增加，对组织的成功网络攻击每天都在发生，因此必须从设计阶段开始将安全纳入企业架构流程。”

Everette 说，基本的安全考虑必须在设计和规划阶段以及最终签核前的测试和验证中进行，他建议在企业架构开发中采用安全设计方法。 “Security-by-design 根据业务风险、价值以及违规和漏洞的影响强制执行设计的优先级。”

7. 追求完美

大多数才华横溢的人，包括 IT 和业务人员，都希望构建完美的东西。虽然完美可能是一个令人钦佩的目标，但在开发企业架构时，这并不是一个特别好的追求，尤其是在面向未来的架构或规模化构建时。

云计算服务提供商 Fastly 的工程副总裁 Laura Thomson 解释说：“这当然很重要，但过度旋转会导致大量问题，主要是各种过度构建和过度架构。”

汤姆森警告说，为企业构建管理层希望在五年内拥有的完美架构将导致复杂性和成本大幅增加。 “它推迟了交付期限，使系统构建速度变慢，更容易出错和中断，并推高了成本。”

Thomson 建议瞄准一个只是好的架构，而不是完美的架构。 “完美的系统并不存在，”她说。获得 80% 的短期解决方案，为企业带来价值。 “你可以而且应该迭代改进，”汤姆森补充道。

本文:https://jiagoushi.pro/node/2110

企业架构是组织标准化和组织IT基础架构以符合业务目标的过程。这些战略支持数字化转型、IT增长和IT现代化。

企业架构定义

企业架构（EA）是分析、设计、规划和实施企业分析以成功执行业务战略的实践。EA帮助组织构建IT项目和策略，以实现期望的业务结果，在快速变化面前保持敏捷和弹性，并使用架构原则和实践（也称为企业架构规划（EAP））来掌握行业趋势和中断。

现代EA战略现在将这一理念扩展到整个企业，而不仅仅是IT，以确保企业与数字化转型战略和技术增长保持一致。EA对于正在进行数字化转型的大型企业尤其有用，因为它专注于将遗留流程和应用程序结合在一起，以形成更无缝的环境。

企业架构目标

EA以组织的业务需求为指导——它有助于规划信息、业务和技术如何一起流动。这已经成为那些试图跟上云、物联网、机器学习等新技术以及其他推动数字化转型的新兴趋势的企业的优先事项。

根据EABOK，该过程是由“从所有者、设计师和建设者的角度对整个企业进行全面描述”驱动的。与其他框架不同，EA不包含正式的文档结构；相反，它旨在为企业提供更全面的视角。

EA的另一个主要优先事项是敏捷性，确保您的EA战略高度关注敏捷性和敏捷采用。有了可靠的EA战略，公司可以更好地应对复杂和快速变化，甚至可以让您的组织在动荡时期茁壮成长。在最近的Bizzdesign调查中，EA成熟度排名前四分之一的组织报告组织敏捷性的可能性要高出三倍，这在过去几年的新冠肺炎疫情中至关重要。只有20%的受访者表示，他们的EA计划允许更快的创新和更快的上市时间，而只有6%的受访者声称企业架构师被纳入敏捷团队，并有权影响技术决策。

一个好的EA战略考虑业务流程、组织结构、敏捷性、信息系统和技术方面的最新创新。它还将包括业务流程的标准语言和最佳实践，包括分析可以在整个组织中集成或消除哪些流程。任何好的EA战略的目标都是提高业务信息的效率、及时性和可靠性。当然，要实施任何EA战略，您还需要确保获得其他高管和利益相关者的支持。

然而，EA及其目标在不断发展。根据Bizdesign对1000多名企业架构师和IT业务领导者的调查，2022年提高EA影响的首要任务包括改善EA对业务价值的沟通（56%）以及改进EA流程的开发和采用（50%）。其他优先事项包括提供更多的战略见解（41%），从高级管理层获得更积极的支持（33%），以及投资额外的EA资源、培训和认证（32%）。

企业架构的好处

企业架构有几个好处，包括弹性和适应性、管理供应链中断、员工招聘和保留、改进产品和服务交付以及跟踪数据和API。EA可以为重新设计和重组提供支持，特别是在重大组织变更、合并或收购期间。通过标准化和整合流程以提高一致性，这也有助于为组织带来更多的纪律。

Bizdesigns询问了受访者，他们的EA计划目前提供了哪些IT好处，最高的回答是改进了IT投资决策。其他好处包括通过API和云改进服务导向、合理化和成本更低的应用程序组合、降低不支持技术的风险和成本、改进信息管理和安全性、重用现有IT资产的解决方案、更好的性能和弹性、更快更成功的实施和更新以及更好的自动化。

在业务效益方面，受访者列举了能力与战略、业务投资决策、合规性和风险管理、业务流程、职能之间的协作、业务洞察力、业务敏捷性和连续性以及更快的上市和创新时间的一致性方面的改进。与EA成熟度落后的公司相比，领先于EA成熟度的公司更有可能从公司的EA战略中获得这些好处。

EA还用于系统开发、IT管理和决策以及IT风险管理，以消除错误、系统故障和安全漏洞。它还可以帮助企业导航复杂的It结构，或使其他业务部门更容易访问It。

根据CompTIA，EAP的好处包括：

• 允许IT部门和业务部门之间更开放的协作
• 赋予企业优先投资的能力
• 更容易根据长期目标评估现有架构
• 建立评估和采购技术的流程
• 为IT以外的所有业务部门提供IT架构的全面视图
• 提供基准框架，将结果与其他组织或标准进行比较

企业架构方法

企业架构作为一个框架可能显得模糊，因为它旨在解决整个组织，而不是单个需求、问题或业务单元。因此，根据CompTIA的说法，已经发展了几个更具体的框架来帮助公司有效地实施和跟踪EAP，包括以下四种主要的EA方法：

• 开放组架构框架（TOGAF）：TOGAF提供了设计、规划、实施和管理企业IT架构的原则。TOGAF框架帮助企业创建标准化的EA方法，包括通用词汇、推荐标准、合规方法、建议的工具和软件以及定义最佳实践的方法。TOGAF框架作为一种企业架构框架广受欢迎，据The Open Group称，它已被全球80%以上的领先企业采用。
• Zachman企业架构框架：Zachman框架以企业架构的创始人之一命名，是另一种流行的EA方法。根据CompTIA的说法，它被更好地理解为“分类法”，它跨越了六个架构焦点和六个主要利益相关者，以帮助标准化和定义IT架构组件和输出。
• 联邦企业架构框架（FEAF）：FEAF于1996年引入，作为对克林格·科恩法案的回应，该法案在联邦机构中引入了IT有效性授权。它是为美国政府设计的，但也可以应用于希望使用该框架的私人公司。
• 高德纳：2005年收购Meta Group后，高德纳建立了EAP的最佳实践，并将其应用于公司的一般咨询实践。虽然它不是一个单独的框架，但CompTIA认为它是一种“实用”的方法，它专注于业务成果，“很少有明确的步骤或组件”

其他EA方法包括欧洲航天局架构框架（ESAAF）、国防部架构框架（MODAF）和SAP企业架构框架等。这些框架专门针对单个行业或产品，与上面列出的更广泛的EA方法相比，它们更多地针对利基市场。

企业架构师角色

企业架构师通常向CIO或其他IT经理报告。他们负责分析业务结构和流程，以确保它们与业务目标高效一致。作为一名企业架构师，您还将负责确保这些结构和流程是灵活和持久的，以便它们能够快速适应并经受住重大变化。

根据PayScale的数据，这是一个利润丰厚的职位，据报道平均年薪为137900美元，年薪范围为97000至201000美元。企业架构师通常继续担任首席技术官、软件工程或开发总监或首席信息官。

要想成为一名企业架构师，你需要计算机科学、信息技术或相关领域的本科学位，以及至少10年的IT或相关领域经验。您还需要使用计算机系统、硬盘驱动器、大型机和其他架构技术的实践经验。企业架构师需要一些软技能才能成功，包括沟通、解决问题、批判性思维、领导力和团队合作。

根据PayScale，IT企业架构师最常见的硬技能包括：

• Microsoft SharePoint Server
• Artificial intelligence (AI)
• Microsoft Azure
• Data warehouse
• Business intelligence
• Data modeling
• Strategy development
• Enterprise solutions
• Enterprise application integration
• Software architecture

有关更多信息，请参阅“成功企业架构的7个特点”

企业架构工具和软件

Microsoft Excel和PowerPoint是您将用于企业架构规划的两个最基本的工具。然而，还有其他第三方工具和软件套件可以帮助您为业务创建高级EA策略。

有很多方法可以将EA工具集成到您的组织中，以便它们支持业务中的其他系统和流程。在Bizdesign调查中，受访者被问及哪些系统和内容类型被集成到公司的EA管理工具和业务流程模型（59%）、数据建模系统（49%）、项目管理工具（35%）、ITSM工具（31%）和配置管理平台（31%）中。

根据Gartner Peer Insights的数据，以下是目前市场上流行的一些选项：

• Orbus Software
• Sparx Systems
• Software AG
• Avolution
• Mega
• Erwin
• BiZZdesign
• Planview
• SAP
• BOC Group

有关详细信息，请参阅“顶级企业架构工具”

企业架构认证

有几个证书可以证明你的EA技能，包括更具体的证书，这些证书侧重于云和安全架构等技能。

企业架构认证包括：

• TOGAF 9 Certification
• The Open group Certified Architect (Open CA)
• AWS Certified Solution Architect
• Salesforce Certified Technical Architect (CTA)
• Axelos ITIL Master certification
• Microsoft Certified: Azure Solutions Architect Expert
• Google Professional Cloud Architect
• Virtualization Council Master Infrastructure Architect certification
• CISSP Information Systems Security Architecture Professional (ISSAP)
• Dell EMC Cloud architect training and certification
• Red Hat Certified Architect
• EC Council Certified Network Defense Architect (CNDA)

See also: 12 certifications for enterprise architects.

企业架构的起源

根据《企业架构知识书》（EABOK），EA始于20世纪60年代，诞生于“杜威·沃克教授关于业务系统规划（BSP）的各种架构手稿”。沃克的学生之一约翰·扎克曼（John Zachmann）帮助将这些文档制定为EA的更结构化格式。这段时间，两人都曾为IBM工作，扎克曼于1987年在《IBM系统杂志》上发表了该框架。

EA框架是对商业技术增长的回应，尤其是在20世纪80年代，当时计算机系统刚刚在工作场所占据主导地位。公司很快意识到，他们需要一个计划和长期战略来支持技术的快速增长，这一点在今天仍然是正确的。