组织视图

什么是组织视图？

组织视图用于描述组织单元的组织结构，例如企业、公司、部门，甚至公司网络。通常，结构以嵌套的方式呈现。然而，像传统的组织结构图一样呈现并不少见。组织视图通常用于确定组织单位的能力和职责。

下表详细介绍了组织观点。

利益相关者	企业、流程和领域架构师、经理、员工、利益相关者
关注点	能力(胜任力)、权限和责任的识别
目的	设计、决定、告知
范围	单层/单角度
元素	业务参与者，业务角色，业务协作，位置，业务接口

 

组织视点示例

下图显示了在Organization视点下绘制的架构图。

业务流程合作视图

什么是业务过程协作视图?

业务流程合作视图用于对企业的主要业务流程流建模。它可用于创建业务流程的高级设计，为运营经理提供对其依赖关系的洞察。您还可以用业务功能对业务流程的映射建模，以及如何通过业务流程实现业务服务。

下表更详细地描述了业务流程协作观点。

利益相关者	流程和领域架构师、运营经理
关注点	业务流程之间的依赖关系、一致性和完整性、职责
目的	设计,决定
范围	层次/多角度
元素	业务参与者、业务角色、业务协作、位置、业务接口、业务流程/功能/交互、业务事件、业务服务、业务对象、表示、应用程序组件/协作、应用程序接口、应用程序流程/功能/交互、应用程序事件、应用程序服务、数据对象

业务流程协作观点示例

下图显示了在业务流程合作视角下绘制的Archimate图。

 

讨论：请加入知识星球【首席架构师圈】或者小号【ca_cea】或者QQ群【11107777】

 

基本视图

ArchiMate基本视图包括ArchiMate元素和ArchiMate三个主要层的概念:业务、应用程序和技术。下面列出的是ArchiMate 3.1示例视点表，分为四类，指明了它们所涵盖的方向和范围:

• 组合:定义元素的内部组合和聚合的视图。
• 支持:您所查看的元素被其他元素所支持的视图。通常从一层往上到上一层。
• 合作:朝向相互合作的对等元素。通常跨不同的方面。
• 实现:您正在查看实现其他元素的元素的视图。通常从一层向下到下一层。

 

组成视图

名字	透视图	关注点
组织	企业在角色、部门等方面的结构。	识别能力、权力和责任
信息结构	显示企业中使用的信息的结构。	使用的数据和信息的结构和依赖关系，一致性和完整性
技术	网络、设备和系统软件等企业信息系统的基础设施和平台。	基础设施的稳定性、安全性、依赖性和成本
分层	提供架构的概述。	一致性、降低复杂性、变更的影响、灵活性
物理	物理环境以及它如何与IT基础设施相关联。	物理环境的关系和依赖关系，以及它们与IT基础设施的关系

支持视图:

名字	透视图	关注点
产品	显示产品的内容。	产品开发，企业产品提供价值
应用使用	将应用程序与其在例如业务流程中的使用关联起来。	一致性和完整性，降低复杂性。
技术使用	展示应用程序如何使用技术。	依赖关系、性能、可伸缩性

合作视图:

名字	透视图	关注点
业务流程合作	显示各种业务流程之间的关系。	业务流程、一致性和完整性、责任之间的依赖关系
应用合作	显示应用程序组件及其相互关系。	应用程序之间的关系和依赖、服务的编排/编排、一致性和完整性、复杂性的降低

实现视图:

名字	透视图	关注点
服务实现	显示如何通过必要的行为实现服务。	业务流程的增值、一致性和完整性、责任
实现和部署	显示如何将应用程序映射到底层技术。	应用平台的结构以及它们与支持技术的关系

 

---

产品视图

什么是产品视图?

产品视图关注的是产品能为顾客提供的价值。它根据构成(业务、应用或技术)服务以及相关的合同或其他协议显示了产品构成。您还可以显示提供该产品的接口，以及与该产品相关的事件。产品视角通常用于为使用产品所涉及的服务建模，产品视角可以是现有服务或需要创建的新服务的组合。

下表更详细地描述了产品视图。

利益相关者	产品开发人员、产品经理、流程和领域架构师
关注点	产品开发，企业产品所提供的价值
目的	设计，决定
范围	多个层/多个方面
元素	业务参与者、业务角色、业务协作、业务接口、业务流程/功能/交互、业务事件、业务服务、业务对象、产品、合同、应用组件/协作、应用接口、应用流程/功能/交互、应用事件、应用服务、数据对象、技术服务、人工制品、材料、价值

产品的视图的例子

下图显示了在产品视角下绘制的Archimate图。

应用合作的视图

什么是应用程序合作视图?

应用程序合作视角展示了应用程序组件之间的信息流，以及组件提供和要求的服务。人们使用这个视点来创建应用程序前景的概览。此外，这个视图还可以用于建模服务之间的协作，这些服务共同支持业务流程的执行。

下表更详细地描述了应用程序合作视图。

利益相关者	企业、流程、应用程序和领域架构师
关注点	应用程序之间的关系和依赖，服务的编制/编排，一致性和完整性，复杂性的降低
目的	设计
范围	多层/多方面
元素	位置、应用程序组件/协作、应用程序接口、应用程序流程/功能/交互、应用程序事件、应用程序服务、数据对象

应用程序合作视图示例

下图显示了在应用程序合作视角下绘制的原型图。

原文：https://www.visual-paradigm.com/guide/archimate/full-archimate-viewpoints-guide/

本文：http://jiagoushi.pro/node/1311

全网同号：【首席架构师智库】

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

基本视图

ArchiMate基本视图包括ArchiMate元素和ArchiMate三个主要层的概念:业务、应用程序和技术。下面列出的是ArchiMate 3.1示例视点表，分为四类，指明了它们所涵盖的方向和范围:

• 组合:定义元素的内部组合和聚合的视图。
• 支持:您所查看的元素被其他元素所支持的视图。通常从一层往上到上一层。
• 合作:朝向相互合作的对等元素。通常跨不同的方面。
• 实现:您正在查看实现其他元素的元素的视图。通常从一层向下到下一层。

 

组成视图

名字	透视图	关注点
组织	企业在角色、部门等方面的结构。	识别能力、权力和责任
信息结构	显示企业中使用的信息的结构。	使用的数据和信息的结构和依赖关系，一致性和完整性
技术	网络、设备和系统软件等企业信息系统的基础设施和平台。	基础设施的稳定性、安全性、依赖性和成本
分层	提供架构的概述。	一致性、降低复杂性、变更的影响、灵活性
物理	物理环境以及它如何与IT基础设施相关联。	物理环境的关系和依赖关系，以及它们与IT基础设施的关系

支持视图:

名字	透视图	关注点
产品	显示产品的内容。	产品开发，企业产品提供价值
应用使用	将应用程序与其在例如业务流程中的使用关联起来。	一致性和完整性，降低复杂性。
技术使用	展示应用程序如何使用技术。	依赖关系、性能、可伸缩性

合作视图:

名字	透视图	关注点
业务流程合作	显示各种业务流程之间的关系。	业务流程、一致性和完整性、责任之间的依赖关系
应用合作	显示应用程序组件及其相互关系。	应用程序之间的关系和依赖、服务的编排/编排、一致性和完整性、复杂性的降低

实现视图:

名字	透视图	关注点
服务实现	显示如何通过必要的行为实现服务。	业务流程的增值、一致性和完整性、责任
实现和部署	显示如何将应用程序映射到底层技术。	应用平台的结构以及它们与支持技术的关系

----------

应用程序使用视图

什么是应用程序使用视图?

应用程序使用观点显示了应用程序如何协同工作以支持业务流程，以及其他应用程序如何使用应用程序。它可用于标识业务流程和其他应用程序所需的服务，或用于通过描述可用的服务来设计业务流程。

下表更详细地描述了应用程序使用观点。

利益相关者	企业、流程和应用程序架构师、运营经理
关注点	一致性和完整性，减少复杂性
目的	设计,决定
范围	多个层/多个方面
元素	业务参与者、业务角色、业务协作、业务过程/功能/交互、业务事件、业务对象、应用程序组件/协作、应用程序接口、应用过程/功能/交互、应用程序事件、应用程序服务、数据对象

应用程序使用视图示例

下图显示了在应用程序使用观点下绘制的原始图。

 

实现和部署视图

什么是实现和部署视图?

实现和部署视角显示了基础设施上应用程序的实现。这涉及到将应用程序和组件映射到工件，以及将这些应用程序和组件使用的信息映射到底层存储基础设施。

下表更详细地描述了实现和部署观点。

利益相关者	应用程序和领域架构师
关注点	应用程序平台的结构以及它们与支持技术的关系
目的	设计,决定
范围	多层次/多角度
元素	应用组件/协作、应用接口、应用过程/功能/交互、应用事件、应用服务、数据对象、系统软件、技术接口、路径、技术过程/功能/交互、技术服务、构件

 

实现和部署视角示例

下图显示了在实现和部署视角下绘制的原型图。

 

原文：https://www.visual-paradigm.com/guide/archimate/full-archimate-viewpoints-guide/

本文：http://jiagoushi.pro/node/1313

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

基本视图

ArchiMate基本视图包括ArchiMate元素和ArchiMate三个主要层的概念:业务、应用程序和技术。下面列出的是ArchiMate 3.1示例视点表，分为四类，指明了它们所涵盖的方向和范围:

• 组合:定义元素的内部组合和聚合的视图。
• 支持:您所查看的元素被其他元素所支持的视图。通常从一层往上到上一层。
• 合作:朝向相互合作的对等元素。通常跨不同的方面。
• 实现:您正在查看实现其他元素的元素的视图。通常从一层向下到下一层。

 

组成视图

名字	透视图	关注点
组织	企业在角色、部门等方面的结构。	识别能力、权力和责任
信息结构	显示企业中使用的信息的结构。	使用的数据和信息的结构和依赖关系，一致性和完整性
技术	网络、设备和系统软件等企业信息系统的基础设施和平台。	基础设施的稳定性、安全性、依赖性和成本
分层	提供架构的概述。	一致性、降低复杂性、变更的影响、灵活性
物理	物理环境以及它如何与IT基础设施相关联。	物理环境的关系和依赖关系，以及它们与IT基础设施的关系

支持视图:

名字	透视图	关注点
产品	显示产品的内容。	产品开发，企业产品提供价值
应用使用	将应用程序与其在例如业务流程中的使用关联起来。	一致性和完整性，降低复杂性。
技术使用	展示应用程序如何使用技术。	依赖关系、性能、可伸缩性

合作视图:

名字	透视图	关注点
业务流程合作	显示各种业务流程之间的关系。	业务流程、一致性和完整性、责任之间的依赖关系
应用合作	显示应用程序组件及其相互关系。	应用程序之间的关系和依赖、服务的编排/编排、一致性和完整性、复杂性的降低

实现视图:

名字	透视图	关注点
服务实现	显示如何通过必要的行为实现服务。	业务流程的增值、一致性和完整性、责任
实现和部署	显示如何将应用程序映射到底层技术。	应用平台的结构以及它们与支持技术的关系

技术视角

什么是技术视角?

技术视角显示了软件和硬件技术元素(如物理设备、网络或系统软件(例如，O/S、数据库和中间件)如何支持应用层。

下表更详细地描述了技术视角。

利益相关者	基础设施架构师、运营经理
关注点	稳定性、安全性、依赖性、基础设施的成本
目的	设计
范围	单层/多角度
元素	位置、节点、技术协作、设备、系统软件、技术接口、通讯网络、路径、技术过程/功能/交互、技术服务、技术事件、工件

 

技术视角的例子

下图显示了在技术视角下绘制的原始图。

技术使用视角

什么是技术使用视角?

技术使用视角显示了软件和硬件技术如何支持应用程序。当需要进行性能或可伸缩性分析时，通常会应用这种观点，因为它将物理基础设施与应用程序的逻辑世界联系起来。

下表更详细地描述了技术使用视角。

利益相关者	应用程序、基础设施架构师、运营经理
关注点	依赖性、性能、可伸缩性
目的	设计
范围	多层次/多角度
元素	应用组件/协作、应用过程/功能/交互、应用事件、数据对象、节点、设备、技术协作、系统软件、技术接口、通信网络、路径、技术过程/功能/交互、技术服务、技术事件、工件

 

技术使用视角示例

下图显示了在技术使用视角下绘制的原始图。

原文：https://www.visual-paradigm.com/guide/archimate/full-archimate-viewpoints-guide/#technology-viewpoint

本文：http://jiagoushi.pro/node/1314

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

基本视图

ArchiMate基本视图包括ArchiMate元素和ArchiMate三个主要层的概念:业务、应用程序和技术。下面列出的是ArchiMate 3.1示例视点表，分为四类，指明了它们所涵盖的方向和范围:

• 组合:定义元素的内部组合和聚合的视图。
• 支持:您所查看的元素被其他元素所支持的视图。通常从一层往上到上一层。
• 合作:朝向相互合作的对等元素。通常跨不同的方面。
• 实现:您正在查看实现其他元素的元素的视图。通常从一层向下到下一层。

 

组成视图

名字	透视图	关注点
组织	企业在角色、部门等方面的结构。	识别能力、权力和责任
信息结构	显示企业中使用的信息的结构。	使用的数据和信息的结构和依赖关系，一致性和完整性
技术	网络、设备和系统软件等企业信息系统的基础设施和平台。	基础设施的稳定性、安全性、依赖性和成本
分层	提供架构的概述。	一致性、降低复杂性、变更的影响、灵活性
物理	物理环境以及它如何与IT基础设施相关联。	物理环境的关系和依赖关系，以及它们与IT基础设施的关系

支持视图:

名字	透视图	关注点
产品	显示产品的内容。	产品开发，企业产品提供价值
应用使用	将应用程序与其在例如业务流程中的使用关联起来。	一致性和完整性，降低复杂性。
技术使用	展示应用程序如何使用技术。	依赖关系、性能、可伸缩性

合作视图:

名字	透视图	关注点
业务流程合作	显示各种业务流程之间的关系。	业务流程、一致性和完整性、责任之间的依赖关系
应用合作	显示应用程序组件及其相互关系。	应用程序之间的关系和依赖、服务的编排/编排、一致性和完整性、复杂性的降低

实现视图:

名字	透视图	关注点
服务实现	显示如何通过必要的行为实现服务。	业务流程的增值、一致性和完整性、责任
实现和部署	显示如何将应用程序映射到底层技术。	应用平台的结构以及它们与支持技术的关系

本节主要介绍信息结构视图和服务实现视图：

信息结构的视图

什么是信息结构视图?

信息结构视图的工作原理类似于开发信息系统时通常创建的传统信息模型。视点显示了企业中使用的信息的结构。它还可以显示业务层的信息如何在应用程序层以所使用的数据结构的形式表示，以及如何将这些信息映射到底层技术基础设施。

下表更详细地描述了信息结构视点。

利益相关者	领域和信息架构师
关注点	使用的数据和信息的结构和依赖关系，一致性和完整性
目的	设计
范围	多层/单一方面
元素	业务对象、表示、数据对象、工件、含义

 

信息结构视图示例

下图显示了在信息结构视点下绘制的ArchiMate图。

服务实现的视图

什么是服务实现视图?

服务实现视角为业务服务如何由底层流程/应用程序组件实现建模。

下表更详细地描述了服务实现的视图。

利益相关者	流程和领域架构师、产品和运营经理
关注点	业务流程的附加值、一致性和完整性、责任
目的	设计,决定
范围	多层/多方面
元素	业务参与者、业务角色、业务协作、业务接口、业务流程/功能/交互、业务事件、业务服务、业务对象、表示、应用组件/协作、应用接口、应用流程/功能/交互、应用事件、应用服务、数据对象

 

服务实现视图示例

下图显示了在服务实现视角下绘制的ArchiMate图。

 

原文：https://www.visual-paradigm.com/guide/archimate/full-archimate-viewpoints-guide/

本文：http://jiagoushi.pro/node/1317

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

基本视图

ArchiMate基本视图包括ArchiMate元素和ArchiMate三个主要层的概念:业务、应用程序和技术。下面列出的是ArchiMate 3.1示例视点表，分为四类，指明了它们所涵盖的方向和范围:

• 组合:定义元素的内部组合和聚合的视图。
• 支持:您所查看的元素被其他元素所支持的视图。通常从一层往上到上一层。
• 合作:朝向相互合作的对等元素。通常跨不同的方面。
• 实现:您正在查看实现其他元素的元素的视图。通常从一层向下到下一层。

 

组成视图

名字	透视图	关注点
组织	企业在角色、部门等方面的结构。	识别能力、权力和责任
信息结构	显示企业中使用的信息的结构。	使用的数据和信息的结构和依赖关系，一致性和完整性
技术	网络、设备和系统软件等企业信息系统的基础设施和平台。	基础设施的稳定性、安全性、依赖性和成本
分层	提供架构的概述。	一致性、降低复杂性、变更的影响、灵活性
物理	物理环境以及它如何与IT基础设施相关联。	物理环境的关系和依赖关系，以及它们与IT基础设施的关系

支持视图:

名字	透视图	关注点
产品	显示产品的内容。	产品开发，企业产品提供价值
应用使用	将应用程序与其在例如业务流程中的使用关联起来。	一致性和完整性，降低复杂性。
技术使用	展示应用程序如何使用技术。	依赖关系、性能、可伸缩性

合作视图:

名字	透视图	关注点
业务流程合作	显示各种业务流程之间的关系。	业务流程、一致性和完整性、责任之间的依赖关系
应用合作	显示应用程序组件及其相互关系。	应用程序之间的关系和依赖、服务的编排/编排、一致性和完整性、复杂性的降低

实现视图:

名字	透视图	关注点
服务实现	显示如何通过必要的行为实现服务。	业务流程的增值、一致性和完整性、责任
实现和部署	显示如何将应用程序映射到底层技术。	应用平台的结构以及它们与支持技术的关系

本节主要介绍物理视图和分层视图：

物理视图

什么是物理视图？

物理视图显示可以创建、使用、存储、移动或转换材料的设备，以及如何通过分发网连接设备，以及分配给设备的其他活动元素。

下表详细描述了物理视图。

利益相关者	基础设施架构师、运营经理
关注点	物理环境的关系和依赖性，以及这与IT基础设施的关系
目的	设计
范围	多层/多方面
元素	位置、节点、设备（Device）、设备（Equipment）、设施（Facility）、路径、通信网络、分发网络、材料

 

物理视图示例

下图显示了在物理视角下绘制的架构图。

分层视图

什么是分层视图？

分层视点提供了企业架构所有层和方面的核心元素的鸟瞰图。完全分层视图背后的结构原理是，每个专用层通过“实现”关系公开服务层，服务层进一步“服务”下一个专用层。通过这个视图，您可以很容易地将专用层的内部结构和组织与其外部可观察的行为（表示为专用层实现的服务层）分开。

下表详细描述了分层视点。

利益相关者	企业、流程、应用程序、基础设施和领域架构师
关注点	一致性、降低复杂性、变化的影响、灵活性
目的	设计、决定、告知
范围	多层/多方面
元素	<所有核心元素和所有关系在这个视图中都是允许的>

 

分层视图示例

下图显示了在分层视点下绘制的架构图。

原文：https://www.visual-paradigm.com/guide/archimate/full-archimate-viewpoints-guide/

本文：http://jiagoushi.pro/node/1321

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

我已经在 ICT 行业工作了一段时间。 我刚开始一份新工作，在第一次客户参与开始之前我有一些时间，所以我想我会好好利用这些时间，并考虑在不参加课程的情况下通过 TOGAF 9 认证。 我有一些自学材料、视频和练习考试，所以我并不完全靠我自己，但肯定有很多材料要读。 我想我会分享我的笔记，也许他们会帮助其他人抓住牛角。

过去，由于 TOGAF 标准的高度理论性质，即使我曾担任技术领导职务，我的上级也没有真正看到认证的必要性。在年度绩效评估中，我曾多次说我想参加企业架构培训。有些年我没有得到许可，有些年我更喜欢接受其他培训，所以我从来没有时间完成它。现在 EA 是我工作的主要部分，获得认可肯定会对我有利。

TOGAF 9.2 的高级视图

完整的标准由五个部分组成。审查所有五个确实需要相当长的时间，如果您完全按照自己的时间完成，可能需要长达两个月的时间。由于我现在或多或少地全职工作，而且我有一些背景知识，我希望我能更快地采用这些信息。当然，由于信息量太大，我需要调整自己的节奏并以可消化的方式工作。我已经将这些笔记分解成这样的块，所以最好分段阅读它们。

就像在敏捷方法中一样，TOGAF 从某种宣言开始。伟大的想法是在企业和解决方案级别重用通用解决方案。通过创建可交付成果、工件和构建块 (ABB)，将架构连续统一体的宏大思想变为现实。 TOGAF 在四个不同的架构域 (BDAT) 中工作：业务、数据、应用程序和技术。帮助您定义的工具在架构内容框架以及如何在架构能力框架中设置架构实践中进行了描述。

TOGAF 的实际主要设计框架架构开发方法 (ADM) 围绕四个领域工作，由 8 个阶段 (A-H) 组成。您需要能够详细描述每个阶段的目标、步骤和可交付成果。此外还有初步阶段和需求管理。该标准的很大一部分用于描述每个阶段的工具和文档实践。

需求管理

在非常重要的 TOGAF 图中，所有阶段都围绕需求管理展开，因此这实际上是开始了解 ADM 的好地方。有趣的是，它实际上是在标准中最后引入的，因为它代表了架构设计的持续服务模式。在许多情况下，作为一名建筑师，您不会从一个绿色领域开始，而是跳进一辆移动的火车，并使用现有的输入。当前的解决方案和相应的需求已经记录在架构存储库中，存在架构愿景以及可交付成果和工件。

期望作为新的企业架构师，您将按照此阶段的步骤确定基线需求的优先级，识别新需求或变更需求的影响，并相应地更新需求存储库。此阶段的输出是具有冲突和优先级的影响评估，其中考虑了成本、时间表和业务指标。正确的方法是动态的，并且依赖于周围的 ADM 阶段。您应该考虑所有假设、约束、原则、政策、标准、组织指南和要求规范。

注意：我已突出显示每个阶段您需要了解的关键变量（输入、步骤、输出、方法）

初步阶段

一旦进入蓝月亮，您可能会遇到您所服务的公司没有现有的架构实践的情况。初步阶段就是为您提供建立架构指导流程的框架，并对其进行定制以适应公司的需求。老实说，对于大多数入门级企业架构师来说，您不会被分配这样的工作，但是了解该标准有助于您在熟悉现有实践时提出有关存储库的正确问题。

令人困惑的是，初步已添加到 ADM 图中，作为主圈之外的附加元素。如果您考虑一下，这是有道理的，因为在您运行节目时它并没有真正发挥作用。作为输入，您将拥有 TOGAF 和您想要使用的任何其他框架。您还需要了解业务和现有文档实践。作为输出，您应该组织模型和定制的架构框架。如果您认真完成所有步骤，您应该拥有您的第一个架构存储库。

您需要采取的步骤是定义谁将受到您所做设计的影响（范围），确认管理支持（治理），确保分配所有关键角色（团队）并确定背景（指导原则）。如果你做了所有这些，你应该能够定制你的工作方法（术语、过程和上下文分类）。困难的部分是想出策略和工具来真正让它发挥作用，从而实现你的架构能力成熟度目标。

概括

了解 TOGAF 的第一天到此结束。我们已经对标准的部分内容进行了高级审查，您现在知道 ADM 是如何开始和结束的。在下一篇文章中，我将写更多关于架构领域的内容，在以后的日子里，我们将回顾每个阶段。最终，如果您阅读了本系列的所有部分，您应该对如何进行企业架构有一个很好的理解，并且通过一些额外的学习，您至少应该能够通过基础考试。

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

在您的项目中，您是否直接与企业架构师合作？您是否收到企业架构师（EA）的文档？企业架构师是否是项目设计和评估活动的瓶颈？你和我一样，对企业架构师的角色有点困惑吗？

一个小小的谷歌搜索将让你确信EA是某种组织向导，他们可以看到所有并且知道所有。她是否住在一座塔楼里并且像一个熟悉的人一样养了一只乌鸦。

定义很难得到。有很多，听起来好像它们是由混淆机器生成的。但似乎有几种不同的口味：

1. IT-业务桥梁 - The Bridge负责了解当前的业务战略并将其转化为支持该战略的IT项目。
2. 集成大师 - 大师了解整个生态系统 - 应用程序，数据库，服务 - 以及它们如何相互连接。她为IT项目团队提供文档和指导，以确保他们了解生态系统变化和约束的影响。
3. 生态系统设计师 - 设计师是组织中的顶级技术分析师，负责制定项目团队负责详细设计和交付的系统设计决策。
4. Enforcer - Enforcer为组织设置软件标准，并确保所有项目团队都接受有关这些标准的教育。
5. 创新者 - 创新者的任务是展望行业趋势和尖端技术，以确保她的组织具有竞争力。

当然，EA，如PM或PdM，不是一个可以轻松融入任何盒子的角色。 EA的作用部分取决于她所在的组织和她自己的专业领域。根据具体情况，她可以完成所有这些角色。我和同一家公司的不同EA合作过，这些公司采用了截然不同的方法。有些是“这里是一个为您的技术设计提供信息的架构图”。有些人“邀请我参加每次会议，让我审查你们的所有要求”。当你搬到不同的项目或工作岗位时，这会让你很难知道你应该期待什么。

敏捷世界中的企业架构师

这种混乱在敏捷世界中更为明显。我见过的大多数模型都说明了团队的责任，他们非常重视EA的活动，将实际的软件团队显示为EA团队想象和设计的能力的提供者，有时将业务分析完全排除在外。这与Agile软件开发的现实并没有真正同步。那么组织如何将EA集成到敏捷中呢？

我们对敏捷的关注主要集中在用户故事上，这是一种提供软件功能以提供业务价值的请求，通常范围非常小。无论您是将用户故事视为更大功能的细分还是作为独立请求，都将重点放在用户身上。但如果用户故事是整个故事，那么你就遇到了问题。可以一次建造一座乐高城堡一座塔，但是如果你没有从足够大的底板开始，你最终会把它拆掉并重新开始。

我向EA询问了我是否曾在敏捷组织中就构建权进行了一些见解。他解释了他与敏捷团队合作的理想方式。我将把它作为我下一个项目的路线图，以确保我有效地参与建筑师团队。

原文：

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

TOGAF可以帮助组织设计和开发IT基础架构，而不会带来很多麻烦。TOGAF专家对于实施优秀的IT基础设施开发战略至关重要，目前正在广泛寻找。目前，拥有TOGAF认证的人不够多，这对专业人士非常有益。TOGAF专家通过与部门主管沟通，帮助快速有效地设计IT基础架构。

现在进入主要问题，让我们知道，在2021年TOGAF认证仍然值得吗？

2021年TOGAF认证是否仍然值得？

2020年是一切发生剧烈变化的一年。全世界的专业人士都受到了影响，企业现在已经意识到员工技能的价值，因此他们急切地寻找更多的技能型员工。现在是每个人都努力提高素质的时候了。

是的，TOGAF认证在2021年仍然有效，因为各地拥有TOGAF认证的人数不足。报告显示，世界上80%的组织已经采用TOGAF作为框架。一些雇主甚至将其列为工作的强制性要求。许多大型咨询公司，如凯捷、甲骨文、惠普都已经在使用它。这也是一个全球公认的认证，它将帮助你在世界任何地方抢夺工作。

让我们了解您为什么应该在2021年获得TOGAF认证的其他几个原因。

2021年获得TOGAF认证的5个原因

TOGAF是一种越来越流行的认证。全世界的员工都已经报名参加了这门课程。TOGAF被认为是IT架构的通用框架。以下是您应该在2021年获得TOGAF认证的一些原因。

成本效益高且易于启动

TOGAF具有极高的成本效益。它更多的是一种技能，而不仅仅是一种认证。TOGAF没有任何先决条件。你可以马上开始。TOGAF无疑是2021年的年度认证。你花在学习上的每一分钱都是值得的。一旦你注册，你需要通过不同的培训级别和一些考试才能最终获得认证。

全球公认

TOGAF是全球公认的有价值的认证。到目前为止，全世界只有大约100000名TOGAF认证人员。需要更多的电流。有了这个，你可以在世界上任何一个国家找到一份出色的工作。这是一个多才多艺的学位，它将帮助你在一个职位上获得更高的职位，主要是领导职位，所以很明显，你的薪水会很高。

多才多艺的

TOGAF不仅适用于架构师和IT专业人员，也是管理领域的认证。在考试期间，您还将接受一些管理基本概念的测试。因此，你也可以在其他领域获得行政职位。

世界顶级公司使用

世界顶级雇主已经开始使用TOGAF，并寻找越来越多的TOGAF认证员工。如果你愿意在这些公司中的任何一家找到一份工作，你必须尽快获得认证。这些公司包括凯捷、惠普、甲骨文等。

更高的工资和可雇佣性

拥有TOGAF认证的人会自动获得更高的可雇佣性，并有资格获得更高的薪酬，因为目前世界上没有太多TOGAF认证的专业人士。各公司都在拼命寻找越来越多经TOGAF认证的员工。已经有80%的世界顶级组织采用了TOGAF架构模型，还有更多的组织也将采用TOGAF架构模型。

获得TOGAF认证的成本也大大降低。你可以从任何地方获得认证，大约300-400美元。对于更高级别的认证，您可能需要多付一点钱。有两种类型；也就是说，ToAF基金会和ToAF认证。它更被建议获得认证，而不仅仅是在基础阶段退出。一份TOGAF认证证书的费用大约为500美元。

底线

努力工作是无法替代的。这一点大家一定知道。世界正在迅速变化。员工越来越需要独特的技能，而不仅仅是学位。记住，总有比你更好的人在等待机会，所以要不断发展！！

希望你喜欢这篇文章。请与大家分享。

原文：https://www.pulseheadlines.com/is-togaf-certification-still-worth-it-in…

本文：http://jiagoushi.pro/node/1523

讨论：请加入知识星球【首席架构师圈】或者小号【csa_cea_cto】

ArchiMate示例

ArchiMate示例视图

框架视图

此视图表示构建所有开发方面和相关图表的框架。视图可以根据具体情况进行修改。因此，此视图可用于图之间的导航。这个版本的观点是从ArchiMate（3）框架中应用的。动机在这里被引入为“层”而不是“方面”。

 

动机观点

动机观点

此视图可用于分析指导组织及其企业架构的设计或更改的动机或原因。这些动机分析是组织中所有变革活动或业务转型的起点。该视图代表了开发工作的愿景——无论规模和范围是整个组织还是仅部分组织（如业务线），还是单个计划或项目（解决方案级别）。注意：可以将值添加到结果（或任何其他ArchiMate元素）中，以指示什么是真正的增值！

 

激励要素基于商业激励模型（BMM）【规范v.1.32015，OMG】。

 

使命价值观愿景

此视图可用于表示组织的使命、愿景和核心价值观。使命表达了例如“组织的目的是什么，它实际上在做什么或打算做什么，它存在的主要原因是什么？”愿景是组织打算发展的未来状态。核心价值观是支持愿景、塑造文化和反映组织价值观的东西。为了实现组织的愿景，需要实现战略目标。

 

参考文献：Alda，A.–Iacob，M.–E.–Hillegersberg，J.–Quartel，D.–Franken，H.（2015）ArchiMate建模策略。

 

战略价值图视图

此视图可用于组织策略的可视化。这一观点包含战略价值要素，所有发展活动都必须直接或间接地从中衍生出来。通过可视化战略价值，可以追踪与实际战略执行相关的所有其他元素。有了这种观点，战略就可以实现：可视化、沟通并与现实联系起来。

 

利益相关者分析视图

此视图可用于业务开发目的的利益相关者分析：变革的驱动因素是什么。首先，确定相关的利益相关者，然后确定符合他们利益的变革驱动因素。“评估”概念可用于对驱动因素进行详细分析，例如根据SWOT（优势、劣势、机会、威胁）方法。通常，可以从不同的角度创建不同的利益相关者视图图。将大型图拆分为小型图的另一个原因是为了保持图的紧凑性和可读性——为了简单起见。

 

利益相关者观点

此视图可用于将利益相关者的驱动因素与业务目标联系起来。目标是组织发展的关键要素。所有后续要素都应追溯到所有变更活动的这些主要原因。

 

原理视图

Risk & Security View

风险与安全观。风险和安全概念到ArchiMate的映射。安全和数据保护事项是风险管理的一部分。这种建模方法涵盖了这两者。

 

参考文献：

 

《如何使用ArchiMate®语言对企业风险管理和安全进行建模》，Open Group，文件编号：W1722017。

用ArchiMate®语言建模企业风险管理和安全，Open Group，2015。

SWOT分析视图

Goals View

Objectives and Key Results

OKR模式。

OKR是一种流行的管理策略，定义目标并跟踪结果。它有助于围绕可衡量的目标建立一致性和参与度。OKR有两个重要部分：你想要实现的目标和关键结果，这是衡量实现目标的方法。

 

目标：

–是对你想要实现的目标的令人难忘的定性描述。目标应该简短、鼓舞人心、引人入胜。目标应该激励和挑战团队。

 

关键结果：

–是一组衡量你实现目标进展的指标。对于每个目标，你应该有一组两到五个关键结果。不止这些，没有人会记得它们。

 

另一个版本的操作如下所示。

Strategy Views

Strategy Layer Views

Strategy View

ArchiMate版本3现在支持与业务战略相关的概念，如“行动过程”、“能力”和“资源”，这些概念可用于组织的业务战略建模。这种观点的价值和重要性在于如何将组织的目标与战略联系起来，以及如何通过能力将这些目标与企业架构联系起来。这种观点可用于应用“基于目标的战略模型”（Azevedo等人，2015），其中目标构成了一个层次结构，从而将更高级别的目标分解为更低级别的目标。

 

业务战略视图

商业动机模型（BMM）视图

理论上，ArchiMate®模型可以使用笔和笔，白板和标记来创建。还有一些软件平台提供ArchiMate建模环境，它具有许多自动化功能和分析功能。

但是在这篇文章中，我们将重点关注一个重要的元素，即成熟为一个先进的关键任务建模功能：模型库。

模型库

ArchiMate用于描述和分析企业的多个视角，包括现状和未来状态，以及规划两者之间的可能步骤。这很有用，因为企业架构（EA）的主要焦点可以说是支持变更计划。

虽然有几种方法，技术和最佳实践可供遵循，但这仍然不是一项简单的任务。这是因为它经常涉及在不同团队中工作的几个人来实现相同的目标：建立集成的企业架构模型。

支持和组织建模工作的集中存储库是必不可少的。存储库本身可以采用数据库的形式，但不一定。许多组织使用文档管理系统来实现EA工件的存储库（的一部分）。

存储库概念的核心方面是模型和信息的重用。在ArchiMate模型库中，对象只存储一次，并且可以在对象相关的其他图中重用。存储库充当所有对象，关系和属性信息的中心保留位置，其中维护模型并保持最新。

这使得基于存储库的ArchiMate建模与使用绘图工具根本不同：重用对象的能力导致生产力的大幅提升。

由于存储库汇集了来自企业的不同区域，视角和状态的信息，因此可以执行集成分析。将定性和/或定量数据作为对象的属性包含在内，可以得到非常高水平，有趣的分析。示例包括基础结构对象的安全信息，或应用程序组件或业务流程的性能信息（KPI）。

使用ArchiMate扩展，需求和项目计划信息也可以包含在存储库中，与体系结构相关，并成为分析的一部分。这样，ArchiMate模型不仅仅是对象，关系和视图的连贯集合;它是一个综合的“企业知识体系”。

设置模型存储库

建立模型库的最佳方法是“思考大，从小做起”。

一旦达到初始级别的ArchiMate建模成熟度，通常在两个或更多“域”（例如，信息，应用，业务和/或技术）中，建立集中式存储库就变得必不可少。这不仅仅是一项技术练习;还需要考虑人员和流程因素。

设置模型存储库时的关键考虑因素

人

应围绕谁建模什么来建立清晰的图景，并应解决模型内容所有权问题。应明确定义和记录，例如使用RACI矩阵。使用自动存储库解决方案时，ArchiMate建模的组织结构可以实现为基于角色的访问级别。

另一个重要问题是为组织特定使用ArchiMate语言提供指导。介绍模型样式指南可以防止“方言”的出现以及在不同域中使用不兼容的细节级别。同时，样式指南促进使用组织特定的可重用模型模式作为（域）体系结构的一部分。

流程

应确定并记录治理流程，角色和职责。这可以通过使用传统格式来完成，包括流程图和组织结构图。治理流程应指明组织设置和维护模型存储库的顺序。

在模型内容和属性数据的一致性和准确性方面，还应存在审查流程以保持高质量。

技术

如前所述，ArchiMate模型库可以使用各种类型的技术实现。 BiZZdesign Enterprise Studio提供了一个集中功能的中央集成模型库。存储库具有灵活性和可配置性，允许为ArchiMate建模实现各种组织和治理结构。

良好的存储库具有许多管理和发布模型内容的功能，包括版本管理，签入/签出功能和基于角色的授权。在模型库中，可以描述不同的状态（原样，将要）以及版本（草稿，审查，发布等）。

结论

ArchiMate模型库对于有效管理和管理架构团队的建模活动是必不可少的。 ArchiMate模型库的采用和实施应该作为一个项目来处理，不仅要关注技术，还要关注人员和流程问题。 至少在我们的经验中，基于“思考大，但从小做起”的战略已被证明是成功的。

原文：https://bizzdesign.com/blog/archimate-modeling-in-practice-using-a-model-repository/

本文：http://pub.intelligentx.net/node/395

讨论:请加入知识星球【首席架构师圈】

想在Facebook上做个调查吗?它会很有趣——我们可以学习哪种动物或颜色最能代表你的个性，或者其他类似的傻事。你所要付出的代价就是收集到的所有关于你的微观数据。你不喜欢那些小测验和调查?没问题，因为如果你Facebook上的任何一个朋友曾经同意过其中的一项，那么不管怎样，你的连接都有可能让其他人访问你的数据。

你知道这是怎么回事。本周，Facebook因允许第三方开发者在未经其许可或同意的情况下，从5000多万用户那里获取远远超出其预期的用户数据而备受指责。这个故事有很多角度，也有很多人指责是谁做了什么，事情应该如何处理。尽管事实仍在调查中，但这是一件严肃的事情。在我写这篇文章的时候，Facebook的市值自消息传出以来已经暴跌了50个基点。该公司目前正卷入一场公关噩梦，包括要求国会作证，这将导致在未来几个月里，乌云笼罩在该股头上。

为什么Facebook会给你敲响警钟?

这是一个警钟，因为Facebook并不是传统意义上的数据泄露，即一个坏人获得了对服务器的未经授权的访问，或者在传输过程中获取了数据。Facebook关注的是社交网络平台固有的弱点，在这些平台上，价值创造与社区成员提供的个人数据量成正比，这些成员认为积极参与社区活动不会损害个人和财务安全。

是否你的业务是一个社交平台,您的客户和员工可能Facebook等社交平台的成员,因为滥用潜力强劲的消费者数据,客户和员工现在想知道他们可以相信他们提供的数据你会呆在可靠的人手中。

将数据保存在安全的地方是欧盟一直非常关注的问题，同时也让消费者决定是否允许公司保存客户的数据。你可能已经听说过《一般资料保障规例》，该规例把个人资料的控制权交还给个人。该法案将于2018年5月25日生效。GDPR的规则之一是，收集消费者数据的公司必须证明拥有这些数据的目的是正当的。这意味着，虽然Facebook、Twitter和类似的播放器仍然允许你分享和喜欢的东西，但它们将不允许保留(当然也不允许出售)你的数据。任何像贵公司这样在欧洲开展业务、导致客户或员工个人数据被保留的公司，都必须遵守GDPR，否则将面临高达全球营收4%或2,000万欧元的罚款，以更高的金额为准。

尽管GPDR被大肆宣传，需要更严格的数据隐私法规，个人有权知道何时、何地以及如何管理他们的数据，但许多企业似乎对这个问题采取了一种从容不迫的态度。Facebook的崩溃提醒我们，数据隐私和合规并不是一件“值得拥有的好事”。我们有一种“必须有的”方法来应对这个每一家大公司在2018年都必须面对的紧迫挑战。理解您的数据隐私漏洞就是要完全理解您的IT投资组合和允许数据在业务单元之间流动的管道。对您的IT投资组合、信息架构和定义您的业务生态系统的支持流程的可见性对于成功地运行业务是必要的。我们遵循GDPR的方法是基于这样一个前提，即推动数据通过管道的技术是业务流程不可或缺的一部分。

 

原文：https://community.mega.com/t5/Blog-EN-Business-IT/Will-the-Facebook-Debacle-Finally-Wake-Everybody-Up/ba-p/16724

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

Nicholas G. Carr 撰写他的文章“IT 无关紧要”已经 18 年多了。我记得读过标题；令一位年轻的 IT 顾问感到震惊，认为本世纪这个世界会如此需要我和我的同事。但是在阅读这篇文章时，我很快就明白了卡尔的意思；电子数据处理成为一种商品，就像电力已经存在了几十年一样。电子数据处理对其早期采用者具有战略优势，但时间有限。因此，随着每个人都可以使用这种信息技术，认为您可以通过“购买 IT”来获得公司的战略优势显然是一个错误的愿景，它仍然适用于新技术。在 IT 集合中，人工智能、物联网、量子计算、虚拟/增强现实、机器人过程自动化等技术不会让您与众不同，因为它们变得可供所有人快速访问。早期采用者优势的窗口随着每项新技术而减少。但是，如果 IT 本身并不重要，那又有什么关系呢？

 

这与拥有 IT 无关，而是关于您的数字业务技术平台如何实现持续的战略竞争优势。

当公司进行战略转型计划时，他们还将检查数字化及其数字业务技术平台在多大程度上可以直接或间接地为其客户促进收入流或创造附加值。今天可以购买的组件越多——包括维护、支持和优化它们的服务——在同时实现常绿、可持续和敏捷方面的风险就越小。对于一些独特的战略业务流程，需要构建平台组件或定制标准产品。但只要定制不能创造竞争优势，公司就应该问他们是否真的重要。

一家公司可以通过 IT 实现的真正不同之处在于其数字业务技术平台的组成方式。如何以对公司重要的方式构建战略、业务流程和工具。

声称构建这样一个平台很容易是自相矛盾的，但就像建造房子一样，它始于架构。在这种情况下，企业架构必须是动态的。这意味着公司的企业架构师对业务和 IT 融合的成功负有很大责任。当我寻找我访问过并拥有成功的数字业务技术平台的公司时，我发现他们的企业架构师的方法有一些显着的相似之处：

1. 他们是 Rockstar 企业架构师：他们了解企业架构不仅仅是设计、原则和规则，而且还是指导组织中实质性变革的一种手段。为此，无论他们使用哪种架构框架，它都必须牢牢地锚定在组织的变革过程中。另一方面，他们确切地知道自己在组织中的位置，不会将其与专注于构建公司未来业务的业务架构师角色混为一谈。
2. 他们认为以行业为中心：一旦涉及特定于公司垂直行业的业务流程，他们就会寻求购买可以支持其大部分流程的组件，并寻找能说他们的行业语言并具有实施这些流程经验的专家选择的组件。
3. 他们采用常青应用架构方法：当购买的组件需要定制时，他们知道可升级性方面的风险。如果无法选择产品更改，他们首先会考虑如何尽可能地将更改与产品隔离，同时在复杂性和可持续性之间保持平衡。他们了解本质复杂性和偶然复杂性之间的区别，在使用新技术的痛苦和收益之间做出权衡。简而言之：他们减轻了常青树状态的风险，并且总是问“为什么”。
4. 他们寻找彻底的技术集成：他们选择经过验证的集成组件和可以一起使用的供应商。他们寻求具有特定产品集成经验并负责成功交付的合作伙伴。
5. 他们从不低估主数据管理：他们为公司的共享主数据资产制定了计划，以确保不同主数据收集的数据保护、统一性、准确性、一致性、管理和问责制。
6. 他们认为设计的劳动力体验：每一次实施或变更都必须迅速为企业所采用，并带来高水平的劳动力体验。 在某些情况下，由变更经理领导的变更管理跟踪是必要的。
7. 他们促成协作：他们善于将组织中具有不同背景和职责的人聚集在一起，并协调他们的利益。 他们发现合适的人成为他们的大使，并对他们的 T 型档案有所了解。

因此，如果您的公司中有一位采用这些方法的 Rockstar Enterprise Architect，那么您可以确定他或她很重要！

 

有关企业架构 (EA) 治理、相关框架以及角色和职责的所有内容。 了解如何开发可持续的 EA 治理！

捷径

• 什么是企业架构治理？
• EA 治理上下文
• EA 治理框架
• EA 治理的指导原则
• 组织结构
• EA 治理角色和职责
• EA 治理流程
• EA 分类
• EA 指标
• EA 工具
• 结论

什么是企业架构治理？

企业架构 (EA) 治理是一种实践，涵盖了管理业务的基本方面。 它涉及坚定的领导力、对组织结构的全面了解、自信的方向以及启用有效的 IT 流程以促进企业战略。

但是，如果仅提炼出一个领域，EA 治理的目标就是将企业的架构要求协调为一组可理解的政策、流程、程序和标准——所有这些都是为了确保组织的愿景和标准与 实际业务需求。

它不是一门脱离现实的学科，也不是基于对什么正在发生什么没有发生的推测。 EA 治理是部署和维护业务战略不可或缺的一部分。

而且，在许多方面，这是一项永恒的工作。

如果没有 EA 治理，组织可能会陷入非标准化技术、不良产品采购或开发以及单一架构（即“孤岛”）的网络。这些习惯将不可避免地对财务和运营产生长期影响，从而在企业层面造成越来越难以纠正的协作和标准化问题。

借助 EA 治理模型，运营可以实现显着的成本节约并实现以下优势：

• 通过管理监督提高角色和责任的清晰度
• 通过提高透明度和问责制，制定清晰、快速的决策以克服挑战
• 架构一致性与简化的合规性
• 通过务实的方法进行相关且有用的企业架构管理
• 在整个企业中扩展和提升架构的业务价值
• 鼓励新受众对架构的开阔视野
• 对正确活动的架构工作进行优先级排序
• 了解改进领域以确定真正的最佳实践

不要将 EA 治理与 IT 治理混为一谈。 IT 治理是有效和高效地利用 IT 来实现组织目标的过程。下表更详细地解释了这种差异：

EA 治理不仅是 IT 主管（CIO 和 CTO）的职责，也是业务主管（在企业架构师、领域架构师、主题专家和整个组织内的各种其他支持人员的关键支持下）的职责。

 

EA 治理上下文

从概念上讲，EA 治理是一种方法、一系列流程、一种文化导向和一组自有职责，可确保组织架构的完整性和有效性。

下图表示 EA 治理框架中涉及的三个关键组件。

要使治理成功运作，所有三个要素必须协同工作。 这种与内容无关的方法确保了框架的灵活性。 此外，这些流程通常独立于内容，并实施经过验证的最佳治理实践方法。

 

EA 治理框架

组织要实现其 EA 目标，需要一个完善的治理框架来支持企业架构的实施和管理。

维护企业架构的治理框架由以下组件组成：

• 组织结构
• 角色和职责
• 流程
• 标准和指南
• 指标
• 工具

下图显示了这些基本元素的组成部分。

在建立 EA 治理时，解决这些要素中的每一个都至关重要。

 

EA 治理的指导原则

建立成功的 EA 治理的主要指导原则是：

• 纪律：所有相关方都承诺遵守商定的程序、流程和权限结构。
• 透明度：所有已实施的行动及其决策支持将可供授权组织和提供方检查。
• 独立性：建立用于最小化或避免潜在利益冲突的所有流程、决策和机制。
• 问责制：组织内的可识别群体——例如，采取行动或做出决定的治理委员会——被授权并对其行为负责。
• 责任：每个缔约方都必须对组织及其利益相关者负责。
• 公平：所有做出的决定、使用的流程及其实施都不允许为任何特定方创造不公平的优势。

对组织 IT 解决方案交付流程的 EA 治理侧重于实现多个解决方案。这些包括：

• 标准化：制定和推广企业范围的 IT 标准。
• 一致性：实现所需级别的信息、流程和应用程序集成和互操作性。
• 重用：在设计、实施和产品组合级别重用和利用 IT 资产的策略和支持功能。这可能包括流程/治理和资产存储库考虑。
• 质量：提供满足业务功能和技术要求的解决方案，并具有确保解决方案质量的生命周期管理流程。
• 成本效益和效率：通过可重复的决策治理流程利用标准、重用和质量，从而降低总解决方案生命周期成本并更好地实现 IT 投资。

组织结构

启动企业架构组织以开发和支持采用围绕 EA 的设计、审查、执行和治理功能。这些功能包括许多关键要素，包括：

• EA 框架：一套标准、程序和操作协议，用于指导和指导组织中围绕信息技术的采用、重用、报告和停用的决策。这些包括指导原则、方法、程序、指标、最佳实践和参考模型。
• EA 审查委员会：一个跨组织、多学科的架构审查委员会 (ARB)，得到企业 IT 执行管理层的支持，负责监督技术治理战略和框架定义的实施。
• EA 合规性：定义 EA 合规策略并制定一套一致的、可重复的流程以确保该 EA 合规策略。建立正确的组织职责和结构，以支持架构治理过程和报告要求。
  
   

EA 治理角色和职责

EA 中的角色和职责涵盖广泛的活动，包括但不限于：

• 提供领导和沟通
• 构想、领导和指导整体解决方案架构合规性与 IT 转型的发展
• 了解映射到业务能力模型的业务领域
• 对映射到技术能力模式的技术的理解
• 建立和维护架构实施、企业架构中体现的架构战略和目标以及业务战略目标之间的联系
• 通过共识和授权发布提供架构的正式接受和批准机制
• 提供基本控制机制以确保架构的有效实施
• 提供解决方案架构和设计技能

EA 领导者需要致力于整合“业务和 IT”，而不是协调“业务和 IT”。重点必须放在实现业务战略上，而不仅仅是保证和合规。

EA 治理流程

该过程是一系列操作或事件，可能会占用时间、空间、专业知识或其他资源，从而产生特定的结果。

EA 治理流程是用于实施技术解决方案的整体 EA 治理框架的组成部分。下面列出了五个主要过程：

• 架构文档流程
• 架构审查流程
• 架构沟通过程
• 架构合规流程
• 架构框架活力过程

企业架构成功的深度指南 [白皮书]：设计您想要的架构以及您的公司需要的架构。 »

 

EA 分类

分类是定义术语的集合，是对关键组件和架构概念结构的连贯描述。下面列出了关键概念和术语的具体定义：

• 方法：执行任务、活动或过程并衡量绩效以满足涵盖原则、政策、系统、过程、方法和技术的标准的一种方式。
• 最佳实践：完成业务功能或流程的一种方式或方法，优于所有其他已知方法。
• 蓝图：
  • 计划或指南，常用于建筑，布局合理，包括基本要素，以解决和遵循建筑进度。
  • 蓝图是记录企业架构的计划和/或设计。
• 指导原则：原则是一般规则和指导方针，旨在经久不衰且很少修改，为组织着手履行其使命的方式提供信息和支持。
• 方法论：方法论代表给定活动领域的一系列实用想法和经过验证的实践，例如基于 IT 的系统的规划、设计开发或管理。
• 协议：
  • 管理数据传输和接收的规则。
  • 指定数据格式和在数据通信和网络环境中要遵循的规则的标准。
  • 执行功能或服务时各种角色之间的参与规则。
• 标准：一组标准（其中一些可能是强制性的）、自愿准则和最佳实践。 EA 指南和标准规定：
  • 架构必须根据架构的预期用途以及企业范围标准的开发和推广进行适当的范围界定、计划和定义。
  • 企业架构必须反映组织的战略计划。
  • 架构不断变化，需要过渡。
  • 架构必须允许许多不同的硬件和软件系统相互连接和集成。他们需要交换数据以执行所需的业务交易。
  • 企业架构将需要继续刷新和更新框架以及分类，并改进企业架构模型。
  • 企业 IT 必须在整个组织内提供架构规范的定义、设计、实施和实践方面的政策指导和帮助。
  • 通过可重复的决策流程实现标准、重用和质量的一致优势，从而降低解决方案成本并更好地实现 IT 投资。
  • 支持在设计、实施和产品组合级别重用和利用 IT 资产的能力的策略。这可能包括流程/治理和资产存储库。

EA 指标

指标在 EA 实施的早期阶段估计 EA 的进度。它还有助于衡量 EA 的效率和有效性，以确保为业务提供真正的价值。

测量 EA 指标对于：

• 确定流程或服务如何有效和高效地满足客户
• 识别改进机会
• 根据事实和数据做出决策

测量应该：

• 将组织期望转化为目标
• 评估流程的质量
• 跟踪改进
• 支持企业战略

为了使 EA 程序成功，需要根据一组定义的指标定期对其进行监控和测量。可以使用 EA 记分卡或仪表板有效地捕获、呈现和传达整个组织的指标状态。

 

EA 工具

企业架构工具捕获、存储、构建和分析与企业架构相关的信息，因此，选择适合您组织的正确工具至关重要。

EA 工具通过捕获重要的企业环境以及跨业务、信息、技术和解决方案架构的内容开发和分析功能，为战略决策制定提供支持。

它帮助利益相关者分析和优化业务战略、组织结构、业务流程/任务和活动、信息流、应用程序和技术基础设施的组合。

EA 工具涵盖以下功能特性：

• 建模能力
• 框架和标准支持
• 能够创建或导入模型和工件
• 强大而灵活的存储库和元模型
• 易用性
• 集成到多个企业使用工具
• 影响企业领域各个层面的能力
• 满足各种需求的管理功能，例如安全性、审计控制、协作、配置和版本控制

结论

精心设计的企业架构治理结构对于降低 IT 成本和风险、同时加快决策制定和交付至关重要。 EA 治理可确保正确管理 EA 程序以生成真正代表组织目标和需求的工件和计划。同样，EA 治理确保投资决策从启动到实施都与 EA 保持一致。

治理是任何变革计划的重要方面。 EA也不例外。治理为各种利益相关者提供了一个定期交互和维护企业架构的平台。

EA 程序定义不应跨越数年。它应该在短时间内提供商业价值。计划输出应该是可操作的，并且应该始终衡量其影响——而不是其活动。

在现代 EA 中，EA 治理的象牙塔方法不起作用。这种方法会导致 EA 程序失败，尤其是当 EA 程序不考虑数字业务的需求时，这是由价值创造转向生态系统、平台和面向外部的架构所驱动的。 EA治理在现代EA中的作用总结如下：

• 不关注当前状态架构
• 继续将 EA 程序推进到下一个成熟度级别
• 了解组织的业务战略、业务模型和目标，并确定 EA 如何帮助实现业务价值
• 不会被 EA 框架、行业参考模型、治理和 EA 工具分心
• 将重点从自上而下的治理转移到 EA“卓越中心”
• 对 EA 程序采用持续创新的方法，完善每个周期
• 在不了解其用例和功能的情况下不使用 EA 工具
  
   

编者注

此内容由 Wipro 的 GEA 实践部门的高级企业架构师 Gopala Krishna Behara 博士提供。他拥有超过 22 年的 IT 经验，可以通过 gopalkrishna.behra@wipro.com 与他联系。作者要感谢 Wipro Technologies 的 GEA 实践部门的 Hari Kishan Burle 和 Raju Alluri 在撰写本文时提供的支持和知识。

原文：https://www.leanix.net/en/wiki/ea/enterprise-architecture-governance

本文：https://jiagoushi.pro/leanix-enterprise-architecture-governance

定义：

企业是一个由相互依赖的人员、流程和支持技术组成的网络，不受任何单一实体的完全控制。信息密集型企业是其成功运营在很大程度上依赖于网络化信息系统的企业。设计信息密集型企业专注于管理企业中的不确定性和相互依赖性，它涉及对企业和支持企业的系统进行设计。信息密集型企业的工程设计旨在构建有效且高效的单个系统网络，以满足整个企业的目标。

关键词：

架构、变化、可组合、设计模式、信息密集型、创新、任务保证、开放系统、不确定性

MITRE SE 角色和期望：

MITRE 系统工程师 (SE) 有望开发平衡本地创新与全球创新和发展的企业解决方案。他们开发的解决方案 (1) 提供定制的创新以满足最终用户的本地需求，以及 (2) 与不断变化的环境互操作、响应和共同发展。

语境

我们赞助商组织的成功越来越依赖于信息。如果在需要时无法获得正确的信息，企业的使命和成果就会变得不那么有效、高效或成功。

一个企业有许多组件和信息必须结合在一起才能实现任务成功。数据、业务规则、应用程序、通信和传感器需要在企业架构、设计、现有系统和任务保证要求的约束下创建或组合成能力。这里有一些例子：

• 对于国土安全，通信能力必须支持第一响应者以及州、地方和部落合作伙伴的需求。
• 在国防部，网络安全威胁需要在使用之前仔细考虑和仔细检查开放能力和新兴技术，例如社交网络。
• 在空中交通管理中，对公众信任的需求可能会推动与自由飞行和在国家空域使用无人驾驶系统相关的商业规则。
• 对于像 IRS 和 VA 那样的现代化工作，鉴于运营组织准备好吸收它们及其相关的新流程和程序，出现了如何以及何时插入新技术和能力的问题。

最佳实践和经验教训

 

• 信息作为资本。将企业数据和信息视为具有长期价值的资本资源。强调数据策略在您的工作中的重要性。
• 数据互操作性。采取数据互操作性设计以确保实现跨企业能力的观点。
• 适应企业周期。有长期和短期的赞助商周期。前者包括预算、需求、合同和实施等活动。后者包括响应紧急的运营需求。了解并区分它们，并根据它们调整系统工程。
• 考虑能力寿命。了解用户所需功能的可能寿命。使您的观点和系统工程方法适应您设计的功能的这方面。当前的情况/环境可能需要某种能力，但下一次危机或以后不再需要这种能力。在危机中，能力进化的考虑可能不是系统工程分析的关键部分，但不应该完全放弃对未来使用的考虑。例如，设计模式可用于创建即时功能，同时便于在未来危机中使用。可组合的能力策略可以使组件能够被创建并“上架”以支持未来的情况。开源能力可以为“立即使用”提供基础。
• 不要抛弃“一次性”的想法。许多赞助商的发展强调一切都必须能够被其他人重用（这在面向服务的世界中得到了加强）。虽然这种情况经常发生，但有时谨慎的做法是建立一种更快、更便宜、一次性的能力。了解在您的企业内和其他人重用的价值，但也要了解在某些情况下，构建一次性版本是更好的行动方案。

该主题下的文章

本主题下的文章旨在帮助工程信息密集型企业中的 MITRE 员工。

• 架构由我们的赞助商使用，用于各种目的——支持对运营的理解，帮助系统设计和实施，并为企业能力提供基本的构建块。联合架构有助于处理工程跨企业需求的规模和复杂性，以提高整体任务效率。架构联盟一文讨论了联合架构如何在企业的主要部分实现本地创新、企业集成和演进——其中许多可能本身就是企业。
• 软件中的设计模式不是软件的具体部分，而是在某些情况下应用的最佳实践模板。 MITRE SE 可能会在开发或审查系统组件之间的接口或更高级别的跨系统边界时遇到并使用它们。文章设计模式描述了在面向工程服务的环境和接口标准化活动中使用这些模式的基本方法、最佳实践和经验教训。
• 可组合的按需功能 (CCOD) 文章描述了一种新的、不断发展的策略，以使功能能够快速拼凑在一起，以满足最终用户的需求，在某些情况下，用户自己需要。 CCOD 具有许多 Internet 工具的风格，这些工具使各种服务能够快速应用于数据或信息，以构成满足用户需求的“用户定义”或定制视图/透视图。
• 开放系统方法增强了在信息密集型系统中快速创建能力的能力。文章开源软件 (OSS) 提供了关于 OSS 的历史视角，描述了 OSS 快速变化的观点及其与工程信息密集型企业的关系，强调了政府对 OSS 的兴趣和使用，并以一套全面而详细的应用开放系统技术和使用开源软件的最佳实践和经验教训。
• MITRE SE 应了解适用于联邦机构收集、使用、维护和披露个人身份信息的法律要求。隐私系统工程一文提供了有关如何将隐私构建到系统工程生命周期中以及如何利用技术来保护隐私的指导。

原文：https://www.mitre.org/publications/systems-engineering-guide/enterprise…

本文：

定义：

架构联合是用于企业架构开发、维护和使用的框架，它对齐、定位和链接分离但相关的架构和架构信息，以向用户提供无缝的外观。

关键词：

企业架构，联邦架构，适合联邦，语义对齐，分层责任，接触点

MITRE SE 角色和期望：

MITRE 与各种政府赞助商合作，帮助他们构建企业架构，通常是在支持其整体企业现代化或转型计划的背景下。许多发起人都面临着以一种有凝聚力和安全的方式共享其业务流程、信息存储、技术系统和人力资源以完成共同使命的复杂问题。 MITRE 系统工程师 (SE) 应了解并应用架构联合的原则，以实现跨企业架构或多机构企业架构的主要部分的本地创新、企业集成和演进。通过帮助他们构建各自的产品来满足共同的规定方向，MITRE 的赞助商将能够通过像 LEGO® 积木一样“将它们拼接在一起”来重用组件架构，以构建范围更广和适用性更广的复杂架构。

介绍

近年来，MITRE 一直在支持联邦政府范围内的架构工作。事实上，联邦政府现在要求为任何重大信息技术投资寻求资金的机构使用企业架构。赞助商通过增强美国企业（例如空军企业）与联合部队和联军部队、其他军种和国家机构的互操作性和整合，使用架构来提高作战和业务能力。

为了完成这些工作，MITRE SE 需要理解和应用联合架构的原则来解释架构相互关系并表达架构如何相互连接。联合架构支持跨企业主要部分的本地创新、企业集成和演进——其中许多可能本身就是企业。架构联合在实践中的原则需要合并(merging)、整合(integrating)和联合(federating )大量不同的组织架构，例如联邦航空管理局、国防部、国土安全部、CBP 和联邦紧急事务管理局，以及航空公司等行业参与者的贡献、机场、IT 行业、气象局等。本文探讨了架构联邦的基本概念，并提供了经验教训，以帮助 MITRE SE 了解联邦原则如何帮助从业者更有效地构建架构。

什么是企业架构？

架构涉及组件的结构、它们彼此之间和与环境的关系，以及指导它们所描述的实体的设计和演变的原则 [1]，无论该实体是一个组织（例如，联邦部门或机构），一个系统（例如，联合监视目标攻击雷达系统），或一个功能或任务领域（例如，财务管理、国土安全）。架构产品和工件可以采用多种形式，包括存储在架构工具或数据库存储库中的结构化数据模型、硬拷贝或电子格式的信息图形描述，或非结构化数据或文本。

“企业”的一个良好的工作定义是具有一组共同目标或原则或单一底线的任何组织或组织群（例如，公司、单个部门、政府实体、地理位置偏远的组织网络）。企业架构提供了清晰而全面的企业图景。它包括当前运营和技术环境的快照、目标环境以及从“现状”环境过渡到“未来”环境的资本投资路线图。换句话说，它充当了前进道路的路线图。快照包含“视图”，每个视图都包含一个或多个架构产品，这些产品为特定的利益相关者组 [2] 提供企业感兴趣的某些部分的概念或逻辑表示。

联合的架构是什么意思？

开发单片集成架构的历史方法效果不佳，因为这些产品通常变得过于复杂和笨拙。相比之下，联合架构是用于企业架构开发、维护和使用的框架，它对齐、定位和链接分离但相关的架构和架构信息，以向用户提供无缝的外观。它使复杂的架构能够从组件架构中以零碎的方式构建。通过这种方式，联合架构方法可以识别单个架构的独特性和特定目的，并允许它们的自治和本地治理，同时使企业能够从它们的集体内容中受益。

联合提供了在定义的上下文和当前/未来环境中组织企业关于其活动（流程）、人员和事物的知识体系（架构）的方法。联合架构通过链接整个企业的架构来支持决策制定，提供一个整体的企业视图，允许评估诸如互操作性、重复和差距的识别以及可重用性的确定等问题 [1]。

为什么要开发支持联邦的架构？

集成和/或联合架构的能力对于解决跨广泛领域（例如联邦部门或机构）的企业问题至关重要。联合使多个团队能够以最能满足他们当前需求的重点来开发架构，同时提供一种链接和关联这些架构的方法，以解决跨多个领域的问题。单一架构可能无法充分解决整个企业的问题，以支持具有多种任务的大型组织所需的分析。联合多个架构的能力导致了一个更强大的结构，可以以更小的、一口大小的块来理解企业。

架构联合在某种程度上作为一个过程，通过查找重叠并在它们的公共架构信息之间建立映射来关联从属架构和父架构。联邦部门和机构也在寻求另一种使用架构联合策略的方法，将企业划分为可管理的、大小合适的组件，每个组件都可以由与其最密切相关的社区进行描述 [3]。每个人都使用一小组规则、通用术语和标准来保持一致性，以便组件可以根据需要“拼凑在一起”。例如，部门架构描述部门范围的规则和约束，组件架构描述特定任务的服务和能力，解决方案架构描述符合更高规则和约束的解决方案。

联邦的概念在环境发展和信息共享方面也发挥着重要作用。例如，随着联邦部门和机构企业的网络化程度越来越高，事实证明，联邦架构在组织信息阵列和复杂关系方面至关重要。联合架构元数据也可用于评估现有系统和程序的组合，以决定实现所需功能所需的更改或添加。

那么，什么是联合企业架构？

根据企业范围的定义，联合企业架构是一组具有以下属性的架构：

• 它以协作方式运作，治理在中央机构和组成单位之间划分，平衡组织自主权和企业需求。
• 中央机构的架构可以专注于规模经济、标准和企业福祉的动态。
• 组成单元的架构具有追求自主策略和独立流程的灵活性[4]。

哪些核心元素支持架构联盟？

在联合方法中，架构开发的责任由企业内的不同层级分担。要将这些单独但相关的努力结合在一起，需要：

• 分层问责制：建立架构的层次结构，使层次结构中较低的架构继承较高层次架构的特征。使用接触点来关联各个级别或层级的架构。
• 分类：关联和分组“相似的”的架构和工件。
• 语义对齐：使用通用词汇和映射关系来建立共享理解。
• 参考架构：为其他架构提供父分类法以供使用。
• 搜索和发现：允许授权用户查找和访问相关架构以获取信息和重用 [3]。

架构联盟的一些关键构造是什么？

图 1 描述了架构联合的关键构造。每个构造都包含一组特定利益相关者感兴趣的架构产品。

Figure 1. Key Constructs for Architectures Federation

主题架构是为特定目的驱动解决方案的架构。它解决了交付功能所需的所有业务、信息、业务服务和技术组件。主题架构所依赖的那些解决方案的架构称为支持架构；而那些依赖于主题架构的解决方案的架构称为受支持的架构。

每个架构接口点（也称为接触点）是两个架构之间有目的连接的抽象表示。这些架构接口点是现实世界接口的抽象，将体现在实现相应架构的解决方案中。简单来说，接口点是架构可以加入更大的联合架构的地方，因此从操作的角度来看，它们是有目的的联合的关键。

合规在联邦中的作用是什么？

如果一个架构将被共享并用于支持与其他架构的联合（例如，指导其他架构或程序的开发），那么符合一组标准的架构就很重要。这些标准以规定方向的形式出现，称为合规标准。合规标准包括业务规则和流程，例如信息、服务和技术标准。程序或其他架构必须遵守这些，才能符合给定的结构。合规标准增加了对这些标准将被验证的方式的描述。因此，合规性标准明确说明了程序或架构必须在功能、遵守标准和满足特定质量要求方面展示什么。

组织可以从创建满足最低标准集的架构开始，从而更容易共享架构并将它们定位用于构建架构联盟，以支持构建可互操作解决方案的联盟。

合规标准有哪些例子？

Fit for Federation 是特定合规性评估的一个示例，可应用于将成为架构联合的一部分的任何架构。适合联邦由以下合规标准确定：

• 该架构的目的已由用户和用途记录和验证。
• 输入已被验证为来自权威来源，并记录了权威来源。
• 架构和/或分析（输出）已被验证符合目的。
• 识别、记录和验证支持的架构接口点和相关标准。
• 支持架构接口点被识别、记录并与供应商协商。

 

• 建立、记录和验证其他合规标准（例如，企业范围的标准和/或定性要求）。

在评估符合性标准时可能应用的一些定性要求的例子是可负担性、可靠性、可扩展性、性能和信任。

对于面向服务的环境，特定的合规标准将被打包为服务水平协议 (SLA)。单个合规性标准可以分配给多个 SLA。例如，支持给定词汇表将适用于处理主题（领域）词汇表的所有服务。

最佳实践和经验教训

实现语义一致。

为了联合架构，必须有语义协议，以便相关信息可以适当地关联。 MITRE SE 可以建议他们的发起人通过以下方式达成语义协议：

• 遵循通用框架，包括对所有架构描述实体或对象使用通用数据元素定义、语义和数据结构。
• 符合通用或共享架构标准。
• 使用企业分类法和权威参考数据。

符合标准。

一般来说，符合通用或共享架构标准会增加互操作性并使其更容易联合。 MITRE SE 应鼓励其发起人选择适合其目的的标准，并帮助他们建立强制合规的方法。例如，商定的企业分类法建立了用于调整任务领域活动和相关参考模型以及对组件架构进行分类和组织的上下文，从而促进跨联盟中各种架构的语义理解。

启用信息共享。

 

支持信息共享的环境促进了架构的联合。

确保健全的治理和企业架构服务：

MITRE SE 首先必须认识到架构共享环境需要健全的治理和企业架构服务。他们必须帮助他们的发起人建立健全的治理结构，以将问责制应用于架构的开发和维护，以实现既定目标，这最终将促进他们的联合能力。这种方法将责任放在配置管理和质量保证等流程上。 MITRE SE 还必须鼓励其发起人建立企业架构服务，以使架构信息始终如一且高效地可见、可访问和理解。

公开架构及其元数据：

联合工作的成功还取决于公开架构和架构元数据，以供分析师、规划人员和决策者在各个级别进行潜在的链接和重用。共享已经存在的架构和服务有助于加快架构开发和联合。注册功能 [5] 提供架构元数据的注册和链接，以支持创建可导航和可搜索的联合企业架构。架构的企业执行策略和治理加强了健壮的接口和数据关系 [1]。 MITRE SE 应该帮助他们的赞助商积极参与这些架构共享场所，方法是在重新发明之前重用工件，并发布他们自己的元数据和产品供其他人重用。

鼓励发起人的联合架构：

MITRE SE 应在发起人组织内促进和促进联合架构的发展，以帮助提高决策的可靠性和效率。当组织跨越边界对齐语义和结构数据时，就会发生这种情况，这样他们就可以确保使用正确的信息来回答关键决策者的问题。 MITRE SE 应继续使用联合架构机会并改善利益相关者节点之间的信息流，从而改善决策者之间的信息流。

概括

MITRE 与各种政府赞助商合作，帮助他们构建企业架构，通常是在支持其整体企业现代化或转型计划的背景下。 MITRE SE 需要具备的一项关键技能是了解业务需求、信息技术和人员如何在构建良好的架构中融合在一起。

MITRE 的许多赞助商都面临着多机构企业架构的复杂问题。不同的政府实体如何以一种有凝聚力、安全的方式共享他们的业务流程、信息存储、技术系统和人力资源，以完成共同的使命？架构联盟可以促进这种共享。通过构建各自的产品以满足共同的规定方向，MITRE 的赞助商将能够通过像 LEGO® 积木一样“将它们拼凑在一起”来重用组件架构，以构建范围更广和适用性更广的复杂架构。

参考资料和资源

1. Department of Defense, April 23, 2007, DoD Architecture Framework Ver. 1.5, Vol. I: Definitions and Guidelines.
2. Hite, R. C., and G. D. Kutz, March 28, 2003, Observations on Department of Defense's Draft Enterprise Architecture, GAO-03-571, accessed October 8, 2017.  
3. Frey, B., July–September 2008, "Department of the Navy Architecture Federation Pilot," CHIPS, pp. 41–43, accessed October 8, 2017. 
4. Air Force Chief Architect's Office, December 2007, Air Force Architecture Framework.
5. Department of Defense, DoD Architecture Registry System.

其他参考资料和资源

 

DoD Deputy Chief Information Officer, DoD Architecture Framework (DoDAF), accessed October 8, 2017.  

DoD Deputy Chief Management Officer, Business Enterprise Architecture, accessed October 8, 2017.

Government Accountability Office, August 5, 2010, Organizational Transformation: A Framework for Assessing and Improving Enterprise Architecture Management (Ver. 2.0), GAO-10-846G, accessed October 8, 2017.

 

原文：https://www.mitre.org/publications/systems-engineering-guide/enterprise…

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

Togaf架构师模块在第一次加载时提供了3个默认模型组织，Togaf、SOA或BPM。

视角选择

这些模型组织是建模帮助，但是您仍然可以以不同的方式组织您的模型。

Togaf结构

TOGAF架构组织在以下结构中:

业务体系结构在业务层中定义。

• 数据体系结构分为业务层和技术层，前者定义数据的概念层(“业务层/业务实体”下的业务实体)，后者定义持久数据的模型(“应用程序层/数据体系结构”)。在“业务实体”阶段，建模师关注概念及其属性，但不关注逻辑和物理方面，如存储库、关系模型等。建议首先对业务的重要概念建模，然后定义企业组织、业务流程和其他业务体系结构元素。
• 应用架构是在“应用层/应用架构”下构建的。它有两个应用程序域:“服务数据”，用于建模业务服务和系统用例之间交换的数据，以建模与IS的主要应用程序组件相关的用例。
• 技术架构是在“技术架构”技术领域下构建的。

SOA结构

SOA架构组织在这个结构中:

• 应用程序体系结构
• 硬件部署

BPM结构

BPM/业务架构组织在这个结构中:

• 业务层

根据目标Togaf架构的性质，这些域是专门的包，其中Modelio菜单建议创建适当类型的Togaf模型元素或Togaf图。

 

原文：http://forge.modelio.org/projects/togaf-modelio3-user-manual-english/wiki/Modeling_Model_Organization

本文：

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【1110777】

在本系列的前几部分中，我们讨论了国防和工业中体系结构的常见驱动因素，国防和民用领域的体系结构实践之间的共性，以及为什么选择ArchiMate语言作为在NATO体系结构框架中表达体系结构的推荐标准V4。在最后一部分中，我们将讨论在NAF v4环境中使用ArchiMate仍需要完成的工作。

 -  Kevin Wallis（MOD ISS）和Marc Lankhorst（BiZZdesign）

术语的差异

在此之前，我们概述了ArchiMate如何发展到其概念涵盖防御领域中企业架构的所有重要方面的程度。这并不意味着它是一个完整的一对一契合。 ArchiMate是为民间组织，组织和组织开发的。此外，防御领域的术语有时与政府或金融领域的术语不同。但是，通过简单的术语映射可以在很大程度上克服这些差异。完整的术语表对于博客文章来说太大（而且太无聊），但下表给出了相应术语的印象。

NAF/MODAF term	ArchiMate concept
Mission	Course of Action
Concern	Driver
External Individual	Stakeholder, Business Actor
Needline	Business Interaction or Flow relationship (depending on context)
Function	Business Function
Mission Thread	Business Process
Forecast	Assessment
Climate	Constraint
Enterprise Goal	Goal
Capability	Capability
Requirement	Requirement
Assigned Property	Value
Actual Location	Location
Actual Organisation	Business Actor (or Business Collaboration)
Actual Post	Business Actor
Post Type	Business Role
Entity	Business Object
Product	Product

该映射表明，ArchiMate的概念世界足以表达防御域的需求。 有时，ArchiMate的专业化和刻板印象特征可能会有所帮助，但英国国防部决定直接使用ArchiMate，而不进行此类定制，以促进模型与行业的交流。

NAF v4的观点

在这种情况下，ArchiMate最重要的用途在于表达NAF v4规定的各种观点，这些观点列在下面所示的网格中。

 

重要的是，NAF v4对视点的使用是以信息为中心的;它将框架划分为建筑信息类别，而不是如何呈现信息（这是NAF v3方法）。这与ArchiMate在架构模型的内容和视图中的表示之间的区别完全一致;相同的模型元素可以存在于多个视图中，但是以不同的方式描述以解决各种观众。

以上所有观点都在NAF v4规范中有更详细的描述。下一步重要的是为这些提供ArchiMate示例。一些观点最好用简单的表格或网格（TOGAF术语中的目录和矩阵）表示，不使用ArchiMate的标准表示法，而是基于同一个底层模型。同样，使用统一架构框架配置文件（UAFP）可以更好地阐明一些详细的设计观点，这是另一个被批准用于NAF的标准。由于ArchiMate在设计时考虑了与其他标准的互操作性，因此同时使用它们不会带来任何概念上的问题。事实上，开放组和对象管理组都在与北约合作，就如何在两个标准之间有效地交换信息达成一致。

北约的联邦任务网络（FMN）参考架构，可以在Tidepedia上找到具有适当安全权限的人，在ArchiMate中表达，作为当前使用的符号的替代。这是一个相对简单的练习，虽然由于信息被分类，这里无法显示某些结果，但以下视图显示了一些工作。

 

 

MOD的方法

国防部信息系统和服务部（MOD ISS）也决定尽可能地利用通用的行业标准。为此，它将自己的架构方法集中在TOGAF和ArchiMate的组合上，与NAF v4一致。它目前正在实施“设计即服务”方法，其中行业合作伙伴可以负责设计某些架构。为了确保最终设计工件的兼容性和质量，它使用EA加速器，根据TOGAF架构开发方法（ADM）的各个阶段组织必要的架构视图。这也预先填充了模型，其中包含要遵循的模板和可重复使用的模式，以便标准化输出并重用现有知识。

 

这些模型的交换是通过独立于工具的ArchiMate Exchange格式完成的，允许承包商自由选择任何符合ArchiMate标准的工具。利用他们与NATO合作开发FMN参考架构的经验，MOD ISS正在开发他们的参考架构，称为防御作为平台（DaaP）服务架构。第一次迭代计划于2018年9月在英国政府网站GOV.UK上发布。

最后的笔记

总之，我们认为在防御中使用广泛接受的行业标准如TOGAF和ArchiMate提供了巨大的优势。在民用和国防领域使用的知识，经验和设计文物的轻松传输，以及广泛的工具支持和咨询经验肯定会有益于防御领域。相反，将ArchiMate作为北约批准的标准进行宣传将提升其受欢迎程度并进一步扩大其用户社区。这将使两个世界的建筑师能够相互学习，并相互受益于彼此的经验。

讨论： 加入知识星球【首席架构师圈】

 

“如果你想要新的东西，你必须停止做旧的东西。”

——彼得·德鲁克，《公司概念》的作者

这篇文章介绍了 Salesforce 运营、治理和架构框架 (SOGAF)，这是一个新的大规模治理框架，由对跨多个行业的学术文献、现有框架和转型案例研究的广泛研究提供支持。

为什么我们需要另一个治理框架？

我们已经看到技术驱动转型的两个根本性转变：技术模型本身以及实施和运营的方法。技术模型发生了变化，因为从内部部署到云计算的转变带来了许多好处，例如敏捷性、可扩展性、成本节约、最小的资本支出、增强的协作、随时随地工作等等。随着技术的这种转变，实施和运营的方法也从基于瀑布的、以项目为中心的交付模型转变为敏捷的、以产品为中心的持续改进模型。

转型三难困境

启动技术驱动转型的公司通常面临三难困境，即一组目标会产生不同的结果并带来特定的风险；他们必须从三个目标中选择两个来“保持在转型三角形的一侧”并推动成果。

让它纯净

 

• 这里的目标是通过快速实施标准技术来跟上业务的步伐，为所有用户组使用相同的设置⁠——“采用，不要适应”。
• 风险在于触发“意外后果法则”。一个架构层的标准化可能需要其他架构层的定制。例如，标准化数据库层可能需要对 UI 进行自定义。

做这一切

 

• 这里的目标是满足所有业务需求，避免回归（即丢失以前对最终用户可用的功能），并确保未来用户组的可扩展性，以满足他们的特定需求。
• 风险在于重建“云中的遗产”。通过解决遗留痛点来设计应用程序通常会导致将这些痛点“提升并转移”到新系统，而不是让架构随着业务发展而面向未来。

让它好

 

• 此处的目标是提供完整的技术驱动型业务转型（例如，从“实体”到在线）以及从瀑布到敏捷技术交付方式的过渡
• 风险在于，这可能会导致混乱。业务和 IT 都将摒弃旧方法，学习新方法，替换现有流程和系统，同时构建新的流程和系统。

为了成功实现数字化转型并降低这些风险，建议公司从三个可能的目标中选择最有可能单独实现且彼此最兼容的两个目标。例如，追求“纯”快速和标准化 Salesforce 实施的公司将难以在不损失功能的情况下满足所有业务需求。

这对 Salesforce 架构师意味着什么？

Salesforce 架构师负责管理技术驱动的转型并交付构建其业务未来的成果。架构师面临着许多与大规模治理相关的问题，例如：

• 如果以可比公司为基准，我们今天在哪里？
• 要自力更生，我们从哪里开始？我们可以从多小的开始？考虑到我们的背景，我们必须走多远？
• 我们需要哪些组织实体、能力、结构、角色和技能？什么时候？
• Salesforce 卓越中心 (CoE) 做什么？它与 Salesforce 设计授权 (DA) 有何关系？
• 我们如何确保端到端的一致性（业务、IT、项目、治理方法等）？
• Salesforce 的企业运营模式是什么？
• 我们如何将运营模型转化为架构或组织战略？

大规模的 Salesforce 治理

Salesforce 治理可以定义为组织公司能力、领导力、人员和管理的战略。 组织能力定义了如何管理 Salesforce 平台并确保最佳实践。 领导层决定了如何以及何时完成，以及由 CoE、变更控制委员会或架构审查委员会等实体完成。 人员和团队负责设计和交付价值，而管理层则确保一致性、合规性和兼容性或原因。

例如，治理的一个关键功能可能是确保交付团队遵循配置最佳实践。 这是通过与架构师和开发人员举行定期审查会议来以一致和合规的方式管理平台，最大限度地减少技术债务，并决定配置与定制来完成的。

介绍 SOGAF

我开发了一个新的大规模治理框架，因为现有的架构和实现框架，例如 TOGAF 和 Zachman，并不是为平台设计的。 Salesforce 运营、治理和架构框架 (SOGAF) 通过七种不同的功能及其端到端的一致性来大规模解决治理组件。 SOGAF 以学术文献为基础，并通过案例研究进行了实证验证，检查了这些能力中的每一个，以期回答有关大规模治理的常见问题。

1. 组织能力。设计、开发和部署所需的结构、角色和技能。
2. 共同实体 (CoE)。 CoE 的使命、范围和组织（或公司可能使用的该实体的任何其他名称）及其管理、启用、优化和确保产品采用的责任。
3. 设计权威。人员和流程的组织，以确保一致性、合规性和兼容性。
4. 运营模式。根据所需的业务流程标准化和数据集成水平，在整个公司内提供效率和可预测性的战略。
5. 架构类型和组织策略。基于运营模型确定 Salesforce 组织战略的能力、系统和功能的架构层。
6. 实施轴。 Salesforce 实施方法源自运营模式和业务目标。
7. 使命、范围和组织。基于 CoE、运营模型和实施轴的有组织的大规模治理支持计划。

SOGAF——一个由研究提供信息的框架

SOGAF 应用 MIT-CISR EA 模型和基于经验的实地研究方法来构建 Salesforce 转型计划和大规模治理框架。我分析并比较了转型计划的组成部分和功能与跨行业案例研究，以验证这个新框架。

SOGAF的创建包括三个部分：

• 第 1 部分。基于学术文献（五部分模型）、Salesforce 经验、案例研究和研究，定义大规模治理能力。
• 第 2 部分。应用 MIT-CISR EA 模型、价值学科和相关理论来定义规模模式的 Salesforce 治理。
• 第 3 部分。创建转型案例研究，以验证跨制造业、高科技、金融服务、消费品和能源行业的模型。案例研究的目的是为框架提供信息并特别回答以下问题：
  • 在实践中，治理模式是否真的可以识别？
  • 它们与运营模式相关吗？
  • 公司的实际用例是什么？
  • 组织和治理的成功模式是什么？

SOGAF 入门

您可以立即开始使用 Architect Digital Home for SOGAF Operating Models、Common Entity Framework 和 Architecture Types 上的可用资源，以帮助链接您的操作模型和组织战略。

作为即将推出的 Salesforce Enterprise Architect (EA) 计划的一部分，我还将发布有关 SOGAF 剩余功能的其他资源。这些剩余的能力将帮助架构师定义卓越中心的范围、使命和实施的具体重点。 EA 计划将包括业务架构课程中的几门课程，旨在为架构师提供大规模治理的最佳实践，并指导以业务为先的方法来推动技术决策。



有关 SOGAF 和更多 Salesforce Architect 内容的更新，请访问 Architect Digital Home。

原文：https://medium.com/salesforce-architects/an-operating-governance-and-ar…

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

Zachman和TOGAF是用于实现企业架构的框架。在本文中，我们将讨论两个最流行的企业架构框架：TOGAF和Zachman。我们还将包括如何选择以及额外资源的提示。

什么是企业架构？

企业架构（EA）是一种结构，用于传达组织的整个企业系统，包括技术、流程和信息资产。它从技术和业务的角度提供了各种各样的观点，允许组织采用一种有纪律的方法来管理这些系统。

换句话说，您的企业架构定义了可应用于企业IT和业务系统的选择约束，并且可以有三个核心组件：框架、方法和工具。使用EA解决了技术驱动型业务组织面临的两个关键问题：

• 在高度依赖的企业系统子集之间建立一个透彻的理解允许组织降低架构的总体复杂性。
• 帮助建立一个结构化和信息充分的决策过程，使技术与业务目标保持一致。

TOGAF：开放组架构框架

TOGAF是事实上的行业标准框架，为企业架构设计、规划、实现和治理提供了一种方法论方法。它提供了架构工件的一致视图，组织内的所有涉众都可以很好地理解。该框架的开放性使组织能够防止供应商锁定专有企业架构解决方案，允许他们在不遇到重大成本、安全和技术集成问题的情况下进行扩展和调整。

TOGAF框架在架构过程中提供了一系列可操作的步骤，称为架构开发方法（ADM）。ADM过程不是一个规定性的模板，而是一种通用的、适应性强的方法，可以应用于开发企业架构的各种组织用例。这些阶段可以根据不断变化的需求进行修改和重新排序，考虑到TOGAF-ADM使用迭代周期来管理和开发新的企业架构需求，这一点特别有用。

TOGAF的ADM部分提供了一个实现决策选择和生成所需模型的过程。这些步骤描述如下：

1. 架构（Architecture）远景：描述项目范围、确定涉众并获得必要批准的初始阶段。沟通业务目标和驱动因素。可以执行能力评估来评估现有的企业架构。
2. 业务架构（Business Architecture）：用于满足架构（Architecture）愿景的流程在此阶段定义。在此阶段，将与多个涉众协作执行详细的业务分析和建模。还规定了基线和目标的正式目标。
3. 信息系统架构（Architecture）：与前一阶段类似的活动现在针对支持架构（Architecture）远景的数据和应用程序架构（Architecture）执行。数据和应用程序架构的目标设计原则将在此阶段指定。
4. 技术架构（Architecture）：支持架构愿景所需的技术架构，特别是与业务和信息系统架构相一致的技术架构，在本阶段进行了详细说明。主要利益相关者将包括负责技术决策和投资批准的IT部门和高管。
5. 机会和解决方案：随着架构设计选择在早期阶段最终确定，将评估各种实现场景。此评估同时考虑了技术和业务方面，并确定了最佳折衷方案。
6. 迁移规划：这一阶段将吸引到上一阶段定义的最可行的决策选择和企业架构模型。根据成本、机会和风险制定实施策略。这些项目按优先顺序列出。
7. 实现治理：在此阶段，为所选项目指定必要的架构规范。在此阶段提供了一个完整的架构监督，描述了变更请求、合规性评估和解决方案构建块的描述。
8. 架构变更管理：在这个最后阶段，新的变更管理过程被定义为包含新的变更。

TOGAF有三大支柱，通过它们可以探索您公司的架构：

1. 企业架构域
2. ARM
3. 企业连续体

有关实现这个企业架构的TOGAF三大支柱和技巧的更多详细信息，请参见什么是TOGAF？TOGAF初学者指南。

Zachman企业架构

John Zachman是一位IT先驱，他了解IT驱动企业所面临的问题。为了解决这些问题，他在1987年开发了一个早期的企业架构方法论Zachman框架。

Zachman框架提供了一种基于模型的方法：

• 指定可交付成果
• 将企业系统子集的各个方面分类为矩阵形式
• 将它们与business-I环境的决策选择相关联。

使用矩阵，行根据列中指定的决策条件对组织中不同参与者的视图进行分类。列标题描述了什么、如何、在哪里、何时以及为什么。利用这些信息，每个矩阵单元描述每个企业子系统与组织的适当方面的关系。虽然框架没有提供实现指南或方法，但它通过提供整个企业架构的透视图，提供了工件的描述性焦点。

行类别包括：

1. 执行视角：描述业务目标和战略的范围上下文。
2. 业务管理视角：描述企业模型、设计选择和组织采用的流程的业务概念。
3. 架构师视角：描述如何满足业务需求的系统逻辑。
4. 工程师观点：技术物理学描述了如何使用技术解决方案来实现系统选择。
5. 分包商观点：这些描述了关于特定模块化工具组件的要求。
6. 企业视角：用户在其操作环境中所看到的运行系统。

有关框架的更多详细信息以及将其应用于公司的技巧，请参见Zachman框架简介。

选择TOGAF还是Zachman

您选择哪种企业架构取决于您的方法。

• TOGAF框架为定义创建或改进企业架构的过程提供了一种系统方法。通过它的ADM，框架提供了一个实现决策选择的过程，以便生成所需的模型。
• 另一方面，Zach框架更多的是一个本体论——一组结构化的表达式，描述了工件如何分类，从而创建、操作和更改。与TOGAF不同，Zachman使用各种企业透视图来确定、定义和计划有关企业系统的各个子集的详细信息。

您的组织可以选择使用其中一个，也可以同时选择这两个。这些框架可以相互补充，TOGAF描述了创建企业架构的详细过程，Zachman对人工制品进行了分类。

或者，您可以选择使用其他知名选项（包括ITIL？、PRINCE2或COBIT）来补充一个框架。

 

 

原文：https://www.bmc.com/blogs/togaf-vs-zachman/

本文：http://jiagoushi.pro/node/1075

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】

您需要了解的关于使用企业架构管理工具管理TOGAF®架构开发方法的一切。

• TOGAF®是什么?
• TOGAF®和ADM流程的价值是什么?
• TOGAF®在现代环境中的挑战是什么?
• TOGAF®的敏捷方法
• 基础(TOGAF®A期)
• 基线和目标架构(TOGAF®阶段B、C、D)
• 转型路线图(TOGAF®E、F期)
• 实施(TOGAF®G、H期)
• 如何获得TOGAF®认证
• 总结

TOGAF®是什么?

TOGAF(开放式集团架构框架)已经被企业架构师(EAs)用作规划IT开发策略的通用语言超过25年了。该计划于1995年成立，目的是协助企业和企业架构师以有组织的方式协调跨部门项目，以促进主要业务目标的实现。特别地，根据Open Group architecture Forum, TOGAF®的基本目标是通过以下方式支持关键业务需求:

• 确保每个人都说同样的语言。
• 通过对企业架构的开放方法进行标准化，避免锁定于专有的解决方案。
• 节省时间和金钱，更有效地利用资源。
• 实现可演示的ROI。

为了确保以系统和可重复的方式实施上述内容，可以在不同阶段遵循名为TOGAF®架构开发方法(ADM)的可定制过程，以管理任何大规模IT现代化工作的需求。

 

TOGAF®和ADM流程的价值是什么?

TOGAF®的ADM流程是专门为加快企业架构的四个领域的工作流程而设计的:

• 业务架构，它负责映射业务的操作层次结构、策略、功能和计划之间的关系。
• 应用程序架构，负责定义处理公司数据的相关应用程序，以及在整个基础设施中实现和部署这些应用程序的方法。
• 数据架构，它负责定义存储和集成数据的规则和标准。
• 技术架构，定义平台、服务和所有周围的技术组件，作为开发团队的参考。

图1:TOGAF®架构开发方法

通过TOGAF®ADM过程的九个阶段，这四个架构域将被迭代开发，以创建一个能够确保组织变革的平衡架构。作为一个行业不可知的过程，该方法旨在限制猜测，并促进企业架构程序的成熟——所有这些都同时聚集了企业特定的架构存储库来支持未来的项目。

TOGAF®在现代IT环境中的挑战是什么?

TOGAF®目前处于9.2版本，随着其定义和符号库的不断发展，以敏捷的方式与框架保持一致是不可避免的。这在很大程度上是由于TOGAF®的全面的架构遵从性审查过程，一个检查表涉及数百个项目的类别，例如:信息和系统管理;硬件和操作系统;软件服务和中间件;应用程序(业务、基础设施和集成规范);和信息管理。

然而，尽管遵从性是架构治理中不可缺少的元素，虔诚地遵守框架的标准对任何企业架构程序来说都是一项困难的任务。因此，对于希望有效地维护TOGAF®最佳实践的现代组织来说，为了有效地评估和编目it项目，在整个组织中获得利益相关者的参与是非常必要的。敏捷和TOGAF®确实能够共存，但为了实现这一点，必须建立团队间it实体标准化的协作途径。

敏捷方式的TOGAF®

一种弥合TOGAF和敏捷架构框架之间差距的流行解决方案是用于协同执行企业架构管理的共享平台。例如，LeanIX自己的企业架构套件(EA套件)提供了在ADM过程的每个阶段协同定义、实现和跟踪IT实体的功能。

特别是，它的好处可以在以下方面得到不同的应用:

基础阶段(阶段A)

当铺设ADM的第一块砖时，一个人必须:(1)定义一个架构愿景;(2)审查整个项目的范围;然后(3)计划哪些利益相关者将参与。LeanIX EA套件提供了一个灵活的数据模型，能够支持任何TOGAF®项目。

您公司的特定战略和业务模型将决定您的架构愿景的范围，因此考虑将TOGAF®“架构工作请求”和“架构定义文档”直接附在LeanIX事实表中——用于架构对象的所有信息的单页存储库——以补充阶段a。

项目事实表还可以为您的adm存储中心信息。这些页面可以定制，以显示估计的设置和实现时间线、预算成本、涉及的供应商，以及所有相关的应用程序及其相关的业务能力。

在ADM的早期阶段，LeanIX EA套件可以促进TOGAF®:

事实表格订阅

通过将个人分配到事实表中，列出与您的操作属性相关的名称和角色——无论是“负责的”、“观察者”还是“负责的”。这是一种简单的方法，可以看到谁参与了架构的开发以及出于什么原因。同样，事实表不仅可以配置为显示高层次的战略驱动，还可以显示对正在审查的应用程序负责的个人。

举例:在以下的“AC管理V1”情况说明书中，有三个不同工作职能和职责的人附在申请中。因此，谁负责维护数据就很清楚了(见图1)。

图1:IT管理角色设置

 

LeanIX EA套件中相关项目和应用涉众的视图。

基线和目标架构(阶段B、C、D)

在阶段A中设置了您的架构视野之后，是时候确定基线和目标架构之间存在什么差距了(例如，您拥有什么和您想要什么)。从业务到信息系统到技术架构，阶段B、C和D是揭示操作中实际存在的内容的阶段。

这时来自LeanIX EA套件的以下报告工作得最好。

在您的IT应用程序版图中实现合并后的协同作用[白皮书]:找出存在哪些巩固IT应用程序版图的方法，以及应该采取哪些步骤来从合并中巩固IT版图。»

应用景观

一旦应用程序被映射到业务功能并与如何使用它们的信息结合在一起，就可以对应用程序环境进行战略概述，以确定它们在未来架构中可能提供的好处。根据应用程序的使用级别和价值，判断应用程序是否应该保持不变，是否应该通过投资进行现代化以保存正在进行的业务价值，是否应该由于冗余而合并或替换，或完全消除(参见图2)。

图2:LeanIX应用程序景观报告

 

一份应用前景报告，通过五个等级(“不适当”、“不合理”、“适当”、“完全适当”和“不适当”)来说明某项行动的应用在技术上的适用性。

数据流可视化工具

数据流可视化工具详细说明了如何处理和交换数据对象。在visualizer中可以使用多种级别的技术属性，以帮助企业架构师获得应用程序完全集成的全面知识。

下面看看“AC Management V1”在操作中与其他服务绑定的方式。它直接发送到“HR Admin”，而“Payroll Europe”则与“Payroll Europe”通信，从而为“Salary Compact”提供数据(如图3所示)。

图3:LeanIX数据流

图表化应用程序的集成和处理的数据流可视化工具(“AC管理V1”)。

IT组件矩阵

检查IT组件(例如，数据库、操作系统、Web服务器等)及其相应的技术属性和服务生命周期，这些技术属性和服务生命周期来自IT组件矩阵报告中的所有操作层次结构。值得注意的是，LeanIX EA套件使用技术栈对IT组件进行分类，以实现对技术环境的完整概述。例如，如下面的图4所示，可以检查为提供者提供服务的生命周期。

图4:LeanIX IT组件矩阵

 

IT组件矩阵报告，显示操作中的各种技术组件(按提供商和技术堆栈进行安排)。

转型路线图(E、F阶段)

在架构被有效地描述和目标明确之后，E和F阶段是具体地定义未来步骤的时候。架构的重新设计发生了什么变化——蓝图能够指导涉众吗?

有了LeanIX EA套件，用户可以设计技术路线图，以避免淘汰和预见价值使用:

项目组合

按原样，一个项目对整个操作的现值是多少?LeanIX项目组合报告根据业务价值和项目风险对应用程序进行分组，以识别当前的需求。如果IT经理想知道保留或抛弃哪些应用程序，可以通过查看报告来进行评估(如下面的示例所示)。

如图5所示，架构数据的集群对业务价值提出了“显著的好处”，但也存在问题的分组只提供“边际好处”。

图5:LeanIX项目组合

 

显示业务价值与项目风险的项目组合报告。

应用矩阵

通过LeanIX应用程序矩阵报告的生命周期视图，确定不可或缺的应用程序何时将被淘汰——或者它们是否已经被淘汰了。请注意下面的图片，它显示了按部门和国家/地区列出的应用程序。巴西的“AC管理V1”服务将于2019年结束，但“AC管理V2”正在排队取代它。

除了生命周期之外，还有许多其他视图。根据功能是否适合应用程序质量的高级细节进行排序，以确定它是“不合理的”、“不够充分的”、“合适的”还是“完美的”。

图6:LeanIX应用程序矩阵

 

操作应用程序的生命周期，按年和工作状态安排，如LeanIX应用程序矩阵报告所示。

一个用LeanIX实现TOGAF的敏捷框架[海报]:一个循序渐进的演示如何使用精益EA工具遵循TOGAF的原则。»

应用路线图

很重要的一点是，要知道当申请的期限结束时，是否有合适的继任者。LeanIX应用程序路线图报告清楚地向用户展示了哪些是活动的、持续多长时间的，以及哪些正在准备取代它。此外，应用程序路线图列出了任何应用程序相应组件的生命周期。

在下面的路线图中，我们可以看到“AC管理V1”及其相关继任者的生命周期时间表。尽管它似乎在逐步淘汰(黄色)的过程中发生冲突，但应用程序的替代品(“AC Management V2”)保证会上线，以确保一个干净的过渡。

图7:LeanIX应用程序路线图

 

LeanIX应用程序路线图报告，按年显示应用程序的服务生命周期和后继程序。

实施(G、H阶段)

一切决定。愿景已经草拟，需求已经完美地向建设者表达。现在是实现架构的时候了。

使用LeanIX的变更管理协作方法密切监控其构建。LeanIX EA套件实现了TOGAF®ADM最后两个阶段的跟踪:

指示板

在与LeanIX EA Suite主页绑定的可配置拖放仪表板中，可以观察到与项目相关的新操作和未决操作。仪表板展示了治理体系结构需要什么，所有这些都在一个地方，以指导工作流和支持响应EA行为。

图8:LeanIX仪表板

LeanIX EA套件中的仪表盘显示“每个业务的应用程序临界性”和“数据敏感性”统计数据。

调查工作流程

更新项目所需的信息可以从所有责任方收集，而无需发送单独的邮件。使用LeanIX调查，EAs可以请求关于紧迫主题(如GDPR)的当前数据，将信息保存在模板中以供重用，并以明确的术语返回结果——即使调查仍在运行。

如下图所示，在一个与IT安全标准相关的示例中，用户可以向LeanIX调查添加自定义参数。

图9:LeanIX调查

查看LeanIX EA套件中的调查模板(“根据IT-Grundschutz评估应用程序安全性”)。

应用景观

检查过去、当前或计划的公司范围内的应用程序的生命周期。在LeanIX EA套件中直接查看这些数据，或者直接下载到。pdf表单中。

在下面的例子中(图10)，许多分配给客户关系管理类别的应用程序都处于“淘汰”或“生命结束”阶段。

图10:LeanIX应用程序的景观

 

应用程序全景报告中的应用程序的生命周期。

如何获得TOGAF®认证?

要理解LeanIX EA套件带来的变革好处，最可靠的方法之一是花时间学习TOGAF®的基础知识。要做到这一点，TOGAF®9.2认证可在通过开放组的两项资格考试后获得，培训可通过自主课程或经认证的项目进行。

TOGAF®提供的两种认证是:

• TOGAF®9.2 Foundation(验证个人理解“TOGAF®术语、结构和基本概念，并理解企业架构和TOGAF®标准的核心原则”)。
• TOGAF®9.2认证(确认了除了TOGAF®9.2基础之外，候选人能够分析和应用这些知识)。

更多关于获得TOGAF认证的信息，请访问开放集团的网站。

总结

今天的IT管理敏捷方法的成功很大程度上归功于TOGAF®首先设置的架构标准。然而，在蓬勃发展的现代企业中，数字化的热潮要求企业体系结构——不管是新体系结构还是老体系结构——认识到所有最佳实践，以便真正集成信息、业务和技术网络。

在LeanIX EA套件中使用报告和数据收集方法来简化TOGAF®ADM的各个阶段，这是一种将数十年的EA最佳实践全部利用起来的方法。

是否建立你的

• (1)基础架构愿景使用全面的事实表,
• (2)评估current-to-future业务基础设施与应用景观的视图,
• (3)做投资决策的应用程序使用详细的指标和矩阵,
• 和(4)监督实现可配置的仪表板和调查,

LeanIX EA套件旨在满足企业架构师的每一个品种。

 

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

Zachman框架是John Zachman在1987年提出的，成为工程企业架构中广泛使用的方法。它以信息系统架构框架（frameworkforinformationsystemarchitecture）的名义发表在IBM的系统期刊上。Zachman于1964-1990年在IBM工作，是IBM业务系统规划（BSP）的创始人之一。

Zachman框架背后的基本思想是，可以使用不同类型的描述，以不同的方式为不同的目的描述相同的复杂项。这个框架提供了36个必要的类别来完全描述任何东西，特别是复杂的东西，如制成品。这36个类别由6行6列组成，采用二维矩阵的形式。

框架的六行是：

1. 计划者视图（范围上下文）-此视图描述业务目的和策略，为其他视图定义竞争环境。
2. 所有者视图（业务概念）–此视图显示企业的哪些部分可以自动化。
3. 设计器视图（系统逻辑）–此视图概述了系统将如何满足组织的信息需求。
4. 实现者的观点（技术物理）–这是一个系统在解决生产约束时如何实现的表示。
5. 子构造函数视图（组件组装）-这些表示说明了特定系统元素的实现细节。
6. 用户视图（操作类）-这是操作环境中运行系统的视图。

这些列表示向企业提出的疑问或问题。

1. 什么（数据）–什么是业务数据、信息或对象？
2. 如何（功能）–通过定义流程，业务是如何工作的？
3. 哪里（网络）-业务运营在哪里？
4. 何时（时间）-何时执行业务流程？
5. 为什么（动机）–为什么选择解决方案，它是如何产生的，以及是什么激励了某些活动的执行？

Zachman框架的规则

Zachman定义了7条使用框架的规则。

规则1：不要向框架添加行或列。

几千年的语言经验将确定这六种原始疑问句是谁、什么、何时、何地、为什么以及如何。如果你能回答所有这六个问题，那么你就可以得到关于主题或对象的任何其他问题的答案。向框架中添加行或列将使分类方案非规范化。

规则2：每一列都有一个简单的泛型模型。

在我们的案例中，框架的每一列都描述了分析目标企业中的一个独立变量。因此，任何一列的基本泛型模型都非常简单：它表示的变量（抽象）与自身相关。

规则3：每个单元模型专门处理其列的泛型模型。

任何给定单元格的特定模型都必须根据行透视图的约束、语义、词汇表、术语和事实进行自定义。此外，考虑到单元描述构成了管理变更的基线，因此（元）模型将必须表达由变更到该单元模型所影响的所有概念。因此，给定单元格的特定（元）模型将从通用的列模型开始，根据行的语义约束进行调整，然后可能进行扩展，以容纳所有相关概念，用于表示单元格行透视图的约束以及管理对单元格模型本身的更改。

规则4：任何元概念都不能分为多个单元。

该框架构成了一个干净的规范化分类系统，每一列都是唯一的。没有一个元概念可以分为多个单元。没有冗余。这是使框架成为良好分析工具的一个基本因素。

规则5：不要在单元格之间创建对角线关系。

首先，业主、设计师、建筑商和分包商都在用同一个词来表示完全不同的东西，这就造成了一个非常混乱的沟通问题。企业中的人可能会说同一种语言，使用同一种语言，但可能无法有效地相互沟通。禁止对角线的结构原因是因为细胞关系是传递的。在逻辑上更改单元格可能会影响同一列中的上下单元格以及同一行中的每个其他单元格。

规则6：不要更改行或列的名称。

不要在通用框架或企业特定框架中更改行或列的名称。如果更改行和列的名称，也会更改受影响行或列的含义。您可以对框架进行反规范化，使其不再全面。

规则7：逻辑是通用的和递归的。

框架的逻辑是通用的。它可以用于对任何事物的描述进行分类，并分析与其架构组成相关的任何事物。它是递归的。它可以用来分析建筑结构本身。框架是惰性的。它不知道用来分析什么。只有分析人员知道分析对象并确定分析的边界，所选择的分析边界具有深远的影响。

Zachman框架是如何使用的，在哪里使用的？

在当今复杂的业务环境中，许多大型组织很难应对变化。这一困难的部分原因是缺乏对组织不同领域中复杂结构和组件的内部理解，在这些领域中，有关业务的遗留信息被锁定在特定员工或业务部门的头脑中。

Zachman框架提供了一种对组织架构进行分类的方法。它是一个主动的业务工具，可用于为组织的现有功能、元素和流程建模，同时帮助管理业务更改。该框架借鉴了Zachman在复杂产品中如何管理变更的经验。John Zackman强调框架可以扩展到整个企业架构，而不仅仅限于信息架构。

John Zachman认为框架被用作：

1. 一个计划工具-帮助你定位问题并做出明智的选择。
2. 一个解决问题的工具——控制业务抽象的复杂性，实现单个业务变量的隔离。
3. 通过将工具和方法映射到框架来评估它们，从而证明一种中立的方式来对它们所做和不支持的事情进行编目。
4. 用于构建灵活的组件架构和系统的上下文，这些架构和系统能够支持高比率的企业更改，并替换由于“上下文外”而“未集成”的“现有系统的库存”

将Zachman框架付诸实践。

在Zachman框架中开始的逻辑点应该在二维矩阵的左上角，然后沿着表格向下。用于表示特定业务领域的相关业务信息或模型可能已经存在于业务计划、项目计划、系统规范、程序指南或其他文档中。

当你浏览这个矩阵时，会有一些空白需要填补，其中只有一个人或少数专家知道的隐含信息需要明确，并提供给更广泛的受众。可能存在重叠或冗余的情况。目标是管理变更，减少冗余和重叠。

 

本文：http://jiagoushi.pro/node/1076

讨论：请加入知识星球【首席架构师圈】或者加小号【ca_cea】

我惊讶于有人发现他或她可以通过企业架构和 IT 架构实现什么时闪闪发光的眼睛。

这种奇妙的效果通常始于一次随意的对话，例如当您在某个活动中第一次见到某人时发生的一种情况，揭示了您所在行业的颠覆性变化。

前几天我进行了那次谈话。

从主会议室出来，我口渴了，就往吧台的方向走去。新饮料？当然，算我一个。这种饮料异常绿色。与我童年在巴黎时使用的“空竹薄荷”中的一种颜色相同。但是这个玻璃是有雾的。当我看着接受者试图猜测魔法药水是由什么制成的时，调酒师正在观察我。犹豫的时候，他说：“是从日本来的。你会喜欢的”。尽管他很有信心，但他并没有说服我。他怎么会知道我的口味呢？尽管如此，我还是喝了神秘的饮料，而且，天哪，他是对的。 ——不管叫什么名字——都很好吃。

我旁边的人正在尝试一种雾红色的丹药。当她看到我脸上的惊讶时，她参与了谈话。

“这是一个有趣的演示。很棒的演讲者。如今，一切似乎都被技术加速了，不是吗？嗨，我的名字是 X，我是 {cool company name} 的数字主管。”

我礼貌地回答，自我介绍。

“很高兴见到你。我叫扬尼克。 ING 首席架构师”。我和她握手，接着说：“确实，我们正在经历有趣的变化。为了更好，我相信。”

“啊，所以你是从事房地产建设的？非常好！事业蒸蒸日上，你一定是个幸福的人！”

“我确实在施工。然而，我建造的是企业，而不是架构。”

她停顿了几秒钟。 “你是什么意思？你不是在管理自己的建筑公司吗？”

“不是一家公司，而是地球上最大的金融技术集团之一的企业架构部门。不过，这感觉就像经营自己的企业一样。我团队的专长包括以最优化和可持续的方式有条不紊地设计和规划产品、服务甚至整个业务线的开发。我们提供的一切都符合客户的需求，并根据其财务、时机、机会、技术、监管范围等进行。我们考虑所有方面。基本上，无论多么复杂，我们都能为您提供解决方案。”

“啊，有趣！我什至不知道有这样的工作。 “所有方面”，你的意思是……？”

• “假设您想出了一个绝妙的主意，通过提出新的产品线或重新考虑您的服务来使自己与众不同。使用企业架构构建方法，我将首先指导您定义和详细说明您的需求和您想要实现的目标。很多时候，你认为你想要的并不是你需要的。

 

• 其次，我会问你一些问题来发现需求，包括一些你一开始没有考虑过的问题，还有一些你不认为关心它们很重要的问题。

 

• 第三，我们将列出您的限制条件并找出您必须遵守的法律框架。鉴于您的预算和资源，我将与您核实您期望的结果。目的是从一开始就揭开信仰的神秘面纱，然后我将与您分享如何获得您想要的东西。它类似于建筑行业，您必须遵守一些规则，例如环境准则、使用的材料、施工许可等。”

“好吧，我现在开始明白了。告诉我更多。”

“当然。

完成上述活动后，架构师进行第一次设计。这是满足您期望的解决方案的草图。目的是评估影响，同时使产品更加直观和有形。随后进行了一些研究，以尽可能最好的方式确定可以满足您需求的组件。我用 S 说“方式”，因为重要的是您在此过程中所做的选择。这一切都归结为为您提供替代方案以保持您的选择自由。

最终，架构师将引导您做出最佳决策。

在这个设计阶段，它们是几个研讨会、讨论、谈判和信息会议，以详细说明主解决方案设计并精简财务分析。

从那时起，我们将根据协议和工作范围共同启动档案。这种相互理解就像合同一样。

• 第一阶段从订单开始，其结果将是对您的需求、架构蓝图、施工规划、报价的迭代分析，与产品开发公司的任何合作伙伴都可以从中制造您的产品和服务。”

“这看起来是一项非常有趣、非常复杂且要求很高的工作。你能在所有这些领域都有知识吗？ “

• “视情况而定”——这是架构师最喜欢的名言。

“架构师至少是两个领域的专家：业务领域和技术领域。它们是 PI 形的。例如，我的职业生涯始于开发工程师，后来发展成为信息系统集成专家，专业是金融服务和保险。

此外，他们必须了解其他领域的目的和机制，以及它们如何组合在一起。他们培养了系统思维。例如，一家公司有一个营销部门、一个财务部门、一个 IT 部门、一个销售部门等。它们中的每一个都有其存在的特定理由，并且它们由大量的活动组成，这些活动是其基本要素。公司机器。在销售之前，营销的目的是展示、展示、吸引客户，同时分析潜在客户，同时继续吸引现有客户。为了更好地销售，IT 将产品的销售目录和规格数字化，同时在移动应用程序上提供 CRM，以便销售人员可以随时随地与潜在客户联系。

我可以继续说下去，但重点是架构师将这些领域中的每一个、每个用户交互、每个流程、每个应用程序、每个技术、每个数据、每个技能都视为一个构建块，需要组装起来以满足您的需求并遵守与商定的要求。这就像得到几盒乐高积木，找出相关的积木，并详细说明实现构建的说明。因此，无需成为多个领域的专家，但您需要了解他们的目的并了解行业如何与您的客户相关。在实践中，我们会在需要时联系专家。”

“嗯。这听起来很容易理解，但执行起来却很复杂。”

“你是对的。”

• “但我以前怎么没听说过企业架构师？想想看，从企业达到一定规模的那一刻起，你的工作就显得很有必要了。”

“也许你做到了，架构师比你想象的要多。由于各种历史原因，架构与信息技术部门相关联。因此，大多数时候，公司里的人都认为我们就像做 IT 工作的 IT 人员，而我们提供的是业务和技术战略、业务和工程分析、业务和工程设计、业务和工程规划以及业务和工程创新。

价值链中的几乎每一个变化和改进都需要软件和硬件。所以这并不让我感到惊讶，我们的核心技能是工程。我们在制造可预测性和精度方面茁壮成长。

尽管如此，我完全理解为什么人们将架构师仅归类为技术领域，如果他们不断地使用他们的专业知识的一部分来展示自己。有时候很舒服！”

“或许。既然你提到了。通常，每当我们需要更改、创建新功能或修复问题时，我们都会与 IT 专家讨论。我们信任他们，但有时感觉他们让事情变得过于复杂。”

我们俩都开怀大笑。

“我只是在这里分享我的感受。我无法评估他们是否可以做得更快或更好。我们知道他们会尽力而为。然而，我们希望我们拥有更灵活、更现代的 IT 系统、更自动化的东西和漂亮的用户界面。好吧，至少他们确实有效！”

“相信我，这才是最重要的。我有一个非常简单的架构座右铭：

• 第一，它需要一直工作得很好，
• 第二，它必须易于使用、记忆、教学和维护
• 第三，它应该看起来很棒。”

“但愿如此。不过，这让我想知道……如果业务和 IT 人员已经可以构建东西，我为什么需要架构师？”

“好问题。为了回答你，我要开始：我更喜欢你不需要我。”

“我没想到会这样。我很困惑……也很好奇！”

“我知道。为什么您需要土木建筑师来修理灯泡、更换厨房水槽，甚至更换建筑物的外墙？不，您不需要参加活动。你打电话给电工、水管工或者你自己做。您需要专业的建筑商或维修人员。自治对每个人来说都是最好的。但是，如果您正在寻找建造新房子、用新房间扩建房子或改变浴室的位置，您可能需要致电您的建筑师。最终，您可以在没有人的情况下做到这一点。但是，您决定冒着风险花费比预期更多的钱，让建设花费比预期更多的时间，收到可能不符合您期望或更糟的东西。

决定权完全在你。”

“我明白你的意思。那么我应该何时何地聘请架构师？我需要蝙蝠符号吗？”

“对于大多数小的变化，你不需要架构师。经验法则，如果结构没有改变，影响的规模和数量保持相似，您就不会触及您的基础，也不会带来任何新的实质性数据或业务功能，请询问您的工程师或高级业务分析师做出改变。但是在某些时候，您的公司变得足够大，以至于人们开始失去视线、控制权和对一切如何结合在一起的理解。企业的系统过于复杂，无法由每天忙于特定任务的人处理。此外，这既不是他们的核心知识，也不是他们的核心活动。似乎这还不够，技术颠覆的步伐还在不断加快。

根据经验，当您执行以下操作时，您需要一名架构师：

• 想要一些定制的东西
• 正在处理复杂的工作计划
• 不知道从哪里开始
• 需要获取或利用一项技术
• 寻求指导以构建可持续和可扩展的企业功能
• 需要以良好的准确性计划可行的策略
• 要么你想要每个人都能得到的东西，要么你想要定制的东西。”

“有不同类型的架构师吗？我的意思是，我们有不同类型的建筑工人，比如水管工、木匠、电工等。”

“架构师是……架构师。有架构师的味道。假设他们有专长。他们中的一些人是基础设施方面的专家，一些是数据方面的专家，还有一些是软件方面的专家，而另一些人则专注于特定行业的专业知识。从客户的角度来看，唯一重要的是他们提供相同的服务并且他们一起工作。

他们具有相同的基本知识和操作方式。不过，架构师的技术可能有所不同。随着 Zachman、TOGAF 等各种架构方法的实践。一些公司建立自己的，因为它更适合他们的行业和他们的组织，例如 EAgile for ING。有些更专业，比如我针对初创公司和创新组织的 AMASE 方法。

我可以告诉你更多，但我会把这个留到下一次。”

“我感谢您的这些解释和您的时间。坦率地说，这令人大开眼界。我需要和我的执行同事谈谈。”

“我很高兴，X 女士。还有一件事。你知道“架构师”这个词的由来吗？”

她看着上方，仿佛在看记忆深处的答案。然后一秒钟后，火花。她用闪烁的眼睛说：“架构大师！”。

 

原文：https://yannick-huchard.medium.com/leading-you-to-the-best-decision-70a…

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

在这个圣帕特里克节，当您选择最适合您的组织的企业架构(EA)解决方案时，如果有一罐金子和爱尔兰人的运气在您这边不是很好吗?为自己倒上一杯醇厚、柔滑、奶油味的吉尼斯黑啤酒，然后悠闲地考虑该选择哪种EA工具，这听起来很愉快，但其实还有更好、更有效的方法来选择合适的工具。当你完成了工作，并为你的公司选择了最好的EA工具之后，那么无论如何你都应该获得吉尼斯——你已经赢得了它!

投资于企业架构解决方案是一个明智的业务决策，它将增加透明度，并为提高效率和业务增长提供机会。考虑将应用程序链接到流程，以了解IT系统在多大程度上支持业务活动。或者，您可能希望对系统有更高的可视性，这样就可以执行影响分析，并在计划更改时更快地做出决策。EA解决方案将帮助您执行这样的计划。

无论您是希望实现一个工具来解决一个特定的挑战，还是推出一个企业范围的解决方案，在为您的公司选择最佳工具之前，都有一些重要的问题需要回答，还有许多问题需要考虑。您应该评估哪种工具?您与解决方案供应商的关系有多重要?你的员工的过渡会有多顺利和容易?这些是选择EA工具时需要考虑的基本问题的示例，然后再决定是否使用EA工具，并沿着实现路径开始赚钱。

为了让您开始您的成功之路，这里有3个步骤来帮助您为您的组织选择正确的EA工具。

1. 确定你的短期和长期目标。

您的组织正在经历什么样的挑战?您认为您的新EA工具将提供哪些好处来帮助克服这个挑战?确定你希望在最初的6个月到1年内实现的可衡量的目标。这些目标不需要是大规模的、无所不包的变更，但是每一个都应该使您更接近于向业务交付价值。对于你设定的每一个目标，考虑问问自己这对企业有什么特别的帮助?

2. 寻找灵活的EA解决方案供应商，与您合作，而不是与您作对。

理想情况下，您应该热爱您的EA工具供应商，并将该公司视为您的合作伙伴和可信任的顾问。一个有知识的专业人员，为你腾出时间，并真正有你的公司的最佳利益，将是你最好的资产之一，并为你提供宝贵的指导，你开始这一旅程，以改善你的运作。他们以前已经成功地做到了这一点，也可以帮助你做到这一点。

3.确保解决方案能够随着业务的增长而增长。

灵活的、可扩展的、可以集成到日常业务操作中的解决方案将比点解决方案提供更多的长期ROI。你不希望每隔几年就购买新的EA解决方案。因此，在今天扑灭紧急的、燃烧的大火很重要的同时，您还需要利用特性和可见性来满足明天扩展操作的需求。要从EA解决方案中获得最大的投资回报，请在评估供应商时考虑您现在和以后的需求。

愿爱尔兰人的好运(和一些明智的选择策略)与你同在!

愿你的双手永远有工作可做

愿你的钱包里总是装着一两个硬币;

愿阳光永远照在你的窗玻璃上;

愿每一次雨后都有一道彩虹;

愿朋友的手常在你身边;

愿你的EA工具使你心中充满喜悦。

 

 

Zachman 框架使用 36 列矩阵来帮助组织您公司的企业架构并深入了解您组织的 IT 资产。

什么是 Zachman 框架？

Zachman 框架并不完全是一种方法论，至少不像大多数 IT 管理框架那样，主要是因为它不提供处理数据的特定流程。相反，它被认为是一种“本体”或“模式”，可以帮助组织企业架构师工件，例如文档、规范和模型。该框架考虑了受工件影响的人，例如企业所有者，并将其与正在解决的问题或问题进行权衡。

Zachman 框架最初由 IBM 的 John Zachman 于 1987 年开发，此后经过多次更新。它旨在组织和分析数据、解决问题、规划未来、管理企业架构和创建分析模型。

Zachman 框架在今天仍然与现代企业息息相关，主要是因为技术环境变得越来越复杂，遗留技术和信息分散在整个组织中，经常被转移到其他系统和解决方案的员工所迷失。借助 Zachman 框架的 36 列矩阵，您可以对组织的所有架构进行分类，通过让您详细了解公司的 IT 资产，帮助您的组织在面对变化时保持敏捷和灵活。

Zachman 框架模板

Zachman 框架使用 36 个类别来描述从产品到服务，再到硬件和软件的任何事物。类别按六行六列组织，形成一个包含 36 个单元的二维矩阵，可帮助您可视化主题、问题或产品。

Zachman 框架模板的列概述了围绕所讨论架构的基本问题（谁、什么、在哪里等），而行代表项目中涉及的每种类型的利益相关者的观点。然后根据每个单元格中代表的基本问题和观点，在完成的矩阵中填写流程、必要的材料、重要角色、相关位置以及与项目相关的任何目标或规则。

Zachman 框架矩阵的六行包括：

• 规划者的观点（范围）：这一行是您确定业务计划或战略并确定矩阵中将解决哪些问题或关注点的地方。
• 所有者的观点（业务概念）：第二行是您将确定业务需求和业务执行计划所需的资源的位置。
• 设计师的观点（系统逻辑）：第三行确定计划将如何满足业务需求。这一行对应于处理业务流程的数据、流程和功能的系统分析师所做的工作。
• 工程师的观点（技术物理）：第四行包括有关如何实施战略以及团队将使用哪些工具、技术、材料和约束的相关信息。
• 技术人员的观点（组件组装）：在这一行中，您将包含对产品、服务或硬件的需求表示。
• 用户视图（操作类）：最后一行包含有关功能系统及其在 IT 或业务环境中如何工作的信息。

Zachman 框架模板的六列包括您将在此过程中提出的所有问题：

• 什么（数据）：您可以在此处确定项目所需的业务数据、信息和要求。
• 方式（功能）：“方式”或“功能”列标识流程如何工作和影响业务。
• 地点（网络）：此栏包括“地点”，其中包括所有系统网络和进行业务运营的相关地点。
• 谁（人员）：在第四栏中，您将确定关键利益相关者并确定项目的所有相关人员。
• 何时（时间）：第五列是您将确定何时何地在公司中执行业务流程的位置。
• 为什么（动机）：最后一栏是您将确定选择最终解决方案的原因以及倡议或项目背后的动机。

Zachman 框架规则

该框架旨在与物理对象和概念想法一起工作。要填写矩阵的列和行，您需要来自利益相关者的输入，并且可能包括冗余和重复信息。我们的目标是尽可能减少这些冗余，最后以一份简洁的文档为您的组织的企业或 IT 架构提供清晰的画面。

Zachman 为完成二维矩阵建立了七项指导规则或原则：

1. 列没有顺序，但应从最重要的类别开始按自上而下的顺序排列。这将特定于您的 IT 项目或关注点，并且在应用于其他产品或服务时可能会发生变化。您应该避免添加或删除任何列或行，因为您将需要它们来获得完整的画面。
2. 每列都有一个简单的通用模型，并且可以在该列中拥有自己的元模型。
3. 每列的基本模型必须是唯一的，并且避免在任何其他列中重叠或复制数据。
4. 每一行都描述了一个独特的、独特的视角。您应该避免将任何元模型或概念归于多个单元。该框架的一个关键元素是它避免了最终二维矩阵中的所有冗余。
5. 如果您成功使用规则 2、3 和 4，您应该有一个矩阵，其中每个单元格都是唯一的。强烈强调这一点，也是该框架的基石之一，从而为您的架构提供了独特的详细和信息丰富的视图。
6. 避免更改行或列的名称。如果利益相关者以不同的方式使用相似的术语，这可能会改变含义或引起混淆。
7. 该逻辑是递归和通用的，这意味着它可用于分类或分析与所讨论的企业架构相关的任何内容。由分析师来确定目标和边界，这些决策会对矩阵的最终结果和计划或项目产生重大影响。

Zachman 框架培训和认证

Zachman 框架是一个敏捷且灵活的框架，它提供了二维矩阵的严格结构。在您完成的 36 个单元中，您将能够为问题建立解决方案并在您的组织中实施更改。但是，如果您想了解有关该框架或如何使用它的更多信息，Zachman International 通过 Zachman International 提供官方 Zachman Framework 培训和认证。

在为期四天的“动手建模研讨会”中，您将看到 Zachman 框架的真实示例，并学习如何构建和实现原始模型。您将学习如何在您自己的公司中实施 Zachman 框架和概念，以及一些有助于支持该框架的方法和工具。

原文：https://www.cio.com/article/193229/what-is-the-zachman-framework-a-matr…

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

Marc Lankhorst，Fabian Aulkemeier

企业架构，敏捷软件开发和DevOps有时被认为是不和的。我们认为他们可以进行富有成效的协作和界面，但您如何做到这一点？如何协调这些世界的概念和流程，弥合文化差距？

在之前的博客文章中，我们和我们的同事已经写过关于以精益和敏捷的方式进行业务转型的必要性，企业架构和敏捷开发流程可以协同工作的方式，以及如何将敏捷概念映射到ArchiMate建模语言支持这种合作。

在本博客中，我们想讨论几个突出企业架构，敏捷开发和DevOps之间协作的用例。我还将讨论BiZZdesign的软件如何与敏捷和DevOps工具协同工作，以简化组织变更流程中的价值流，帮助您成为适应性企业。

为什么要关联EA和敏捷/ DevOps？

敏捷方法对提高对变化的响应能力有很大帮助。但是，它们并不是您需要的唯一方法，如果应用不正确，它们甚至可能会损害企业的整体适应性。

一般而言，组织越大，其各部分（能力，资源，流程，系统）之间的互连和依赖性就越大，企业架构就越重要，就会提高适应性，使部分与整体战略方向保持一致。

在较小的组织中，一些敏捷/ DevOps团队可以协调他们之间的变更，管理层的线路足够短，可以直接向团队传达战略方向。然而，在大型组织中，可能有数百个敏捷团队，每个团队都在大型“企业机器”的一部分上工作，并且需要更多的协调。如果敏捷团队建立了无视环境的敏捷孤岛，那么您仍然无法获得适应性和灵活性的最终结果。此外，未来的变化可能会变得更加困难，这就是良好的架构至关重要的原因。

已经创建了诸如LeSS和Scaled Agile Framework（SAFe）等方法来处理这些情况下的协调团队。下图显示了SAFe的简化版本，突出显示了一些重要的术语和反馈循环。

他们的架构方法主要关注软件开发的需求，因此，主要从软件和解决方案的角度来看待企业。但是，企业不仅仅是软件。这是EA提供的“全局”视图增加价值的地方，因为它还包括除软件用户之外的其他利益相关者，包括所需（和不需要的！）业务成果，要开发或改进的功能，所需资源，业务流程，IT和要实现的物理基础设施等等。

EA和敏捷的用例

在许多情况下，企业架构和敏捷开发的结合是非常宝贵的。例如，在以下情况下，此协作至关重要：

1. 优先考虑业务价值。基于对企业体系结构的分析，您可以了解不同的epics和功能如何与业务流程，功能，业务目标和相关的利益相关者相关联。通过跟踪您的体系结构模型，您可以了解哪些业务目标以及哪个利益相关方对该功能做出了贡献，以及这是否比其他功能更重要。像这样的客观信息可以帮助产品所有者停止“分贝驱动”的优先级排序，其中具有最响亮的声音的用户获得他们的愿望。
2. 规划工作的连贯性。您的体系结构中的依赖项可用于规划敏捷活动：如果功能A依赖于功能B，则首先构建B.这在SAFe称之为“促成因素”中更为重要：解决方案的各个方面不直接向用户提供功能，但间接支持此功能并实现长期质量和发展。它的“建筑跑道”概念就是一个例子，您可以及时为新功能奠定技术基础。不过，这个概念可以扩展到软件之外。例如，投资于员工技能可以为许多未来的发展和改进提供基础。
3. 跟踪进度。如果某个功能或启用程序被延迟，例如敏捷团队希望将其推送到下一个sprint，则需要将对整个解决方案的影响纳入该决策。这个团队可能有充分的理由优先考虑其他事项，但通常他们没有足够的信息来理解后果。能够追溯到总体目标将证明决策将如何影响发布，项目完成日期等。它还可以帮助团队提出诸如“这对组织的业务目标有何影响？”等问题。哪些客户群体会受到影响？我们可以通过优先考虑其他功能（可能是其他团队）来减轻这些影响吗？“这就是体系结构模型非常有用的地方，特别是对于推动者而言。由于启用程序不提供最终用户功能，因此当您推迟它们时，很少有人会抱怨。但是，它们对于许多不同的功能和解决方案的长期可行性通常很重要，因此跟踪这些依赖关系是关键。
4. 使用新见解更新架构。在敏捷环境中，企业架构不是对长期未来状态的静态描述。相反，它是一种共享工具，可以根据自上而下和自下而上的输入提供愿景，指导并确保整个企业的一致性。业务战略，目标和期望的结果提供了自上而下的方向，而本地创新和改进提供了自下而上的变化。因此，企业中的各个团队从他们自己的角度共同致力于架构。

EA和DevOps的用例

当我们使用DevOps扩展敏捷开发时，还有其他用于架构的用例可以添加到上面的列表中。一般而言，运营管理并不总是意识到架构的好处。但是在敏捷/ DevOps的快速变化周期中，以及解决问题的“失败前进”方法，DevOps的架构变得更有价值。例如，架构模型可用于：

1. 事件相关。架构模型允许您以集成的方式查看整个企业中的事件。例如，如果黑客试图同时使用不同的攻击媒介危害您的安全性（例如社会工程，网络钓鱼，病毒和物理入侵），那么架构模型可以帮助您将这些关联起来以了解其实际目标。
2. 根本原因分析。通常，必须追踪整个系统链以找出故障或问题的原因。架构模型在这方面提供了很大帮助，因为它们为运营管理提供了可能需要调查的各种互连和依赖关系。
3. 风险分析。在实施更改之前，您需要知道企业的哪些部分可能会受到影响。低风险变化可以快速实施，但高风险变化需要更彻底的分析和缓解措施。

在本系列的下一部分中，我们将介绍如何使用模型和工具支持在Enterprise Studio和HoriZZon中集成敏捷开发和体系结构。敬请关注！

本文: http://pub.intelligentx.net/enterprise-architecture-enterprise-architecture-and-agiledevops-adaptive-enterprise-cornerstones

讨论:加入知识星球【首席架构师圈】

作为开放小组的一员，多年来我一直是企业架构师协会加州分会的成员和官员，同时也属于INCOSE——国际系统工程委员会(SE)。几年前，我们举行了一次两章的联席会议，讨论企业架构(EA)与系统工程(SE)的关系。在那次会议中，发生了一场激烈的辩论，当时的INCOSE当地分会主席强烈主张，EA不仅包含在SE学科中，而且两者之间的区别是无关紧要的。他认为，系统的系统(SoS)和企业之间没有区别，使用后者不仅是多余的，而且过分强调了业务的概念。

东南社区并没有完全认同这一立场;事实上，在INCOSE中有一个INCOSE架构工作组(AWG)，其任务是“在系统工程中扩展架构实践并推进知识体系”。这个定义将EA的实践放置在SE的规程中，而不是与它一起实践的联合规程。在现任政府之前，国防部举行了年度DoDAF (Department of Defense Architecture Framework)会议。

在其中一次演讲中，国防大学的一位讲师发表了一篇关于如何将DoDAF纳入SE学科的论文，这与AWG的观点是一致的。我们中的一些人指出EA所涉及的远不止工程，因为它还包括企业中的社会、文化、业务、管理和其他行为因素。另一位与会者问出席全体会议的500多人，有多少人认为自己是工程师。作为回应，只有10%的人举起了手。这强调、支持并导致了对EA(在这里的DoDAF上下文中)作为其自身实践的完整性的额外讨论。

认识到EA来源于多个规程，包括SE，是自TOGAF 8以来实践的开放组架构框架(TOGAF)的基础。现在在TOGAF 9.2中有一个强烈的认识，即在TOGAF的架构开发方法(ADM)中，阶段B(业务架构)是其他架构领域(数据、应用程序和技术)的主要发展。目前，有许多不同的架构框架。TOGAF认为它可以与其他框架和方法结合使用。这一立场是当前国际重大倡议在OMG(对象管理组织)协调建立一个新的统一架构框架(UAF)，作为一个扩展试图协调的主要防御架构框架（major defense architecture frameworks）——DoDAF MoDAF(国防部架构框架-在英国使用)和NAF(北约体系结构框架)。这一努力被称为UPDM或DoDAF、MoDAF和NAF的统一概要。与这一进步相一致的是，人们也认识到整合来自其他主要框架的领先实践的重要性，包括联邦机构管理和预算办公室(OMB)管理的FEAF 2(联邦企业架构框架)，以及来自各种商业架构框架。

在使用SysML或系统建模语言作为UPDM和UML开发的主要语言时，OMG的这个活动具有很强的系统工程重点。这再次提出了EA与SE的关系。诚然，这两个学科之间有一个共享的词汇表和关注点。例如，根据MITRE的Mary Tolbert的说法，以下是使用SysML的OMG试图从基于文本的实践转移到基于模型的实践的主要系统工程过程。这些过程包括项目管理、需求管理、体系结构(系统体系结构)、测试用例的测试、配置管理和风险管理。然后，一般的SE远景是确保从架构建模工件相关联的信息中创建各种各样的可交付成果(这里定义为从集成的模型存储库生成的报告)的能力:规范、系统体系结构模型、接口需求和替代分析。我们的愿景是将这些基于开放文本的模型转化为可执行模型——这里使用的是SysML。

根据INCOSE的说法，基于模型的系统工程(MBSE)是“一种形式化的建模应用，用于支持从概念设计阶段开始并贯穿整个开发和随后的生命周期阶段的系统需求、设计、分析、验证和验证活动”。“基于模型意味着模型存储库中架构/工程元素的独特表示;模型的任何元素只有一个定义，尽管基于这些元素可以有任意数量的表示;并且模型被集成，这样元素之间的关系本身就是模型元素。同样地，对于MBSE和基于模型的EA，其目的是促进传统的SE和EA活动，从而增强通信、规范和设计精度、系统设计集成和系统工件的重用。因此，MBSE和基于模型的EA的输出都是定义的元素和关系的系统模型。

SE和EA模型的好处是能够捕获、分析、共享和管理信息;改善利益相关者之间的沟通(利益相关者管理);通过一个明确和精确的系统模型，提高管理复杂性的能力，该模型可以评估其正确性和完整性;以及增强知识获取、重用和变更管理。

根据INCOSE和OMG，“OMG Systems Modeling Language (OMG SysML)是一种通用的图形化建模语言，用于指定、分析、设计和验证可能包括硬件、软件、信息、人员、过程和设施的复杂系统。OMG为软件模型、系统模型和DoDAF模型提供了SysML建模。他们主张SysML加上DoDAF = UPDM (DoDAF和MoDAF的统一配置文件)。

对于SE社区，UPDM被描述为使用UML和SysML表示DoDAF工件的一种方式。国防部已经授权了该标准，现在已经由许多工具供应商实现，包括Atego、IBM、No Magic和Sparx。这使得架构师能够以一致的方式在较高的抽象级别上开发架构。

UPDM的目的是提供一种简洁的语言来捕获涉众的关注点，并表达处理这些关注点的高级架构。它是一种标准化，减少了通信中的歧义(包括外部涉众)，并支持优化体系结构以支持设计。

UPDM并不是一个新的体系结构框架，正如ISO/IEC/IEEE 42010所定义的那样:“架构框架建立了在特定应用领域或利益相关者社区中创建、解释、分析和使用体系结构描述的实践。架构框架的例子:MODAF, TOGAF, Kruchten的4+1视图模型，RM-ODP。此外，UPDM不是一种方法或过程。相反，它是一种图形企业建模语言。

UPDM的未来是UAF或统一架构框架。新UAF的基本原理是解决UPDM支持的框架大量增加的问题，以及支持工业、联邦和军事使用的需求，支持附加框架(包括TOGAF)的能力，并允许使用非SysML工具和使用SysML的工具实现。

UAF的支持者提倡一种新的网格方法，如下图所示:

网格的使用之所以得到推广，是因为在管理视图时遇到了许多相互竞争的框架，这导致了复杂的映射表和笨拙的描述。

现在回到讨论开始时提出的关于SE和EA的问题，EA是包含在SE中，与SE冗余，还是彼此平行?在一系列的论文和演讲中，MITRE和其他人将框架产品或工件相互映射。

一个这样的映射显示了DoDAF模型与TOGAF内容元模型的关系:

虽然SE和EA共享许多相同的建模特征，并处理共同的涉众集，但是我们需要考虑每个人如何拥有不同的视角和目标。我们认为EA与转型项目的启动是相关的，而转换项目又被移交给系统架构师，而系统架构师又为SE实现人员提供这些模型和描述。因此，这些学科之间有协同作用。在EA中，重点是业务以及信息技术(通过数据、应用程序和技术体系结构领域)如何支持业务。通过这种方式，EA为业务转型提供了路线图，并为系统工程师创建和实现系统提供了指导。

 

原文：https://www.eaprincipals.com/content/enterprise-architecture-and-systems-engineering-component-or-relationship-disciplines

本文：http://jiagoushi.pro/node/1285

讨论：请加入知识星球【首席架构师智库】或者小号【jiagoushi_pro】或者QQ群【11107777】

 

企业架构被认为是通过信息技术获取竞争优势的关键途径之一。降低成本、增加灵活性和规范技术环境的需求越来越大。

企业架构在概念上可以划分为不同的架构层，包括业务架构和IT架构(数据、应用程序和技术架构)。

然后，解决方案体系结构接受一个问题，并提出构建块来解决它。它经常重用企业架构提供的其他元素(企业构建块、企业功能、架构标准和指导方针)

因此，企业架构师在企业架构团队和组织的其他地方有许多不同的角色和职责。但是，人们可能会混淆这些角色和职责，例如，企业架构师有时会与解决方案架构师混淆，或者技术架构师与基础设施架构师的角色混淆。这不仅是因为他们的职位听起来相似，而且他们的职责也有部分重叠。然而，每个角色对于一个项目的成功都是至关重要的，不能被其他职位取代。让我们在本文中更精确地看看它们的区别。

四个架构域

企业架构指导组织的业务、信息、流程和技术决策，以使其能够执行其业务策略并满足客户需求。通常有四个架构领域，它们通常是相互关联的:

• 业务架构描述了企业在组织上是如何构建的，以及交付业务远景所需的功能。业务架构解决了什么和谁的问题:
  • 指导业务服务或功能创建的组织的业务远景、战略和目标是什么?
  • 谁在执行定义的业务服务或功能?
• 应用程序架构描述单个应用程序、它们的交互以及它们与组织的核心业务流程的关系。应用程序架构解决了如何:
  • 之前定义的业务服务或功能是如何实现的?
• 数据架构描述了一个组织的逻辑和物理数据资产和数据管理资源的结构。通过数据分析了解您的客户，使您能够改进和持续改进业务流程。
• 技术体系结构描述实现业务、数据和应用程序服务所需的软件和硬件。

企业架构师

企业架构师负责通过与关键人员协作来定义业务目标并创建支持这些目标的企业基础设施，从而确保公司的业务战略。企业架构师的职责包括协助创建和执行信息技术架构路线图，与领域架构师一起设计所有领域的路线图，并确定操作缺口和开发改进方法。

企业架构师的角色和职责包括:

• 分析技术架构领域的当前趋势并提供建议
• 评估应用程序是否符合企业标准和业务标准
• 确定与组织变更相关的架构的生存能力
• 就治理模型和框架等领域的最佳实践对技术人员进行培训

解决方案架构师

解决方案架构师专门评估业务需求，并将它们转换为解决方案、产品或服务。各种行业都需要解决方案架构师，包括专业服务公司或技术咨询机构。解决方案架构师通常花费大部分时间来协调正在进行的活动，参与活动的所有方面和活动，从概念定义到需求的分析和实现，最后转移到IT操作。

解决方案架构师的角色和职责包括:

• 在设计和构建阶段管理应用程序开发团队
• 为初级员工提供培训和指导
• 与应用程序开发人员协作以实现业务目标
• 在技术环境中监督战略关系

领域架构师

领域架构师是在其专业领域具有深入知识的专家。他们可以是企业架构团队的一部分，或者在各种交付项目中工作。词域是用来与一个小范围的知识领域所需的技能集相关的。

• 业务架构师
• 应用程序架构师
• 信息架构师
• 技术架构师
• 数据架构师
• 安全架构师

企业架构师vs解决方案架构师vs领域架构师

• 企业架构师定义需要解决的问题。
• 解决方案架构师将问题转化为解决方案。
• 领域架构师负责一个解决方案(例如，业务架构师与企业架构师一起负责业务架构，同样，应用架构师负责应用架构师与另一个领域架构师一起工作)

 

本文：http://jiagoushi.pro/node/1217

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

访谈是工作赢或输的地方。简历 - 尤其是强大的简历 - 将确保您踏上门，但要确保在面试中确保您需要发光的位置，这意味着要做好准备。准备让你看起来知识渊博，轻松，这是人们通常在工作同事中所珍视的两个特征。

 

为了在面试过程中为您提供额外的优势，在BiZZdesign，我们准备了100个问题，帮助您完成企业架构师角色访谈。其中一些针对初级企业架构师，另一些针对更有经验的专业人士 - 他们将共同为您提供一个非常好的想法。不用多说，以下是企业架构工作面试的100个问题：

1. 从大局的角度来看你是多么容易想到它，你能举例说明你在工作中汲取这种品质吗？
2. 为什么你认为自己适合我们公司？
3. 你如何改善你的专业网络？
4. 您之前是否处理过具有孤立结构的组织，以及您是如何处理它的？
5. 你参与过的最成功的倡议是什么？你如何描述你对它的贡献？
6. 您如何平衡与不同利益相关方群体的关系，特别是那些挑战您的想法的群体？
7. 您如何评估自己的领导能力？
8. 架构在敏捷环境中的作用是什么？
9. 您是否有使用安全架构框架的经验，如果有，哪些？
10. 在职业明智的十年后，你认为自己在哪里？
11. 您对数据管理标准和实践有经验吗？
12. 您是否有与供应商协商服务水平协议的经验？
13. 您是否曾经未能成功交付项目，如果是这样，您从经验中学到了什么？
14. 您认为企业架构在哪个领域？
15. 建立EA实践的成功第一年对您来说是什么样的？
16. 你在建筑师中寻找什么品质？
17. 您能否提供企业架构的简要定义？
18. 根据您的经验，哪些利益相关方团体将参与企业架构生命周期？
19. 简单来说，什么是架构模式？
20. 您如何发展在易变环境中运行的公司的企业架构？
21. 您能否列举一些最近的技术发展，您认为这些发展对EA专业人士来说很重要？
22. 您对EA在战略决策中的作用有何看法？
23. 您是否有任何与整个组织的团队合作的例子？
24. 您与高级业务利益相关者打交道的经验是什么？
25. 您如何从管理层获得支持？
26. 企业架构如何支持业务目标和战略？
27. 您能简要介绍一下成熟的企业架构实践吗？
28. 您是否有在敏捷环境中工作的经验？
29. 您如何描述寻找关键增值业务活动的方法？
30. 您是否有构建建筑路线图的经验？
31. 您参与过的最困难的项目是什么？您是如何应对挑战的？
32. 您评估EA实践的成熟度有多舒适？
33. 您如何确保解决方案与架构保持一致？
34. 你职业生涯中到目前为止使用了哪些工具？
35. 您是否有建立架构治理功能的经验？
36. 当你为解决问题的方法感到自豪时，你能想到一种情况吗？
37. 您如何确保遵守业务利益相关方的要求？
38. 您将使用哪些指标来证明EA实践对业务产生积极影响？
39. 您能举例说明您向高层管理人员传播架构和策略吗？
40. 您为此做出了哪些业务目标以及如何实现这一目标？
41. 您是否通过最新版ArchiMate标准认证？
42. 您喜欢参与定义业务战略吗？
43. 你如何强调同事工作中的弱点或错误？
44. 架构如何为DevOps做出贡献？
45. 您之前是否进行过风险影响分析？
46. 当一位同事纠正你时你如何回应，初级建筑师是否能够纠正高级职员？
47. 您如何鼓励跨部门合作？
48. 你能简单介绍一下TOGAF吗？
49. 您对敏捷方法和框架的体验是什么？
50. 企业架构实践在不同的组织文化中有何不同？
51. 您能举例说明如何成功实施最小化业务成本的解决方案吗？
52. 你能简单地定义ITSM吗？
53. 您如何定位业务架构相对于企业架构？
54. 您是否有为EA部门引入新标准的经验？
55. 您是否曾使用架构引导组织摆脱危机？
56. 您能简要定义应用程序组合管理吗？
57. 您目前最感兴趣的技术趋势是什么？
58. 您如何保持技能并与IT趋势保持同步？
59. 您是否有使用建模工具的经验？
60. 您能描述一下如何利用以前职位的工作流程来增加工作量吗？
61. 在交付项目时，您在EA部门之外与哪些利益相关方群体进行了互动？
62. 您最有经验的EA框架是什么？
63. 您是否有使用ArchiMate认证工具的经验？
64. 您是否获得最新版TOGAF认证？
65. 你能描述一下你曾经参与过的最成熟的EA实践吗？
66. 架构师可以做些什么来最大化他们在敏捷环境中带来的价值？
67. 您将如何提升组织的EA成熟度？
68. 什么“及时，足够”的架构意味着什么？
69. 您对微服务有何看法？
70. 您是否有应用程序云迁移的经验？
71. 您是否曾在之前的职位中有过基于能力的计划经验？
72. 什么是ArchiMate？
73. 您是否可以提供一些示例，说明您之前如何帮助识别安全威胁，然后提供控制措施来缓解这些威胁？
74. 您是否具有面向服务的体系结构的经验？
75. 在评估EA成熟度时，您会考虑哪些方面？
76. 您使用ArchiMate有什么经验？
77. 你能说出一些个人身份信息的例子吗？
78. 您有使用ITIL的经验吗？
79. 你能简单地定义业务架构吗？
80. 您是否曾经通过架构改善组织的客户体验？
81. 你能简单地定义安全架构吗？
82. 你有指导初级建筑师的经验吗？
83. 你知道GDPR是什么吗？
84. 你能解释面向对象和面向方面设计之间的区别吗？
85. 您参与的最全面的技术架构升级计划是什么？您是如何为其成功做出贡献的？
86. 您能描述一下您的客户旅程映射体验吗？
87. 您是否亲眼目睹了安全漏洞，如果是这样，您的经验教会了什么？
88. 关于企业架构师如何完成工作，您会改变哪些方面？
89. 你认为有一个“最重要的”建筑层吗？
90. 您能否分享一个成功的APM实践的例子，您可以参与并描述您在成功中的角色？
91. 参考架构的作用是什么？
92. 出于什么目的，您将分别使用ArchiMate，BPMN或UML建模语言，以及如何将它们联系起来？
93. 在您看来，什么是项目成功的最重要预测因素？
94. 您是否能够在软件开发生命周期中简要描述解决方案架构师的角色？
95. 你工作的最佳方面是什么？
96. 您是否参与过物联网项目的实施？
97. 您是否曾经运行情景分析来指导投资决策？
98. 您是否有实施GDPR合规计划的经验？
99. 您认为TOGAF中的哪些架构观点在低成熟度实践中特别相关？
100. 您是否可以提供一个示例，说明在项目目标意外更改后您是如何成功调整的？

我们认为，提前回答这些问题将使您在面对企业架构师角色的真实面试中毫无压力地工作，并增加您成功的机会。要了解有关当今数字化转型的更多信息以及组织变得适应性的重要性，请随时下载我们的电子书，自适应企业：在变革时代蓬勃发展。

原文:https://bizzdesign.com/blog/100-questions-to-ace-an-enterprise-architect-job-interview/

本文:http://pub.intelligentx.net/enterprise-architecture-100-questions-ace-enterprise-architect-job-interview

讨论:加入知识星球或者小红圈【首席架构师圈】

从这里开始使用试用帐户创建动画企业架构框架图。 快来看看Dragon1循序渐进指南吧。

这是在Dragon1上创建的企业架构框架图的示例。 Dragon1是一个协作平台，您作为Business Professional可以在其上学习，创建，共享和控制交互式内容。

什么是企业架构框架图？

企业架构框架图是架构的分类方案（治理架构，业务架构，信息架构，技术架构，人力资本架构，安全架构，系统架构，软件架构，基础架构架构等）及其重要工件。 企业架构框架可用作背景来报告一种或多种类型的工件，例如构成架构的概念。

为什么这个企业架构框架示例？

此示例企业架构框架图是为您创建的，以显示在Dragon1上创建企业架构框架的效率。

在此页面上，您可以阅读并了解Dragon1在建模和可视化交互式企业架构框架方面的强大功能。

此示例还说明了Enterprise Architect如何能够并且应该如何向利益相关者报告正在进行的EA兼容企业体系结构定义的工作状态。

从Architecture Diagram到Management Report视图

上图显示了企业体系结构框架图的管理报告视图。这不是一个沉闷的无意义的建筑模型图片，而是一个支持报告框架的决定：红色意味着：现在采取行动，因为目前的情况阻碍了目标的实现！

下面的第二张图显示了企业架构框架的概念视图。它给出了一个问题的答案：我们的框架中的架构最重要的概念是什么。

Dragon1，节省了大量宝贵时间！

现在，您立即了解为什么您作为Enterprise Architect需要EA工具。上面的企业架构框架有很多可能的视图，当管理员要求新情况，方面或时间段的新视图时，您不希望手动创建和更新每个报表视图。

不，您只是希望经理提供可点击的企业架构框架，并让他自己根据存储库中的信息生成视图，方法是设置一些时间段等参数。

阅读有关如何创建企业架构框架的更多信息。

交互图示例

例如，您可以通过单击图层或过滤掉某些信息来构建自己的企业体系结构框架视图。单击此Watch页面上的企业体系结构框架的此交互式示例。这可能会让您了解框架图应该如何以及您希望如何使用它。

还读

您可能还对Enterprise Architecture Framework上的以下资源感兴趣：

• Terms > Architecture Diagram Definition
• Terms > Enterprise Architecture Framework Definition
• Visualizations > Ideal Enterprise Architecture Framework
• Blogs > Enterprise Architecture Framework Diagram - A First Aid Kit for Projects
• Frameworks > Zachman Framework
• Wikipedia > Enterprise Architecture Framework
• Terms > Architecture Principle Definition
• Training > Dragon1 Foundation

入门

我们希望我们能够激励您创建企业架构框架。

你想立刻开始吗？您可以通过Paypal在线购买Dragon1 PRO用户许可证。

如果您没有时间并且需要在短时间内获得企业架构框架图，我们可以为您创建框架。

 

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

在今天的第三部分中，我将更广泛地了解与企业架构相关的组织、框架和模型。具体来说，我们考虑了云领域，并得出结论认为，当今 EA 最佳实践的重要部分是由云组织和提供商开发的。

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

谁仍然对企业架构感兴趣？

– 第 3 部分，共 6 部分

有两种不同类型的组织与企业架构相关。

- 一些组织，例如 The Open Group 和 Bizzdesign 完全专注于该主题。

- 此外，还有一些新的市场参与者也在开发企业架构框架，但并不完全专注于这个主题。

云原生计算基金会（CNCF）是一个重要的参与者

第二类的一个例子是云原生计算基金会（CNCF）。它的创始公司包括 Google、Docker、Red Hat、Twitter 和 IBM。它的目标是成为许多增长最快的开源项目的供应商中立之家，促进开发人员、最终用户和供应商之间的协作。因此，他们的主要目标是为开源项目提供一个进一步合作和发展的平台。然而，作为其中的一部分，他们还不断开发合适的生态系统。

如今，CNCF 还提供工具和技术的培训和认证，以帮助轻松有效地管理云原生应用程序（例如微服务）的整个环境（例如，服务网格、Kubernetes）。虽然毫无疑问，此类解决方案是其产品组合的合适扩展，但它们位于企业架构的核心。

AWS、Azure 和 GCP 等超大规模企业也在开发最佳实践

与 CNCF 一样，大型云提供商开发的最佳实践正在成为如何管理云架构的行业标准。例如，AWS 在 2018 年首次提供了 AWS 架构完善的框架，其中包括五个支柱以及一组用于设计和构建云环境的设计原则。 2020 年底，MS Azure 还发布了他们的架构完善的框架版本。这两个框架都建立在相同的五个支柱之上。这使得它们很可能成为整个行业的标准。尽管这些支柱主要关注 IT 架构，但它们也会影响企业架构活动。

除了 Well-Architected Framework，前面提到的云提供商还提供了大量的参考架构。与无边界信息流或来自 TOGAF 标准的集成信息基础设施参考模型相比，它们相似，但更现代。

最后，MS Azure 云采用框架或类似模型很可能会取代 TOGAF 的架构开发方法。随着云变得越来越重要，并且两个框架都遵循类似的概念，我相信这种发展将继续下去。

您对云组织和提供商在企业架构最佳实践开发中的作用有何看法？你同意还是不同意我的推理？我期待您在下面的评论部分中发表评论！

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

本文：https://jiagoushi.pro/new-sources-enterprise-architecture-frameworks-em…

企业架构(EA)是“一种定义良好的实践，用于执行企业分析、设计、规划和实现，在任何时候都使用一种全面的方法，以实现战略的成功开发和执行。企业架构应用架构原则和实践来指导组织完成执行其战略所必需的业务、信息、流程和技术更改。这些实践利用企业的各个方面来识别、激励和实现这些变化

企业架构师负责执行业务结构和流程的分析，经常需要从收集的信息中得出结论，以实现企业架构的目标:复杂业务操作的有效性、效率、敏捷性和连续性。

概述

美国法典44第3601节企业架构的定义:(4)“企业架构”- (A)指- (i)定义任务的战略信息资产基础;执行任务所需的资料;执行任务所需的技术;执行新技术以应付不断变化的特派团需要的过渡过程;(B)包括:(i)基线架构;(2)目标架构;(iii)测序计划;

EA不仅仅是关于IT的。它是关于充分详细地理解任务，以便您能够及时地在整个企业范围内做出知情的购买决策。

布鲁贝克说:“国会、行政管理和行政管理办公室以及IT界都被克林格-科恩法案的潜在阴谋分散了注意力——这从来不是关于技术，而是关于如何通过深思熟虑的技术应用来转变任务和支持过程。”“各机构将展示他们是如何深思熟虑地应用技术的，通过提供清晰而令人信服的商业案例来投资于技术，然后对在任务和业务绩效方面产生可衡量的改进负责。”遗憾的是，行政管理和预算办公室(OMB)、政府总务管理局(GSA)、各机构和首席信息官(cio)都无法抵抗诱惑，过度规定合规要求，并推动那些过于关注技术和基础设施的任务，而这些工作完全没有抓住重点。“保罗布鲁巴克

https://federalnewsnetwork.com/reporters-notebook-jason-miller/2019/02/…

企业架构知识体系将企业架构定义为一种实践

分析组织内部或组织之间共同活动的领域，在这些领域信息和其他资源被交换，以从战略、业务和技术的综合观点来指导未来状态

IT分析公司Gartner将这个术语定义为一种引导企业经历变化的规程。根据他们的术语表，

企业架构(EA)是通过识别和分析朝着期望的业务远景和结果的变更执行，主动地和全面地领导企业对破坏性力量的响应的规程。EA通过向业务和IT领导提供已签名的建议来实现价值，这些建议用于调整策略和项目，以实现利用相关业务中断的目标业务结果。EA是用来引导未来状态架构发展的决策制定

上面的每一个定义都低估了企业架构产生于记录和规划信息系统架构的方法的历史现实，以及大多数企业架构从业者向CIO或其他IT部门经理报告的当前现实。在当今的业务组织结构中，企业架构团队执行正在进行的业务功能，帮助业务和IT经理找出支持和实现业务开发和业务变更的最佳策略——与业务所依赖的业务信息系统相关。

主题

术语企业和架构

企业这个术语可以定义为描述一个组织单元、组织或组织集合，这些组织共享一组共同的目标，并协作为客户提供特定的产品或服务

从这个意义上说，企业这个术语涵盖了各种类型的组织，而不管它们的规模、所有权模型、运营模型或地理分布如何。它包括那些组织的完整的社会技术系统，[5]包括人员、信息、流程和技术。

术语架构指的是系统在其环境中的基本概念或特性，体现在系统的元素、关系以及设计和发展的原则中

企业被理解为社会技术系统，术语企业定义了企业架构的范围。

作用域

企业架构从业者和学者持有的关于企业架构意义的观点或信念，通常倾向于三种思想流派的一种或混合:[7]

1. 企业IT设计——EA的目的是使IT和业务关注点更一致。企业架构的主要目的是指导计划和设计企业的IT/ is能力的过程，以满足预期的组织目标。通常，架构建议和决策仅限于企业的IT/IS方面;其他方面仅作为输入。
2. 企业整合——根据这一学派的思想，EA的目的是在企业的各种关注点(人力资源、IT、运营等)之间实现更大的一致性，包括战略制定和执行之间的联系。通常，架构建议和决策包含企业的所有方面。
3. 企业生态系统适应——EA的目的是培养和维护企业的学习能力，从而使企业能够持续发展。因此，提高企业自身的自我完善能力、创新能力和与环境协同发展的能力成为企业研究的重点。通常，建议和决策包括企业及其环境。

一个人对企业架构意义的信念将影响他如何看待它的目的、它的范围、实现它的方法、执行它所需的技能，以及执行它的责任所在[7]

企业的架构描述

参见:架构领域

根据标准ISO/IEC/IEEE 42010，用于描述系统架构的产品称为架构描述。在实践中，架构描述包含各种列表、表格和图表。这些模型称为视图。对于企业架构，这些模型描述了逻辑业务功能或能力、业务流程、人工角色和参与者、物理组织结构、数据流和数据存储、业务应用程序和平台应用程序、硬件和通信基础设施。[引文需要]

英国国家计算中心EA最佳实践指导[8]声明:

通常EA采用一组全面的内聚模型的形式，描述企业的结构和功能。EA中的各个模型以逻辑的方式进行安排，从而提供了关于企业的越来越多的细节。

描述企业的架构是为了提高业务的可管理性、有效性、效率或敏捷性，并确保在信息技术(IT)上的花费是合理的。[引文需要]

对于更改企业架构，最重要的是确定赞助者。他/她的使命、愿景和策略，以及治理框架定义了预期转换中涉及的所有角色、职责和关系。企业架构师考虑的变化通常包括:

• 组织结构或过程的革新
• 在使用信息系统或技术方面的创新
• 业务流程的集成和/或标准化
• 提高业务信息的质量和及时性。

用于开发和使用架构来指导业务从基线状态到目标状态的转换(有时通过多个转换状态)的方法通常称为企业架构框架。框架提供了流程、技术、工件描述、参考模型的结构化集合，以及针对特定企业架构描述的生产和使用的指导。

好处

企业架构的好处是通过它对组织目标的直接和间接贡献来实现的。人们发现，企业架构最显著的好处可以在以下方面观察到:[9]

1. 组织设计——企业架构在合并、收购或一般组织变革期间，为组织结构的设计和重新设计提供支持
2. 组织过程和过程标准——企业架构帮助加强业务过程的规程和标准化，并支持过程整合、重用和集成
3. 项目组合管理——企业架构支持投资决策和工作优先级划分
4. 项目管理——企业架构增强了项目干系人之间的协作和沟通。企业架构有助于有效地确定项目范围，并定义更完整和一致的项目可交付成果
5. 需求工程——企业架构通过发布企业架构文档，提高了需求捕获的速度和需求定义的准确性
6. 系统开发——在系统开发和测试期间，企业架构有助于优化系统设计和有效的资源分配
7. 资讯科技管理及决策制定-企业架构有助推行资讯科技规划活动的纪律及标准化，并有助缩短作出与科技有关的决策的时间
8. IT价值——企业架构有助于降低系统的实现和运营成本，并最大限度地减少跨业务单位的IT基础设施服务复制
9. IT复杂性——企业架构有助于降低IT复杂性，整合数据和应用程序，并改善系统的互操作性
10. IT开放性——企业架构通过增加对法规遵从性的数据可访问性和增加基础设施变更的透明度来促进IT的更加开放和响应性
11. IT风险管理——企业架构有助于减少系统故障和安全破坏带来的业务风险。企业架构有助于降低项目交付的风险

例子

企业架构的文档记录是在美国联邦政府[20]的资本计划和投资控制(CPIC)过程中完成的。

联邦企业架构(FEA)参考模型指导联邦机构开发它们的架构

公司如独立蓝十字、英特尔、大众[22]和洲际酒店集团使用企业架构来改善他们的业务架构，并提高业务绩效和生产力。

由于各种可以理解的原因，商业组织很少发布实质性的企业架构描述。然而，政府机构已经开始发布他们开发的架构描述。例子包括:

1. 美国内政部（US Department of the Interior）
2. 美国国防部（US Department of Defense）企业架构，[23]或2008 BEAv5.0版本
3. 财政部企业架构框架（Treasury Enterprise Architecture Framework）

与其他学科的关系

根据EA专业组织联合会(FEAPO)的说法，企业架构与广泛的业务设置中常见的其他学科相互作用。根据FEAPO:

企业架构实践与许多相互联系的学科,包括性能工程和管理、过程工程和管理、IT和企业项目组合管理,治理和合规、战略规划、风险分析、信息管理、元数据管理、和各种技术规程以及组织学科如组织发展、转型、创新和学习。越来越多的从业者强调企业架构与新兴的整体设计实践(如设计思维、系统思维和用户体验设计)之间的重要关系

随着企业架构在各种组织中出现，其广泛的影响已经导致该业务角色被包括在许多组织的信息技术治理过程中。虽然这可能意味着企业架构与IT紧密相连，但应该在更广泛的业务优化上下文中来看待它，因为它处理业务架构、性能管理和流程架构，以及更多的技术主题。

各种IT分析公司已经发表了关于企业架构和各种IT实践交叉的讨论。Gartner和Forrester强调了企业架构与新兴的整体设计实践(如设计思维和用户体验设计)之间的重要关系。[26]分析公司Real Story Group认为，企业架构和新兴的数字工作场所概念是“一枚硬币的两面”。Cutter Consortium将企业架构描述为一种信息和基于知识的规程

组织的企业架构过于复杂和广泛，无法完整地记录下来，因此知识管理技术提供了一种方法来探索和分析这些隐藏的、默认的或隐式的领域。反过来，企业架构提供了一种记录组织组件及其交互的方法，以一种补充知识管理的系统和整体的方式

在各种场合，[30]企业架构都被讨论为与面向服务架构(一种特定的应用集成风格)的关系。研究指出，企业架构促进了SOA作为企业范围集成模式的使用

工具

下表列出了Gartner和Forrester Research在2013、2014、2017和2018年报告中列出的一些著名的企业架构工具。[33][34] b[36] [37]

Product	Vendor	Headquarters
ABACUS	Avolution	Australia
Alfabet	Software AG (formerly alfabet)	Germany
Ardoq	Ardoq	Norway
ARIS	Software AG (formerly IDS Scheer)	Germany
BiZZdesign Enterprise Studio	BiZZdesign	Netherlands
Enterprise Architect	Sparx Systems	Australia
HOPEX	MEGA International Srl.	France
leanIX	LeanIX	Germany
Planview Enterprise One - Capability & Technology Management	Planview (formerly Troux)	United States
ProVision	OpenText (formerly Metastorm)	Canada
QPR EnterpriseArchitect	QPR Software	Finland
SAP PowerDesigner	SAP-Sybase	Germany
System Architect	Unicomm (formerly IBM (formerly Telelogic))	United States
Product	Vendor	Headquarters

批评

尽管企业架构声称提供了许多好处，但在十多年的时间里，作者和组织一直在关注企业架构作为一种有效的实践。以下是部分反对意见:

• 2007年,计算机科学家Ivar Jacobson(一个主要贡献者UML和面向对象软件开发的先锋)给他的评估企业架构:“世界各地引入企业架构EA一直是主动对大多数金融机构(银行、保险公司、政府等)在过去五年左右,并没有结束。我一直在与这些公司合作，帮助他们避免犯最严重的错误。大多数EA计划都失败了。我猜超过90%的人从来没有真正得到任何有用的东西。
• 在2007年的一份关于企业架构的报告中，Gartner预测“……到2012年，40%(2007年的)企业架构项目将被停止
• 鹿特丹伊拉斯谟大学和软件公司IDS Scheer在2008年进行的一项研究得出结论，三分之二的企业架构项目未能改善业务和IT的一致性
• 在2009年的一篇文章中，行业评论员Dion Hinchcliffe写道，传统的企业架构可能会被“打破”:“在最好的情况下，企业架构提供了清晰的线条，清晰地阐明了业务的所有可能性，甚至描述了如何实现它……最近，越来越多的人认识到，如今经常实践的传统企业架构可能在某些重要方面被打破。现在的问题是问题出在哪里以及如何解决
• 2011年，联邦企业架构顾问Stanley Gaver发布了一份报告，调查了美国联邦政府企业架构项目中的问题。加弗的结论是，联邦企业架构项目基本上失败了;这个结论被联邦政府在2010年10月的一次会议上做出的一个类似的结论所证实，那次会议是为了确定联邦企业架构项目为什么没有“过去那么有影响力和成功”

由于EA项目的粗线条和经常不透明的本质，一个关于EA的关键关注一直是很难达到成功的度量标准

另请参阅

• 企业架构的构件
• 企业架构框架
• 建筑模式(计算机科学)
• 综合信息系统的架构
• 互操作信息系统的架构
• John Zachman，企业架构的倡导者
• 企业架构服务生命周期- SOMF

 

原文：https://en.wikipedia.org/wiki/Enterprise_architecture

本文：http://jiagoushi.pro/node/1097

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】

企业架构通常被认为是一种抽象的，概念性的，有些深奥的学科，由“大祭司”实践，他们为他们崇高的“建筑原则”提供指导。架构师经常关注的是总体而言，跨领域的问题并不总是如此。在战壕中人们可以看到，但这种企业架构的观点充其量是错误的，并且越来越错过了这个标志。

自上而下和自下而上变化之间的一致性

企业架构的任务是根据公司战略，企业生态系统以及各利益相关方团体的需求和愿望，一致地设计和改进企业运营方式。这应该是组织中每个人都关心的事情，每个人都在自己的范围内，从他们自己的角度来看。 Mintzberg和Waters1在20世纪80年代已经将故意（自上而下）和紧急（自下而上）战略区分开来，Ciborra2认为当地的“修补”可能会带来战略优势，竞争对手难以复制。

在采用敏捷，DevOps和精益方法的现代组织中，创新和改进同样是自下而上的事情。但是，要想在当今不稳定的商业环境中取得成功，您需要一种协调和协调这些自上而下和自下而上的变化的方法。这是企业架构可以提供帮助的地方。在之前关于Agile / DevOps与EA之间关系的博客中，我的同事Fabian和我解决了其中的一些问题，概述了企业架构如何为Agile和DevOps的工作方式增加价值。对此关系的考虑有助于您分析各种事件和变更的影响，根据业务价值确定变更的优先级，协调不同学科的工作，并为创新提供背景。

让每个人都成为架构师

从长远来看，我们看到架构角色发生了更为深刻的转变：将企业架构定位为高层次，自上而下的运营规则，而不是不同类型的变革之间的连接结构。在企业内部，这意味着每个人都将以某种方式在架构的开发和发展中发挥作用。从本质上讲，每个人都成为架构师！

当然，这并不意味着每个员工都应该参加TOGAF课程。相反，您应该为每个人提供工具，让他们了解当地或全球变化的选项和效果，并采取相应措施。所有这些变化都可以与共享的企业愿景保持一致，并协同工作，从本地流程改进的结果或敏捷用户故事的优先级到合并的影响或新监管要求对您业务的影响模型。

架构师：从'超级设计师'到变革的管家

这种重点转变的主要驱动力是企业对速度的需求。为了生存和竞争，组织需要适应不断变化的环境。这是一个战略性问题，越来越多地胜过传统成本或收入，特别是在我们经常在数字领域看到的“赢得所有”市场。以前，我们已经写过关于Adaptive Enterprise的愿景以及支持它的功能。任何大型企业都需要本地团队之外的协调机制进行本地更改：如果您只有一群敏捷团队构建敏捷孤岛，那么您最终可能会获得“即时遗留”，并且您的企业可能会变得更少 - 而不是更多 - 适应其环境。

下图来自BiZZdesign的EA成熟度模型，展示了我们如何看待这种演变，从脱节的非正式努力到专注于适应性和创新的协作。这既适用于学科本身的发展，也适用于个体企业的应用方式。

Maturity stages of Enterprise Architecture 

 

现在，这种转变并不意味着企业架构师将会消失。相反，他们的角色将从“超级设计师”转变为企业内部变革的管家。他们不会自己设想，而是越来越多地向参与变革的其他人提供帮助，并确保建筑作为组织的结缔组织的质量和企业范围的一致性。

EA的消费化

让每个人都参与企业架构需要对所使用的工具采用新方法。在不久的将来，架构师，流程设计师，软件开发人员，投资组合经理和其他“变革专家”使用他们的专用建模和分析工具，每个工具都在他们自己的领域。跨这些领域的合作，更不用说与“非专家”合作，这很困难。因此，我们需要通过组织内任何人都可以访问的协作工具来增强这一点，其中架构信息以易于消费的方式共享，并根据不同利益相关方群体的需求进行定制。这也意味着使用常规的消费者市场工具并在协作环境中集成这些工具 - 从而建立EA的消费化。

这种协作平台的功能包括：

1. 针对不同用户社区的各种视图和仪表板
2. 交互式分析工具，可以创建全面的概述和详细的深入分析
3. 团队支持，以组织团队内部和团队之间的工作
4. 社交功能让人们可以轻松地协同工作，相互学习，提供反馈并随时了解情况
5. 工作流支持，以实现必要的协作和治理流程
6. 与各种内部和外部信息源的数据集成
7. 一种可靠的访问控制机制，可确保信息安全而不会妨碍协作

好消息是，这不是科幻小说！

由于您正在阅读BiZZdesign博客，您将猜到这正是我们的协作平台提供的。 Enterprise Studio是专家使用的建模和分析环境。 HoriZZon是非专家用户的可视化和协作门户，两者都以Team Platform为基础，提供模型管理，工作流，安全性，数据集成等等。我们正在快速发展这一功能，以适应这种转向EA的消费化。在以后的博客中，我将更详细地介绍其中一些功能。

原文:https://bizzdesign.com/blog/the-consumerization-of-enterprise-architecture-everyones-an-architect/

本文:http://pub.intelligentx.net/enterprise-architecture-consumerization-enterprise-architecture-everyones-architect

讨论:请加入知识星球【首席架构师圈】

介绍

在当今的数字时代，大多数企业的运营都依赖于技术。这项技术有多种形式，但软件系统最为人所知。

众所周知，每家公司要么提供要销售的产品，要么提供服务。这些公司由其所有者、经理或企业最高管理层管理，但他们不一定是技术专家。

这些所有者不做出技术决定。这就是为什么他们需要帮助来构建和购买运行其业务的信息系统。这就是企业架构的用武之地。

在本文中，我们将讨论什么是企业架构师以及他们的工作。好，那我们开始吧。

什么是企业架构 (EA)？

企业一词代表任何使用软件系统的组织，并且不仅限于公司。它可以是政府机构、非营利组织、非政府组织和慈善机构。

企业架构 (EA) 是一种实践和一套技能，用于使技术战略与业务战略保持一致。此外，EA 处理企业/组织、其人员、其支持的业务流程以及自动化这些流程的系统之间的复杂关系。

这就是为什么在企业环境中，业务领导者依赖企业架构师作为值得信赖的技术顾问。

在我个人看来，企业需要 EA 不是因为 IT 项目的复杂性，而是因为它们弥合了业务利益相关者和开发人员之间的沟通鸿沟。

试想一下，由于开发人员和业务利益相关者之间缺乏沟通，项目状态可能并不理想。

这就是为什么您会看到 EA 充当解释器，将业务需求转换为解决方案设计，最后转换为企业系统。

因此，我们可以得出结论，企业架构师支持业务主管将他们的愿景转化为帮助公司成功的技术战略。

开发人员和架构师之间的区别？

一般来说，大多数架构师的职业生涯都是从软件开发人员开始的。

并不是每个人都同意软件开发人员是一个伟大的职业，特别是如果你不喜欢在软件空间内构建东西并通过将业务问题转换为代码来解决问题。

你想在未来成为一名建筑师吗？成为一名软件开发人员是一个很好的垫脚石。

现在，让我们关注开发人员和架构师之间的区别。

在我看来，开发人员专注于树木，而建筑师专注于森林。这些树代表开发人员关注的技术或相关技术，而森林代表 EA 关注的一系列连接系统。

另一个区别是软件开发人员，他们的第一直觉是编写代码来满足业务的请求。

这就是为什么如果公司没有架构师，业务用户会直接与开发人员交互。这就是为什么一切都被视为软件问题的原因。

虽然架构师善于提出驱动目的和意图的正确问题，但 EA 有助于继续专注于交付业务价值，避免中断。

例如，当业务用户要求新的系统或功能时，架构师会帮助他们表达他们在实际业务成果中真正需要的东西。

三种主要类型的架构范围

应用架构师

应用程序架构师最接近软件开发团队。这些人也被称为软件架构师。

这些人专注于由平台、可重用组件和软件组成的复杂 IT 系统。简单来说，我们可以说应用架构师主要关注与他们所专注的特定平台相关的工程问题和技术解决方案。

通常，大多数软件高级或软件工程主管通常会成为或被提升为团队的应用程序架构师。这就是为什么这个角色仍然可以编写代码。此外，我喜欢这些角色的原因是测试一些概念证明，最终将帮助项目在他们面临的当前问题上取得进展。

此外，当不编码、测试或设计新想法时，该角色会与开发团队进行沟通，以了解他们在设计实现方面的进展。这确保了应用程序的持续开发是根据软件架构师给出或建议的计划构建的。

解决方案架构师

解决方案架构师专注于将工作系统连接在一起以处理复杂的业务工作流程。你会看到他们负责弥合业务问题和技术解决方案之间的差距。因此，我们可以说它们处于应用程序和企业级关注点的中间。

这就是为什么我们有时可以将它们视为万事通，因为它们只关注个别应用程序，但在需要时扩展他们的知识和技能以解决更广泛的技术和战略问题。

解决方案架构师不需要编码技能，但其中一些人确实了解编码。这就是为什么他们可以与开发团队进行良好沟通的原因。

企业架构师

企业架构师战略性地运作，与高管合作以实现公司目标。此外，他们的主要目标是使技术与业务战略保持一致。

以下是我在 EA 领域看到的情况：

• 他们保持发展计划的整体愿景
• 协调大型项目的需求
• 通过业务和技术路线图指导敏捷团队。

试着想象一下你是组织中新加入的 EA。您首先要了解公司的使命。

从那里，您得出愿景并询问公司为什么要朝特定方向发展？一旦你回答了原因，你最终会坐下来，与领导层交谈，并确定如何在战略层面调整一切。

在组织内建立 EA 团队的好处

最终，公司在战略决策方面超越了咨询、承包或外包公司。这是公司可能决定创建内部 EA 团队或部门的时候。在一家外包公司工作时，我见过很多这样的案例。

好的，也许您会问：“在组织内拥有 EA 团队有什么意义？”。为了回答这个问题，它基本上从企业使命和产品开发之间的一致性开始。

在大多数情况下，拥有内部开发团队的组织通常专注于技术并面临许多手头的问题。随着时间的推移，它们可能与组织的真正业务价值脱节。这就是为什么拥有一个 EA 团队可以帮助组织专注于提供真正的业务价值。

另一个显着的好处是不断评估不断变化的需求，并且可用于支持其业务需求的技术也在不断变化。敏捷和敏捷架构等实践可以使开发适应变化。

最后，EA 收集、记录和管理的知识很有价值。这将帮助组织集中其知识存储并使其可供架构师、开发人员和业务利益相关者使用。

概括

在本文中，我们讨论了以下内容，

• 什么是企业架构 (EA)？
• 开发人员和架构师之间的区别
• 三种主要类型的架构范围
• 在组织内建立 EA 团队的好处

我希望你喜欢这篇文章，因为我喜欢写它。

请继续关注更多。直到下一次，快乐的编程！

请不要忘记收藏、点赞和评论。

干杯，谢谢！

原文：https://lock29down.medium.com/introduction-to-enterprise-architecture-e…

本文：https://jiagoushi.pro/introduction-enterprise-architecture-ea

我是一名建筑师。 我设计系统。 我专注于返回值。 我不断地学习。

在我设计系统时，我不断寻求了解如何使该系统变得更好，或者至少我可以发现哪些要点可以使下一个解决方案变得更好。 通常这些不是技术问题——技术是简单的部分——而是本质上更广泛的问题。 有时他们在本质上更个人化，比如努力成为更好的沟通者。 作为一个内向的人，我敏锐地意识到我的这个弱点。

An Archimate-based Metamodel is a metacognitive tool to visual a complex technology ecosystem.

这些更广泛的担忧是什么？那么如何改进技术交付平台以使其更好地满足业务需求。这些问题通常属于企业架构 (EA) 领域。什么是企业架构？这是一个有很多答案的问题。对我来说，它是跨业务和 IT 协调资源以确保 IT 资产的战略交付的纪律。

在我多年的咨询和创建系统中，企业架构是我看到几乎每个组织都重复出现的一个失败领域。为什么呢？出于多种原因。但主要是因为大多数组织中不存在企业架构的实践。当它被实践时，它被错误地实践或定义为企业级的解决方案架构。我看到的主要错误是：

• 业务不是企业架构的一个元素——EA 的一个主要部分是确保交付业务价值。大多数高管（来自业务或 IT 方面）都不愿意让 IT 进入业务领域。墙仍然存在，我相信将企业架构围在 IT 领域会阻碍 IT 将两者结合起来的能力。
• 感知到的需求就在当下——要做的事情太多了，EA 只是分散了在接下来的几周或几个月内交付软件的注意力。短期思维对于随着时间的推移提高性能或确保您交付业务实际需要的东西没有任何作用。交付的最低价值组件意味着没有交付价值更高的组件，从而降低了 IT 输出实现的价值。
• C 级套件的狂妄自大——世界各地的 CTO、CIO、CFO、COO 和 CEO 都有过成功的职业生涯。大多数人的外表和身高都高于平均水平。他们通过他们的能力和他们的能力达到了他们所在的位置。他们对自己的能力过于自信，因此不愿意支持可能挑战他们非结构化信念的结构化技术。 EA 利用元认知工具来构建分析并帮助为有效决策提供信息。
• 过度使用 EA — 最受欢迎的 EA 框架是 TOGAF。这是一个复杂而雄心勃勃的框架，有很多行话。 TOGAF 已经过时，源于瀑布思维。在敏捷的世界中，它适合哪里？好吧，有很多东西可以带走，也有很多东西可以留下。 EA 本身不应该是一个目标。努力应该集中在为组织带来价值上，尽可能地轻量化和自动化。

如何避免这些错误并有效执行 EA？它是通过使用数据和元认知工具来塑造您分析复杂系统的方式，并结合不懈地敲响为技术执行提供指导的原则。它还需要不懈地关注回报价值。

将来，我将撰写更多关于企业架构以及如何将其引入您的组织的文章。如果您有任何问题或意见，请告诉我。我喜欢反馈！

原文：https://www.naviger.com/enterprise-architecture-an-unknown-art-b16f4780…

本文：https://jiagoushi.pro/enterprise-architecture-unknown-art

它需要高级领导的支持和正确的企业架构工具来创建企业架构(EA)程序，从而成为增长、创新和业务战略的强大驱动力。房利美是抵押贷款机构的主要融资来源，它已帮助5000多万中低收入家庭实现了住房所有权。该公司的电子艺界项目已经取得了巨大的成功，这表明如果处理得当，电子艺界可以帮助公司克服一些最大的挑战。

使企业架构具有可操作性是大多数组织努力追求的目标，但是由于缺乏对项目的支持、协作、采用和清晰的目标，这一目标常常难以实现。同样重要的是，房利美的企业架构已经摆脱了其作为治理功能的形象，成为提高敏捷性、协作、透明度和加速数字转型的催化剂。

业务操作的变化比以往任何时候都要快，正因为如此，EA程序(以及支持它们的工具)必须促进敏捷性和变革性的计划，例如改进客户体验。

从企业架构治理开始

房利美(Fannie Mae)的企业架构计划最初是一项治理功能，如今已发展为在确定公司数字战略直至执行过程中提供可衡量的价值。房利美的成功之路可以教会我们所有人企业架构的最佳实践，以及如何开发一个为组织带来最大价值的EA程序。

房利美(Fannie Mae)的企业架构计划与许多公司一样，以治理为重点。该公司使用企业架构来执行策略、标准和过程，以确保遵从性，并减少风险。

将企业架构连接到业务

在兆丰企业架构解决方案的支持下，房利美通过促进协作和加强沟通的战略，将其企业架构计划从以治理为重点发展为以使能者为重点。房利美邀请了不同的商业用户组访问该软件并获取他们的数据。随着越来越多的信息开始进入存储库，它变得更丰富、更准确、更有价值。

今天，该公司的存储库是健壮的，数据准确，组织良好，支持自助服务，从而节省了时间和资源。MEGA的HOPEX软件促进了数据平台之间接口的建立，使得数据能够被拼接在一起，从而更容易准确地查看公司的it平台、流程和业务操作。大量准确的数据和对公司流程的不断增加的可见性使房利美有能力建立新的仪表盘和报告来推动可操作的工作。

利用企业架构做出战略决策

房利美通往企业架构成功之路的全部内容都是关于集成、协作、增加可见性，以及培养包容和支持的文化。房利美通过向决策者提供关键信息和指标，使他们能够看到所收集数据的价值，从而消除了EA的神秘感。通过提供可见性和信息来做出正确的决策，这些数据可以作为战略计划的良好起点。

加快创新和数字化转型的企业架构

投资组合架构师在房利美(Fannie Mae)颇具影响力，是所有与他们在各种项目上合作的人值得信赖的合作伙伴。实现了工具和过程，以便更好、更有效地使用技术。由于这些新工具及其自动化能力，房利美已经看到了数字文档的标准化和增长。

房利美继续使用EA促进创新和数字转型，并将兆丰的HOPEX软件视为未来业务现代化计划和客户体验改进的推动者。这需要时间和决心，但房利美成功地开发了一个EA项目，为公司提供了巨大的价值和洞察力。

 

原文：https://community.mega.com/t5/Blog-EN-Business-IT/Making-enterprise-architecture-actionable-Fannie-Mae-s-success/ba-p/17519

本文：https://pub.intelligentx.net/making-enterprise-architecture-actionable-fannie-maes-success-story

讨论：请加入知识星球或者小红圈【首席架构师圈】

在之前的Marc Lankhorst博客中，参考架构的价值得到了突出体现，包括原因和方式。在这篇博客中，我想深入一点，专注于我们（或我们中的一些人）熟悉的“产品” - 参考模型，使用ArchiMate作为语言。

什么是参考模型？

首先，我们退后一步，并参考参考架构，这些架构被描述为“为特定领域，行业或领域提供参考框架的标准化架构”。

参考模型带来的是一个非常清晰的视图（通常是在页面上）的感兴趣的领域 - 可以重复使用的东西，当然可以调整以适应组织。

参考模型类型的示例：

• 业务参考模型（或BRM）
• 技术参考模型（或TRM）
• 信息参考模型（或IRM）

有许多行业参考模型可供任何人使用，但真正的优势在于将这些模型转化为组织特定的参考模型 - 这些模型可以促进讨论，​​促进重用，并为其他建筑领域提供可追溯性。

我如何使用ArchiMate表示这一点？

参考模型通常只是PowerPoint幻灯片，Visio图表，甚至是Excel电子表格中的一些填充单元格。这非常适合进行通信，并且可以一次性获取消息。

当我们谈论企业架构时，很少有参考模型被孤立使用 - 我们需要将它们“链接”到其他区域，因此需要使用标准将参考模型元素绑定到 - 例如ArchiMate。

一次又一次出现的问题是 - “我应该使用什么概念来表示这个特定参考模型上的'块'？”

这是一个通常需要花费数天甚至数周讨论的主题领域 - 并且争论它实际上只是违背了使用参考模型的目标，因为，参考 - 我们需要就表示达成一致，然后只是始终如一地使用它！为了建议或回答这个问题，我们确实需要放大相关的参考模型。我将回顾上面提到的三个例子。

业务参考模型

基本上描述了“在页面上的商业”，我们将父母“区域”分解为儿童，然后是孙子等。它应该描述“组织的作用”，这通常提供了一个很大的线索。

对于那些至少具有ArchiMate工作知识的人来说，某种“行为”正在被描述，它本质上应该是“商业性的”。这听起来像商务功能！

Microsoft Industry Reference Architecture for Banking

 

技术参考模型

 

与业务参考模型类似，TRM通常描述“基于页面的基础结构”，但同样在更具功能性的角度 - 它不应该是关于服务器x，y和z，处理器和服务器的细节级别。 技术信息的类型。

考虑到这些要点，我们再次关注基础设施服务和基础设施功能（即行为）。

The Cloud Ecosystem Reference Model

 

信息参考模型

到目前为止，在上面的两个例子中，我们注意到“行为”概念似乎被使用 - 这通常是一系列参考模型的情况。 毕竟，“结构”概念通常更接近于实施。

IRM描述了组织内部可用的常见“信息”（TM论坛SID就是很好的灵感）。 从正确的角度来看，行为概念的使用并不合适 - 因此我们在逻辑上看待“被动结构”专栏（描述某种“对象”）。

正如ArchiMate的忠实用户所知，可能会决定是否使用Business Objects或Data Objects来表示IRM的元素。 这再次受到解释，但通常像“信息”这样的高级别可能最适合作为业务对象。

 The Information Framework (SID)

 

结论

因此，我们有它。 使用ArchiMate使用参考模型的一些建议。

您可以使用各种ArchiMate概念来表示模型中的元素; 但最重要的一点是要就标准达成一致（并坚持下去），在使用中保持一致，并分享结果！

最后一个结论侧重于向“非技术”利益相关者展示 - 记住，虽然建筑师可以用标准化的ArchiMate表示法创建参考模型（创建有效的关系以执行影响分析等），但没有理由不输出 是不同的（它可以是“通知”类型的观点）。

 

 

本文：http://jiagoushi.pro/reference-architecture-models-archimate

讨论：请加入知识星球【首席架构师圈】或者飞聊小组【首席架构师智库】

在此之前，我写过关于数字化变更功能以及企业架构如何支持并为您的组织提供价值的需求。 我还讨论了如何在不同的抽象层次上对架构描述进行分类。 但是有一个方面我没有深入研究：与您的组织相比，架构描述的概念性或具体性如何？

在过去的十年中，已经开发了参考架构，并且已经发布了许多参考架构。 它们是描述企业的一个非常有用的开端，架构或多或少地特定于我们的企业。 我不想在学术讨论中迷失自己应该归类为什么，所以我将专注于背后的想法的重点。

从通用架构到特定于组织的架构

上图中显示的频谱从左侧开始，具有最通用的架构类型，即Foundation Architectures。通用技术或基础架构体系结构通常属于此类，例如TOGAF 9.1规范所涉及的技术参考模型（TRM）。在这里，我们经常发现技术或技术平台的架构描述。

向右移动，Common Architectures可以基于Foundation Architectures构建。通常，这些对于组织的体系结构更具体，但是，这些体系结构仍然可以应用于所有行业。我想提出可以在不同行业中使用的企业资源规划（ERP）参考架构或ERP系统的示例。

如果体系结构更具体，但仍可能在同一行业的多个组织中重复使用，则这些体系结构可归类为行业体系结构，例如， ERP汽车参考架构。另一个例子是开发用于能源和水行业的ERP系统，其中一些国家的公司面临着许多不断变化的监管变化。

特定于组织的体系结构是您为组织描述的体系结构，主要用于支持程序或项目。因此，它们是您企业最具体的架构描述。

TOGAF称架构描述为“工件”，它是“描述架构方面的架构工作产品”，可以用表格，矩阵或图表表示（TOGAF 9.1,2.5）。 TOGAF规范中有关于此类别频谱如何相互关联的更多信息，但让我关注最实用的部分。

你在实践中用了什么？

在实践中，我经常看到特定于组织的体系结构（我们的体系结构描述）和特定于行业的体系结构。如果您找不到适合您所在行业的参考架构，您可能需要再次尝试寻找更通用的架构 - 通用架构或基础架构。这些参考模型存在于各种架构领域中;例如用于功能，业务流程（例如ITIL），功能，应用程序，技术或风险和安全性。

现在，您可以根据功能/解决方案描述并根据其特异性对体系结构描述进行分类。以下示例将有助于在实践中应用此分类。

体系结构分类的实例

为了实现这一目标，您可以使用提供技术信息服务的公司提供的技术分类分类法。其中一家公司是Flexera BDNA Technopedia，它提供有关技术生命周期的信息等。这是对技术进行分类的良好起点，是旧版TOGAF TRM的替代品。此外，如果您错过了某些分类，请记住TOGAF所说的“根据您的需要定制参考模型”。

下表显示了企业连续体中的示例：

基础架构	一般架构	行业架构	特定于组织的架构
TOGAF TRM including OS and DBMS, BDNA,  Open Infrastructure Architecture repository OIAr	TOGAF III-RM, IT4IT, ERP-Architecture	BIAN Capability Map, ERP-Architecture for Automotive	Capability Map Company XY, ERP Architecture Company XY
Linux, SAP Hana, MS SQL, Kafka	SAP ERP	SAP ERP Automotive	SAP ERP of Company XY

现在，您可以通过该方法对架构描述进行分类。 为了实现EA成为自适应企业的价值主张，您可以仔细研究架构和解决方案构建块，这可以防止您在管理作为EA架构师的所有已部署实例时迷失方向。

在本系列的下一篇博客中，我将概述如何使用ArchiMate以全球标准符号描述这些体系结构。 这将帮助您标准化有关架构描述的沟通，以支持战略变更！

要获得有关ArchiMate及其在BPMN，UML和其他符号旁边的定位的简要说明，请阅读将ArchiMate 3.0与其他标准结合使用。

讨论:请加入知识星球【首席架构师圈】

在之前关于我们协作平台功能的博客文章中，我们已经解释了如何通过结构化工作流支持人们在架构和其他模型上一起工作。在那篇文章中，我们展望了未来的功能，以支持这种协作。是时候向您介绍最新动态了！

 -  Marc Lankhorst，Fabian Aulkemeier

首先，我们需要区分不同类型的用户。一方面，我们有建模专家使用Enterprise Studio来创建，分析和更新不同类型的模型。另一方面，有各种类型的临时用户，他们不需要完整建模环境的力量，但他们想要获得洞察力，提供反馈，审查，批准或以其他方式与这些模型交互。这些用户更可能习惯于我们的协作和发布门户网站HoriZZon。

至少有两个常见案例，这两个小组紧密合作：

• 收集来自更广泛组织的意见。例如，来自“业务”的某人想要请求更改某个需要由专家实施的流程模型，或者组织中的应用程序所有者需要提供有关他们负责的应用程序的某些属性的信息。
• 在围绕体系结构，业务流程或数据模型的治理流程中。在这里，具有一定管理职责的人（比如架构委员会的成员，安全官或数据所有者）需要审查和批准某些模型，并且专家（例如架构师）需要处理此反馈。

在Enterprise Studio和HoriZZon中，我们现在通过输入表单和自定义工作流为这些场景提供广泛的支持。

在HoriZZon输入表格

为了帮助您从组织收集相关输入，例如在上述场景中，在下一版HoriZZon中，您将能够配置输入表单。这种形式由一组各种类型的字段组成，从简单的名称和数字到更复杂的字段，如模型对象和需要参与的用户ID。

在下面的示例中，此类表单用于从应用程序管理器收集数据。他们需要填写许多不同的领域，从名称，首字母缩略词和所有者到生命周期状态，支持层和它提供的服务。

以这种方式收集的输入不会直接放入模型中。这将是有风险的，因为不是每个人都是建模专家，并且这些领域中的一些（例如所提供的服务）需要在模型中创建某些关系。这是应该由专家检查和执行的事情。出于这个原因，来自这种表单的输入被发送回具有Enterprise Studio的用户，然后Enterprise Studio可以简单地应用建议的更改，改进甚至拒绝它，以防它导致一些不一致。

这种工作方式的各个步骤是使用工作流程配置的，我们的下一个主题。例如，您可以使用此类工作流将上述调查表单发送给所有应用程序所有者，或者用于更高级的治理目的。

自定义工作流程

在许多组织中，对架构，流程和数据的更改进行明确而严格的管理至关重要。例如，监管合规或风险管理可能要求特定的工作人员批准某些变更。在大型组织中，这可能需要多个步骤并涉及各个部门和角色。还有其他场景需要这样一个结构化的过程，如上面提到的调查。

为了支持这些类型的流程，HoriZZon整合了一个完整的工作流引擎，可以根据您的特定流程进行配置。基本的批准和更改工作流程是开箱即用的，但您也可以配置自己的自定义工作流程，在BPMN模型中定义。

下面的示例显示了如何通过在与应用程序架构师对话的情况下提供信息的输入和潜在补救来使前一示例中的应用程序管理器参与架构的维护。

在这样的工作流程中，您可以定义需要执行特定步骤的人员，从而确定所涉及的每个人之间的协作。通过电子邮件通知需要执行步骤的人员在HoriZZon中有等待他们的任务;例如，架构委员会成员需要批准一些更改。您可以使用表单配置事物（如上所述）以从任务执行者获得各种输入;例如，如果进行了一些更改，架构板成员可以给出有条件的批准。此输入将通过Enterprise Studio发送回建模人员，Enterprise Studio会将其选中并处理输入;在该示例中，架构师应用架构板成员建议的更改。然后可以将结果发送回HoriZZon以供架构委员会最终批准。

上面的示例仍然非常简单，但您可以根据需要将这些工作流程设置为高级，涉及多个个人，组或角色。结合这两个功能，输入表单和自定义工作流，为您提供了组织模型周围各种组和角色协作的方法。鉴于我们平台的灵活性和可配置性，这方面的机会是无穷无尽的。

您想了解更多有关我们平台的这些和其他功能的信息吗？参加我们的网络研讨会或申请免费试用！

ALSO CHECK: Data Analysis with Dashboards in HoriZZon

原文:https://bizzdesign.com/blog/organizing-architecture-governance-with-workflow-and-forms/

本文：

讨论:加入知识星球【首席架构师圈】

Dragon1是企业架构建模和设计的专用软件。在此页面上，我们提供了创建EA蓝图的教程。首先，我们介绍一些关于创建EA蓝图的开放式Dragon1 EA方法理论，接下来我们将在Dragon1平台上创建EA蓝图的步骤布局。

学习目标

本教程的学习目标是：

• 什么是企业架构？它的功能是什么？
• 什么是EA蓝图？为什么要创建一个？
• 企业架构师的主要任务是什么？
• 如何在Dragon1上创建交互式EA蓝图？

介绍

作为架构师，您通常需要为利益相关者创建景观，蓝图和路线图。因此Dragon1被优化以创建这三种类型的可视化。

企业架构蓝图，五大＃1

作为EA方法的一部分，Dragon1定义了一个包含参考模型和体系结构的开放EA框架。

五个最重要的蓝图被命名为“五大”，其中EA蓝图是最重要的蓝图。那个我们将在这里讨论。

在创建EA蓝图之前，请务必按照“入门”区域的“跳转右侧”页面中的建议开始使用第一个教程。

为什么要创建EA蓝图？

有许多不同类型的组织，如企业，公司，学校和政府机构。所有这些都是组织，因为他们是使用手段和资源共同实现目标的人群。

您越了解人员，手段和资源的组织方式，就越能够更好地管理它们以实现目标。管理我们的意思是：设定目标，检查进度和（重新）指导项目或工作。

但是，组织通常缺乏结构的概述和依赖性。这是因为组织不断创新并适应他们变化的环境（在改变客户需求，技术和立法方面）。蓝图是在组织所包含的部分之间存在相互关系或依赖关系时创建概述和见解的最佳实践。

结构（总元素）

企业架构作为一个工作领域和Dragon1开放EA方法将组织视为流体系统。

在逻辑层面，系统由元素组成。没有一秒钟，组织与另一秒组织相同。系统中的所有元素都与其他元素直接或间接相关。这意味着如果要更改组织中的元素，则更改的内容将超过直接结构。您还将更改您不想要或不想要的相关部件。或者反过来说，其他部分可以阻止或阻碍您的预期变化。

架构（总体概念）

了解组织如何存在元素以及它们如何相关，就是了解组织的结构。它是组织的物理（技术）或逻辑（功能）级别视图。但是当你知道元素组如何协同工作作为产生结果的概念时，你就会知道组织包含哪些概念（及其原理）。换句话说，您就知道了组织的企业架构。为什么这很重要？好吧，如果您更改元素（在逻辑级别）或组件（在物理级别），您可能会干扰或启用元素的组协作（即概念的原则）。

假设您的组织正在打印书籍，但新购买的干净再生纸比以前使用的纸张厚。然后，使用当前的打印机打印可能不会成功，并且还必须购买新的打印机。因此，这篇新论文破坏了当前组织的印刷原则：通过使用廉价和薄纸，我们可以使用任何低成本的打印机，并生产大量的书籍，以获得有利可图的价格。

作为一名架构师，您可以通过沟通概念和原则的当前状态以及战略需要哪些新概念和原则以及变革如何影响组织中的概念和原则来获得巨大的附加价值。换句话说：您绝对应该创建企业架构蓝图以增加您的附加值。

设计蓝图

Dragon1 open EA Method将体系结构定义为结构（如组织）的特殊总体概念。架构师被定义为该概念的设计者及其实现的监督者。因此，为了创建EA蓝图，架构师必须选择和分组概念。但要了解组织需要什么概念，架构师必须知道架构在组织治理中的位置。架构被Dragon1定义为战略与转型之间的桥梁。因此，任何总体概念（=架构）都可确保执行正确的转换以实现策略。并且架构为执行转换的所有程序和项目提供了完整的设计或蓝图。

架构师必须去组织的战略利益相关者并获得有关战略的信息（使命，愿景，抱负，起点，问题，关注点，目标，需求和要求等......）

有了这个，他收集，选择，组amd修改和适应概念，因为它们是策略所要求的。在EA蓝图上，架构师将概念，原理，元素和/或组件作为一个整体设计。这些部件通常按层和域分组。在EA蓝图中，通常可视化层：市场和客户，治理，业务，信息（或数据和应用）和技术或这些层的任意组合。这些层填充了来自概念的元素或组件。像业务层中的流程，功能和单元一样。

接下来，架构师定义转换的各个部分：程序，项目，阶段，阶段，里程碑和可交付成果。

因此，在开始在Dragon1上创建EA蓝图之前，了解所有这些是一件好事：为什么，什么以及如何创建EA蓝图。

创建企业架构蓝图

以下是在可视设计器中创建蓝图的步骤。您将在下面看到一个屏幕截图，其中显示了您可以用作编辑模板的示例蓝图。

要创建EA蓝图，请执行以下操作：

• 在电子表格中收集策略，体系结构和转换数据
• 创建文件夹结构
• 自动导入数据或手动输入数据
• 丰富数据 - 如果缺少数据，请填写数据
• 创建模型 - 创建包含所有数据的企业模型，或创建一起形成企业模型的多个模型
• 在模型中创建大约20个数据视图：利益相关者视图，关注视图，产品视图，流程视图，应用程序视图，程序视图，可交付成果视图等...）
• 创建可视化
• 在可视化上绘制每个视图的可视项
• 将Visual Items链接到视图
• 在正常模式下切换蓝图并观察您的蓝图（正在解释可视项目）
• 当然，您可以创建单独的战略和转型蓝图，或为特定项目或解决方案创建解决方案蓝图或路线图。
• 您还可以创建AS-IS蓝图或TO-BE蓝图，并在它们之间定义GAP并显示该GAP。
• 无论如何，创建EA蓝图后还有很多事情要做。
• 将蓝图发布到Content Viewer并与利益相关者共享。
• 请他们在Content Viewer中添加评论。
• 处理评论以改进蓝图。
• 教育利益相关者可以使用蓝图以及如何使用蓝图。
• 下次要创建EA蓝图时，请使用此蓝图从导演获取设计任务，作为架构师的所有者/客户。

下面我们将详细介绍上面的所有步骤。

创建文件夹

要为EA蓝图创建文件夹结构：

• 创建档案结构

导入数据

要自动导入数据或手动输入数据：

• 导入数据
• 输入数据

创建模型

创建包含所有数据的企业模型，或创建一起形成的多个模型和企业模型。

要为EA蓝图创建企业模型：

• 创建模型

创建视图

在模型中创建大约20个数据视图：利益相关者视图，关注视图，产品视图，流程视图，应用程序视图，程序视图，可交付成果视图等...）

要创建视图：

• 创建一个视图

创建可视化

我们现在有数据，模型和视图。最后，这些视图需要在可视化画布上可见，以形成可视化。首先，我们将创建一个可视化画布。

要创建可视化画布：

• 创建可视化
• 插入体系结构视图布局模板

•  

绘制视觉项目

Visual Item是一个形状/数据占位符，放置在可视化文件上并链接到视图。可视设计器将解释在“正常模式”下可视项目中配置的规则，以在可视化画布上显示链接视图的数据。

在每个视图中绘制可视化上的可视项目。

要在可视化画布上插入可视项：

• 插入可视项目

在您希望在可视化画布上生成视图数据的确切位置绘制包含背景颜色的可视项目是一种很好的做法。

视觉项目需要链接到视图。

确保你已经这样做了。

切换到普通模式

在正常模式下切换蓝图并观察跟踪和跟踪蓝图

要在正常模式下切换蓝图：

转到播放器栏并将编辑模式切换到普通模式

现在将解释可视项目，如果所有设置都正确完成，将在正确的位置显示视图的数据。

发布

将蓝图发布到Content Viewer并与利益相关者共享。

要发布蓝图：

• 发布可视化

•  

添加交互性

如果要为EA蓝图添加交互性，可以执行以下操作。您可以在鼠标悬停或鼠标单击形状时生成弹出对话框。您可以通过此蓝图的链接插入时钟到其他可视化。例如，如果单击它，则转到流程或应用程序的详细可视化。

要生成弹出对话框：

• 使用弹出对话框

要插入点击链接：

• 使用点击链接

第三个标准的交互性是跟踪和跟踪。对于跟踪和跟踪，您无需执行任何额外操作。通过可视设计器和内容查看器中播放器栏上的开关，您可以打开和关闭跟踪和跟踪。

示例屏幕截图

原文: https://www.dragon1.com/help/create-enterprise-architecture-blueprint-big-five-1

 

很少有组织能够系统可靠地将业务战略转化为跨组织所有相关要素的行动。只有在稳定的情况下，才能通过连续的分解，设计和实现步骤来实施长期计划。传统的自上而下策略实施无法跟上快速变化的环境所需的转换速度。

组织需要通过将同时运营的学科与相同的期望业务成果保持一致来开发一致的业务转型管理能力，从而将它们指向同一方向。这种能力协调和协调各相关学科的变革工作。这需要从不同的角度清楚地了解企业的​​结构和发展。我们至少看到了业务转型中涉及的以下相关学科：

• 战略发展
• 基于能力的计划
• 企业组合管理
• 计划和项目管理
• 持续交货
• 服务管理
• 流程，规则和数据管理
• 治理，风险和合规

在之前的博客中，我们描述了企业架构如何在此转型管理中充当“知识中心”。企业架构模型的使用为这种连接作用提供了理想的基础。

在BiZZdesign的Enterprise Studio中，我们为这些关系提供广泛的支持。 Enterprise Studio使组织利益相关者能够将业务战略转换为转型计划，并通过使用EA模型集成各种观点的指标。我们正在扩展我们的工具能力，以实现企业组合管理，决策管理，风险管理，利益相关者协作以及与项目管理和BI工具的集成。因此，Enterprise Studio使用户能够有效地建模和分析目标业务成果与支持它们的计划和项目之间的直接视线联系。

这些关系的一些例子如下所示。该图显示了战略，基于能力的规划和企业架构之间的典型信息流。在这个三角形中，我们看到该战略通知了基于能力的规划和企业架构。战略重点，业务模式和目标运营模式。考虑到架构的当前状态和灵活性，EA提供有关这些选择的成本和可行性的反馈。基于能力的计划根据战略方向定义所需的能力并设定变更目标。 EA用于评估其依赖关系和变更的影响。

 

Enterprise Studio以各种方式支持这些关系。 例如，您可以使用Business Model Canvas来描述您的业务模型和策略。 有关您的运营模式的战略决策可以转换为有关业务功能标准化和集成的架构原则，这反过来又会影响支持应用程序的设计。 描述业务能力图的体系结构模型在此上下文中是非常有用的工件。

反过来，这样的能力图可以与支持业务流程和IT资源相关联，并且支持您的策略所需的能力级别可以转化为这些流程和资源的改进。 您可以使用Enterprise Studio的Enterprise Analytics模块执行成本计算，分析当前的IT环境或评估更改的影响，并以可访问的管理仪表板的形式显示这些结果。 该信息是您的资产组合和变更计划的投资决策的重要输入。

企业组合管理和企业架构共同为项目和项目管理提供指导。 EPM设定投资优先级并确定各种变更计划的预算，而EA则用于分析其收益，成本，风险和依赖关系。 反过来，程序和项目管理提供了考虑到这些依赖关系的变更路线图。 它还为EPM提供有关计划和项目所交付的价值和预算的跟踪数据。

Enterprise Studio为您提供了一个管理此信息的集成平台。 其坚实的基础，基于您企业的形式化模型，确保了一致和连贯的信息库。 这对于明智的决策至关重要，可以将所有相关的学科都集中在实现战略业务成果上。

原文：https://bizzdesign.com/blog/driving-business-outcomes-with-enterprise-architecture-as-a-knowledge-hub/

本文：http://pub.intelligentx.net/driving-business-outcomes-enterprise-architecture-knowledge-hub

讨论：请加入知识星球或者小红圈【首席架构师圈】

在我之前的博客文章中，我写过关于价值驱动的企业架构及其与企业内不同学科的关系。在这篇博客中，我想关注使用参考体系结构的附加价值。

什么是参考架构？

参考体系结构是标准化体系结构，为特定域，扇区或感兴趣的领域提供参考框架。参考模型或体系结构提供了通用词汇表，可重用设计和行业最佳实践。它们不是解决方案体系结构，即它们不是直接实现的。相反，它们被用作更具体架构的约束。通常，参考架构包括通用架构原理，模式，构建块和标准。

许多域都定义了自己的参考体系结构。众所周知的例子包括：

• 银行业的BIAN服务格局;
• ACORD保险业框架;
• TMforum为电信行业提供的eTOM业务流程框架;
• 各种政府参考架构，例如荷兰NORA及其“女儿”，美国FEAF或澳大利亚AGA;
• NAF，DODAF和MoDAF等国防架构框架;
• 制造和供应链的参考架构，如ISA-95和SCOR。

这些体系结构中的大多数包括域中的公共业务功能/功能和业务流程。除此之外，它们可以包括例如通用数据模型，通信标准和交换格式，有时甚至包括通用软件构建块和其他可重用资产。

为什么要使用参考架构？

那么使用这种参考架构的价值是什么？为什么以及何时应该使用它们？

首先，参考体系结构提供了一个参考框架，可帮助您了解特定域，并为您自己的企业体系结构工作提供了一个起点。它们为您提供基本结构，因此您无需重新发明轮子（无论如何通常都是正方形）。参考体系结构对于您不与其他人竞争的组织的这些方面和元素最有价值。

例如，典型保险公司的业务功能与其竞争对手的业务功能大致类似，其业务流程也很多。竞争差异很可能出现在其产品，定价，客户群和客户关系中。重用参考架构提供的行业最佳实践可确保您不会在这些非竞争方面落后于曲线。我们在许多IT系统的实施中也看到了这一点，其中SAP等供应商为组织的大部分提供参考流程。例如，您的会计流程很少具有竞争优势。

使用参考体系结构的第二个原因是互操作性。在我们日益网络化的世界中，组织需要与各种其他方面建立联系和合作。参考体系结构提供的标准和构建块有助于实现这些连接。一个相关的好处是使用标准提高了灵活性，因为交换通过标准化接口连接的构建块更容易;反之亦然，如果构建模块本身是标准化的，那么开发标准要容易得多。乐高是一个完美的例子，正如我的同事Bas van Gils最近在他的博客中所描述的那样。

这就引出了使用参考架构的第三个原因：兼并和收购以及外包。如果双方使用相同的语言，使用相同的标准，并认识到功能，过程和/或系统之间的相同边界，则以新的方式重新组合它们的元素将更加容易。

使用参考体系结构的第四个原因是为了促进您所在行业的基准测试。通常，公司之间的差异不在于例如他们的业务流程，但在他们的执行。使用参考设计可以更容易地比较这些执行结果。

基准测试将我们引入参考架构非常重要的第五个原因：法规遵从性。通常，监管机构规定（或至少强烈建议）参考架构。例如，会计原则，实践和流程日益标准化和强制执行。这导致了业务报告标准，甚至达到了XBRL等交换标准的水平。

如何使用参考架构？

在决定使用参考架构之前，应该满足一些条件。首先，参考架构应该是基于社区的。用户而非供应商应决定最佳实践，并且应该由用户社区主动维护该体系结构。世界正在发生变化，您的参考架构也应如此。

在描述架构时，使用开放标准可以理想地补充这种积极和开放的社区流程。 BiZZdesign提供了许多开箱即用的参考架构模型。

在组织中使用参考体系结构也需要治理：组织应该真正致力于其使用，并且应该以某种方式“强制执行”。如果人们真正按照预期使用它们并且实际遵循他们的指导，那么参考体系结构才有价值，否则重用行业最佳实践的整个想法就会崩溃。

最后，您选择的参考架构应提供真实，可操作的指导。一般的架构原则是不够的。需要实际结构，例如在业务功能或流程，构建块和标准方面，为您自己的架构工作提供有用的主干。

使用参考体系结构并不意味着您失去了所有的设计自由。相反，您可以将这种自由集中在企业的哪些方面，从而实现真正的改变。这是您作为建筑师可以增加最大价值的地方！

原文:https://bizzdesign.com/blog/the-value-of-reference-architectures/

本文:http://pub.intelligentx.net/node/370

讨论:加入知识星球【首席架构师圈】

近年来，企业架构领域对ArchiMate标准的采用发展迅速。2017年底，它又向前迈进了一步，被北约批准与北约架构框架[1]一起使用。ArchiMate流行起来的原因是什么?

 

ArchiMate是什么?

ArchiMate®是一种用于描述和可视化企业架构的语言。它最初是在2002年至2004年间由荷兰Telematica研究所开发的。2008年，所有权转移到Open Group®，该公司将其作为开放标准进行管理。企业架构师通常使用一系列不同的表示法。大多数，如BPMN™和UML®，是为特定的目的而设计的，如流程建模或软件开发。ArchiMate通过其企业建模范围将自己与这些工具区别开来，这使得它特别适合于改进业务和it之间的一致性。

为什么ArchiMate企业架构框架如此成功?

ArchiMate旨在成为一种简单的语言，它包含正确的概念，在正确的层次上，支持企业架构的实用建模方法。它在定义语言范围的框架上下文中设置概念。“核心”框架包括用于业务、应用程序和技术的层，以及用于战略、实现和迁移的附加层。通过围绕IT和业务，ArchiMate解决了业务和技术涉众的主要关注点，为他们提供了一组用于描述企业的公共概念和视图。

ArchiMate定义了如何使用定义良好的关系将描述企业的概念链接在一起。使这些关系清晰和明确，使涉众能够评估和交流决策和更改在各个领域的结果。ArchiMate中的许多概念和关系都是基于UML和BPMN中的概念和关系，为这些建模语言提供了一个方便的桥梁。

然而，ArchiMate并不打算取代这些现有的标准。事实上，ArchiMate的成功很大程度上可以归因于这样一个事实，即它的目标是尽可能小，通过只包含那些对其预期目的有用的概念和关系，使学习变得更容易。这可能被认为是限制性的，但正如语言学家Guy Deutscher[2]所指出的:

“如果不同的语言以不同的方式影响我们的思维，这并不是因为我们的语言允许我们思考，而是因为它让我们习惯性地思考。”

把事情省略掉可以帮助我们集中精力描述什么是重要的。ArchiMate提供了企业的视图，作为道路地图集，而不是详细的调查地图。

一些建模符号，特别是那些来自软件分析和设计技术的符号，可以促进对高级业务涉众来说过于详细的方面的关注。此外，它们经常遵循“关注分离”的工程原则。这导致了建模过程、数据、基础设施等的清晰且严格划分的图表类型。相比之下，ArchiMate解决了高级利益相关者看到“大局”的需求。它鼓励使用面向利益相关者的视图来显示感兴趣的对象之间的关系，不管它们是什么。对象可能来自不同的层。例如，可以在一个图表中显示为特定类型的客户提供服务所需的技术、应用程序和流程

越来越多的组织和顾问正在采用ArchiMate。作为一个独立的标准，它不依赖于特定的供应商或工具。这有助于避免厂商锁定并降低培训成本，因为如果用户迁移到新的ArchiMate工具，他们不需要学习新的符号。主要的技能和培训是广泛可用的，所以新员工可以很快变得富有成效。此外，用户可以通过开放群组的ArchiMate论坛来提高自己的知识和分享经验。

在企业架构领域中处于领先地位

ArchiMate并不打算取代现有的建模技术。正如ArchiMate规范所述:

“许多其他语言试图满足所有可能用户的所有需求。为了简单的学习和使用，ArchiMate语言被限制在那些足以建模80%的实际案例的概念上。

ArchiMate通过以超越领域边界的标准方式捕获和可视化架构信息，补充了其他建模技术的使用。这样做实际上有助于利用其他技术。许多EA计划之所以失败，仅仅是因为信息以主要涉众无法理解的模型的形式被捕获(并保留)。ArchiMate提供了一种方法来可视化在其他模型中创建的选定对象和关系，从而使那些模型的价值在更大范围的涉众面前显现出来。通过提供一种通用的沟通方式，ArchiMate为所有的涉众(业务和技术)提供了一个企业的综合视图。

HOPEX ArchiMate如何为您的架构工作增加价值

作为企业架构的领导者，MEGA将ArchiMate 3.0.1标准集成到其通用的企业架构存储库中，以加速时间与价值的转换。这个ArchiMate的新实现构建在一个统一的HOPEX平台上，它通过共享关键对象来提供与其他企业架构产品的兼容性。这使得企业架构师能够轻松地在用例之间移动，例如应用程序组合管理、IT合理化、IT战略规划和业务流程分析。

 

References

[1] “NATO C3B Adopts OMG Unified Architecture Framework Metamodel”, OMG Press Release, 27 November 2017. http://www.omg.org/news/releases/pr2017/11-27-17.htm

[2] “Does Your Language Shape How You Think?”, Deutscher, G., The New York Times Magazine, 26 August 2010. https://www.nytimes.com/2010/08/29/magazine/29language-t.html?_r=1

[3] “ArchiMate® 3.0.1 Specification”, Section 3.1: Language Design Considerations, The Open Group, 2017. http://pubs.opengroup.org/architecture/archimate3-doc/chap03.html

 

原文：https://community.mega.com/t5/Blog-EN-Business-IT/How-adding-ArchiMate-to-your-enterprise-architecture-toolkit/ba-p/17266

本文：https://pub.intelligentx.net/how-adding-archimate-your-enterprise-architecture-toolkit-helps-give-you-big-picture

讨论：请加入知识星球或者小红圈【首席架构师圈】或者加微信小号【intelligenttimes】

在 IT 领域工作了二十多年，我遇到了各种描述 IT 环境的不同方法。我最喜欢的模型是我自己提出的数据驱动模型，但需要最新的 CMDB 和 Visio。有像 TOGAF 这样的标准方法，提供 Open Group ArchiMate 图表定义，用于建模企业架构。规格很广泛，但我想我会分享我使用通用办公生产力工具 Powerpoint 的简单解决方案。

通常，要创建企业架构图，您可以使用标准的 Microsoft Visio，或者如果您更认真，则可以使用 Sparx EA。我发现你也可以使用简陋的 Powerpoint 进行管理。您只需要使用我创建的演示模板。它允许您拖放元素以按照您喜欢的方式创建模型。为了帮助您入门，我在这里描述了三个最有用的图表和使用模板创建它们的过程。

所选模型使用 TOGAF 定义的六个不同层（业务、应用程序、技术）中的三个来描述架构。 （战略、物理和实施与迁移层，我们将在下次讨论）

业务层

无论您是为解决方案架构创建图表还是试图描述完整的企业架构，最好的方法都是从业务层开始。第一个图表将用于通过定义角色、服务、流程和数据来设置架构描述的范围。为此，请创建一个列表，然后使用下面的前四个元素并将它们展开在您的第一张幻灯片上。为了清楚起见，我留下了<标准名称>，但您应该使用对您有意义的名称相应地标记元素。

下一步将是创建一个交互图，其中定义了业务参与者和连接。 所以基本上你只需要根据数据流、交互和依赖关系来连接你的元素。 现在 Powerpoint 真的不是一个绘图工具，所以它需要更多的摆弄才能得到你想要的流程。 在我的模板中，标签是与箭头分开的对象，因此一旦您将它们复制粘贴到您需要它们的一般区域，您可能希望将它们取消组合。 您最终将得到一个类似于下面显示的图表。

另一种方法是仅使用标准连接器并更改形状的轮廓以匹配所需的箭头和可能的线条中的破折号。对于专业化、实现和聚合箭头，您需要使用复制粘贴添加自定义箭头。在此阶段，您还希望使用对您的组织有意义的解释来标记连接器。在实践中，很多人只使用普通的箭头连接器，只使用标签。

一个问题是 Powerpoint 幻灯片上的空间是有限的，但由于我们想要保持图片可读，我们并不真的想要创建巨大的图表。将设计拆分为逻辑块是一种很好的做法，其中一个业务角色的交互和流程在单个图表中进行描述。从某种意义上说，这也是一种很好的做法，因为您可以更容易地进入下一步，使用相应的应用程序层元素来描述应用程序的功能。

应用层

现在这一步的主要目标是将业务服务描述为最终可以作为服务实现和管理的技术组件。在现代微服务架构中，应用程序逻辑将由负责实现业务服务的每个不同部分的独立组件组成。我们对数据模型和信息流掌握得越好，以后就越容易将实施工作分解为可管理的任务作为工作包。

 

应用程序视点图由它提供的服务、它使用组件内部运行的功能实现的流程组成。 因此，首先从业务层收集与业务流程匹配的应用程序流程是最容易的。 现在每个流程都将由 IT 服务实施。 在服务或应用程序中，有一些组件实现了通常对应于流程的功能。 有时存在更高级别的抽象，并且函数实际上被多个进程使用。

无论您是描述现有解决方案、重构它还是创建一个全新的解决方案，接下来的分析任务都至关重要。了解与我们对解决方案的要求相匹配的模式和最佳实践应该可以指导我们找到正确的解决方案。最重要的是，我们清楚哪些组件应该由使能技术提供，哪些实际上是我们自己解决方案范围的一部分。为这些依赖项添加数据对象和技术接口有助于我们了解全局。

技术层

在描述了业务服务的功能之后，我们需要开始设计具体的操作环境。位置为我们提供了所需网络架构的提示。技术是指托管堆栈，节点是实际的应用程序驱动环境。可以有多层节点、技术和位置，以便我们可以根据需要尽可能详细地描述地理分布要求、虚拟化和容器托管。

我喜欢从应用程序组件开始，因为您应该从应用程序级图表中准备好它们。 基本上只需从应用程序层幻灯片复制粘贴行并将它们设置为新幻灯片上的最高。

结论

使用 Powerpoint 绘制企业架构图是开始描述您的需求、所需功能和操作环境的一种简单方法。 我们已经描述了一个基本的图表，但很容易扩展（即颜色元素）模板以满足您的组织需求。 此外，为了使模板更可用，组件可以以 .emf 格式定义并导入到 Powerpoint 工具中。 然而，目前只创建了基本的业务、应用程序和技术形状。 用策略和迁移层的对象填充整个调色板仍然是一项简单的工作。 现在，作为家庭作业，您可以创建自己的图表，并使用 <serving> 连接器将所有三个连接在一起形成一张大图。

原文：https://medium.com/@roxblend/modeling-enterprise-architecture-in-powerp…

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

企业架构是一门完整的科学和专业。 尽管如此，企业架构领域还很年轻，所以对于我们大多数人来说，它都是全新的。 在下面您将找到一个“如何”分步教程列表，以创建有效的，可视化和交互式的架构产品。

当你忙的时候企业架构

在工作中，您很好奇如何创建某些企业架构产品或如何执行某些架构流程？ 本网站上的资源是您的指南，它将引导您完成符合Dragon1开放EA方法的Visual Enterprise Architecture的步骤。

您的分步教程

在这里的每一页上，您都会找到一系列步骤来设计符合Dragon1开放EA方法的非常有用的架构产品。 产品的顺序是创建符合Dragon1开放EA方法的产品的理想/正常顺序。

我们为您提供以下分步教程：

A）企业架构 - 概念架构设计

创建的以下产品都是架构设计应用程序的第1阶段：

1. 如何创建利益相关者需求和需求分析图（利益相关者企业愿景）
2. 如何创建企业结构元素和功能图（企业结构愿景）
3. 如何创建企业架构功能，概念和原理图（企业架构愿景）
4. 如何创建ArchiMate业务功能图？
5. 如何创建企业全面概念的设计草图？

B）企业架构 - 初步架构设计

创建的以下产品都是架构设计应用程序的第2阶段：

1. 如何创建一个概念的原理细节图？
2. 如何创建元模型，用户模型和实例模型？
3. 如何创建流程横向图（具有业务功能）？
4. 如何创建应用程序格局图（静态和动态）？包括域，信息系统，套件，模块，组件，对象，接口，连接，软件和服务。
5. 如何创建技术（服务）路线图
6. 如何创建AS-IS企业架构蓝图
7. 如何设置AS-IS体系结构原理文档/数据库

C）企业架构档案

创建的以下产品都是企业架构档案的一部分：

1. 如何设置EA基准
2. 如何创建AS-IS企业架构框架图？
3. 如何设置术语文档/数据库的词汇表
4. 如何创建AS-IS企业架构（文档）
5. 如何创建AS-IS治理体系结构（文档）
6. 如何创建AS-IS业务架构（文档）
7. 如何创建AS-IS信息架构（文档）
8. 如何创建AS-IS技术架构（文档）
9. 如何创建AS-IS安全体系结构（文档）

通过遵循这些教程，您将涵盖Dragon1开放EA方法中的流程，产品，清单，文档模板和其他实际内容。

阅读

逐步教程的目的是让您对设计架构产品感兴趣。从那里你可以决定跟随一个

训练课程

或者创建一个免费的Dragon1帐户。

如果您对架构设计感兴趣，可能还需要阅读：

• Terms > Architecture Framework Definition
• Software > Enterprise Architecture Tool
• Software > ArchiMate Tool
• Software > BPM Tool
• Examples > Application Landscape Diagram
• Examples > Process Landscape Diagram
• Examples > IT Landscape Diagram
• Examples > IT Infrastructure Enterprise Blueprint

入门

你想自己创建一个架构图吗？可以使用Dragon1 PRO创建这些架构产品。

在我之前的帖子中，我讨论了三个不同的路线图以及它们之间的关系。在这篇文章中，我们将详细介绍能力路线图。能力路线图将能力映射到时间线（duh）。业务能力是做某事的能力。它们是业务架构的常见元素，对战略执行很有用。

能力的例子包括：

• 位置识别——确定最佳位置以建立具有最快投资回报率的实体位置
• 库存优化——最大限度地减少仓库库存的能力
• 功能速度——更快地产生新功能，以更好地满足客户需求。

就像是：

• 提供工作流功能，允许您的客户使用低代码方法定制您的系统

可能看起来像是一种能力，但事实并非如此。它是一个产品功能，即使它在描述中具有功能。

通常，能力被定义为名词。

能力代表降低成本、增加价值或以其他方式推动组织执行战略的活动。这里的关键词是策略。能力需要与战略挂钩。战略是一个完全不同的话题，已经写了很多年了，将来还会继续写。您如何定义战略超出了本文的范围，但出于我们的目的，我们需要制定战略目标。这些是可衡量的目标，表明您执行策略的效果如何。这些能力应该与这些目标直接相关。例如，如果战略增长目标是每年 25 个新的实体店（战略目标），那么平均 60 天来开设新店（可衡量的能力）将支持战略目标。

能力也会随着时间的推移而改变——无论是在规划方面还是在重新评估方面。上面提到的 60 天平均值可能是下一财年的 45 天。这将是一个有计划的变化，它们可能是不同的工作流集来支持每一个。但它们也可能因战略或市场条件的变化而发生变化。也许很明显，由于颠覆性技术，能力不再是战略优势。

能力不是业务流程——业务流程是完成某事的方式以及参与者、系统和任务之间的相互依赖关系以实现这一目标。能力范围更广，更类似于组织技能。能力也不是价值流。价值流分解了为组织创造价值所涉及的步骤。价值流有它们的位置，也是业务架构的重要元素。它们将在以后的文章中讨论。

这些能力是如何发展起来的？它们是通过改进业务流程（例如，减少完成任务的时间）、改进决策制定（通过提高决策所依据的信息质量）、消除任务（通过流程改进）、消除外部依赖性（通过将专业知识引入内部），提高制造或开发吞吐量（通过技术投资或改进）。名单还在继续。这些本质上都是可操作的——战略的战略执行。这是组织战略和执行协调一致的第一步。

制定能力路线图的步骤是：

1. 识别能力。从战略目标中推导出有助于实现目标的能力。它们应该是可衡量的，并尽可能与战略目标挂钩。当然，这假设已定义具有战略目标的战略并与您共享。
2. 对能力进行分类。这是一个可选步骤，但如果您有很多已定义的功能，它会很有帮助。能力可以按大类（制造、运营、供应链）或部门（人力资源、IT、财务、应收账款、采购等）进行分类。就个人而言，我更喜欢按部门定义能力的更精细的方法。我相信，这更具可操作性和可追溯性。但也可以将能力分组为更大的能力集。例如，生产高性能计算机的能力需要设计、组件采购和制造方面的能力。
3. 识别功能的依赖关系。能力可以在一段时间内发生变化。以医疗账单为例。最初的能力可能是为医疗账单提供适当的编码并在 90 天内移交给第三方。未来的能力可能是处理被拒绝的医疗账单付款并在 90 天内返回给第三方。最终的能力可能是以相同或更好的性能在内部进行医疗支付。或者，一些能力可能依赖于其他能力——例如，响应季节性小麦作物产量的能力可能依赖于 IT 部门内商业智能能力的发展。
4. 确定实施时间的长度。这可能是最困难的一步。它需要了解实际掌握该功能所需的努力。它需要与负责变更的团队成员交谈，并了解实施变更所涉及的步骤、依赖关系和风险。
5. 创建路线图。这是基于类别/部门、依赖关系和时间要求的可视化路线图的创建。一般来说，路线图将按照时间线组织，现在代表起点，未来代表正确。
6. 纳入反馈。一旦创建了能力路线图，就需要对其进行验证。特别是，来自技术路线图的反馈至关重要。该技术可能需要更长的时间来实施，这可能会迫使能力路线图发生变化。

Figure 1 — An example layout of a capability roadmap with dependencies.

路线图可以像您想要的那样简单或复杂——最重要的是增加价值。图 1 代表了一个典型的路线图，左侧的类别和箭头表示的功能。能力按类别分组——如上所述，这可以按业务单位、部门或其他有意义的差异化因素进行分组。战略执行中可能存在差距——而且应该存在——来代表资源限制。我喜欢将能力保留为数据点。这使您可以将它们连接到参与者和角色（所有者、执行者、受其影响、应付账款等）、系统（ERP、仓库管理系统）和业务流程（信用检查、履行）。数据是可管理和可查询的。简单地将路线图放在图表中作为一种组织思想的方式具有价值，但它会使数据锁定。

我被问到的一个问题是，路线图应该在未来多远的时间内进行规划。这是一个难题，将取决于组织及其所从事的市场。例如，航空航天等资本密集型行业可能需要比电子商务组织（大多数可能不会超过 2 到 4 年）。

归根结底，业务能力是战略执行的工具。随着时间的推移，它们变得越来越流行，因为它们填补了战略规定的内容以及如何确定如何完成的空白。应根据需要维护和调整能力及其路线图，以反映不断变化的战略，以应对不断变化的业务环境。在本路线图系列的下一篇文章中，我们将深入研究产品路线图。

本文：https://jiagoushi.pro/mapping-future-part-2-capability-roadmaps-defined

产品路线图是我们将在我的 4 部分系列中深入探讨的第二个路线图。如果您尚未阅读它们，请阅读第 1 部分：路线图概述和第 2 部分：能力路线图。顾名思义，产品路线图定义了产品或产品及其功能的预期未来推出。由于我们正在谈论技术，因此我们将假设后者进行讨论。

与我们正在讨论的其他路线图一样，产品路线图随着时间的推移展示了产品的未来。通常，企业架构不会产生产品路线图。通常，这可能是营销或产品管理的功能，或任何这些实体的组合。实际上，它将涉及所有三个方面的输入：EA、产品和营销，因为每个都为路线图提供关键信息。

产品路线图的受众不仅仅是开发人员，它用于提供有关何时创建功能的指导。它被用作一种元认知工具，用于组织产品团队的思想，以及与高管和其他内部利益相关者的沟通媒介。它也可以用于外部利益相关者，但应注意确保外部受众知道这不是合同承诺或对即将发生的事情的硬性定义。许多组织不会在产品发布之前共享产品。苹果因限制对其产品的可见性而臭名昭著，使他们受到许多谣言和猜测的影响。

产品路线图的基本输入，例如战略、当前产品和技术需求以及市场需求，都会影响路线图，应该以批判的眼光进行评估。如果在其中一个影响路线图的变化中发现了变化，则应注意并立即或在其下一次迭代中调整路线图。

您将产品路线图预测到未来多远？与所有优秀的建筑师一样，答案是视情况而定。与功能一样，如果产品具有较长的开发周期或强烈的资本需求（如 CPU），那么它会更长。对于大多数软件产品，您需要 18 到 24 个月，但这实际上取决于您的需求。投影越远，它的价值就越小。换句话说，随着时间的推移，产品路线图的不确定性更大。

Figure 1 — An example of a product roadmap created in Lucid Chart

产品路线图看起来像一个项目计划——它不是。有一些相似之处。两者都有时间线，都可能有依赖关系，并且都可能在垂直轴上有分组。但它们的不同之处在于意图。产品计划更加详细，代表要完成的任务。产品路线图旨在显示功能何时可以推出。请注意，一旦功能完成，它不会自动推出，它只是准备推出。

哦，所以如果功能正在计划中，这不违反敏捷原则吗？并不真地。开发人员不会选择用户故事。有人会这么认为，但不一定。产品路线图并非一成不变。它是根据战略和市场需求确定功能以及何时需要它们。它受到 IT 将基础架构部署到位的能力以及依赖业务合作伙伴提供交付和支持该功能所需的服务或材料的能力的影响。它为开发团队提供指导，但不是强制要求。产品路线图的输入之一是产品的当前状态。这会根据开发人员实际完成的工作向路线图提供反馈。开发人员仍然是自我管理的，但与往常一样，他们需要了解企业想要完成什么，并且路线图为他们提供决策指导。

开发产品路线图的过程并不简单，涉及大量输入和反馈循环。但总的来说是：

1. 确定组织对其产品所遵循的战略。如果您的组织尚未确定战略，请努力确保其确定。首先，它不需要完全充​​实，但它需要提供选择产品功能的基础。
2. 识别特征域。特征宇宙是可以定义的所有可能特征的集合。这并不是说一切都会好起来，也不是说一切都会实施。这可以来自许多不同的来源。市场和客户是最明显的，但它也可以来自审查竞争对手的产品、非竞争对手的产品，以及软件开发人员等内部资源，他们确定了不同数据源之间的协同作用，可用于为客户带来价值.必要时，还将对特征进行分类。类别可以由受众或角色、子系统、地理或其他定义创建。可以定义多个类别，为每个类别生成路线图或具有动态视图。
3. 将功能与策略对齐。这可能是最困难的部分，尤其是在策略没有明确定义的情况下。查看每个功能，看看它在策略中的位置。它提供价值吗？它有助于实现战略目标吗？如果没有，则丢弃该功能——这并不是说该功能不会在以后重新引入，但最初它不会推动组织向前发展。由于合规性或法规或业务合作伙伴的需要，还可能存在强制功能。这些通常具有必须交付的特定日期，因此对于维持您自己或您的业务合作伙伴的运营至关重要。
4. 确定功能的工作量。这是您确定该功能需要多长时间和多少资源的部分。这更像是一种猜测或 SWAG（Scientific Wild-A** Guess），并不意味着 100% 正确，只是一个近似值，以了解这如何适合日程安排。大型功能可能会被分解成更小的块，以便更早地推出部分功能 - 例如，报告功能最初可能会从一些预制报告开始，然后随着时间的推移引入自定义功能。后者将依赖于前者。
5. 识别依赖关系。如步骤 4 所述，当一个特征被分解成更小的特征时，特征之间可能存在依赖关系。但可能还有其他对功能的依赖——例如，提供对某些屏幕的访问或共享数据的功能可能依赖于 OAuth2 和 OpenID。提供特定矩阵视图的功能可能依赖于允许用户在应用程序中创建和编辑特定记录的功能。这些依赖关系将指定至少一些功能的开发或准备推出的顺序。
6. 布局产品路线图。这就是我们将这一切结合在一起的地方。布局和安排优先功能，了解每个功能所需的工作量以及开发功能的时间长度。根据功能的可用性，必须做出一些努力来了解如何设置功能的时间线。一个特性可以被挤压或拉伸到某个点，但这种弹性不一定是线性的（即，在一个特性上投入更多资源并不能保证它会在更短的时间内完成）。依赖映射将确保依赖链中较早的功能首先完成。
7. 冲洗，起泡，重复（Rinse, lather, repeat. ）。好吧，实际上这是一个不断更新或按计划更新或两者兼而有之的问题。产品路线图应该至少每季度更新一次，但在这个瞬息万变的世界中，也许每月一次更合适。每季度进行一次实时调整是一种很好的中间方法。在这种情况下，季度审查将包括更全面的审查，实时调整的范围将受到限制。实时调整将反映来自生产团队、IT 或其他内部服务提供商的反馈循环，以及市场或战略的重大变化。例如，如果您有一个卖方房地产应用程序并且市场转向买方提供更多机会的地方，那么所有这些卖方功能可能会被搁置。制作团队的反馈可能会调整时间表。如果开发人员无法准备好 UI，这将推动功能和任何依赖项的路线图时间表。同样，如果 IT 组织在实施第三方 SaaS 集成时遇到问题，这也可能会延迟某个功能和相关性。如上所述，规划和更新路线图的时间范围取决于您企业的情况。

上面的图 1 提供了使用 LucidChart 开发和修改的产品路线图的表示。 Lucid 的模板有颜色代码作为开发的进展情况（完成、等待、迟到）。我发现这在敏捷世界中相当无用，在这个世界中，迟到并不是什么大事，除了在 sprint 方面——它对于看板来说更不重要。另外，为什么要更新图表以表明它已经晚了，而新的修订版本更好地代表了调整后的计划？我更喜欢用它来定义重要性，因为这为开发团队提供了更大的沟通价值。颜色编码还可用于指示其他关键要素，例如成本、产品领域、领域或团队。

产品路线图既是一份活的文件，也是一份未来计划的快照。因此，出于历史目的，应定期存档。有许多专门用于路线图和产品路线图的工具。质量更好的工具将是数据驱动的，并将更新路线图以反映变化。并非所有更改都可以由数据驱动，很有可能。开发团队的输出等数据可能保存在未集成的不同系统中。战略和市场细节通常也不能用于集成。

总之，产品路线图是一个看似简单的过程，但实际上相当复杂。它涉及许多不同的组织利益相关者，是一个平衡多个关注点的过程。然而，它是推出产品的重要组成部分，有助于调整战略和执行。请继续关注我关于路线图的最后一篇文章——技术路线图——大约一周后会发布。

本文：https://jiagoushi.pro/mapping-future-part-3-product-roadmap

记得回到 90 年代（男孩，我现在正在和自己约会）。口号是 IT 需要与业务保持一致。如今，技术变得如此重要，以至于业务需要与技术保持一致，看起来。在 IT 和业务方面，我从未真正看到过“我们与他们”的现实。但无论你怎么看，它们都需要对齐。这就是路线图的用武之地。

路线图是定义未来方向的过程。您可能听说过产品路线图或技术路线图。也许您甚至听说过能力路线图。但是您如何创建这些路线图，每个路线图做什么以及它们如何协同工作？这就是我们今天要讨论的内容。

在随后的文章中，我将详细讨论不同类型路线图的创建以及它们是如何形成的。正如我所提到的，路线图分为三种类型：

1. 技术路线图。这些在当今的 IT 世界中并不少见。它们在 IT 组织中用于安排在时间范围内提供某些技术所需的工作量。他们通常会提前 24 个月查看并确定技术何时开发、实施和推出。它们用于提供高级别的行军命令、制定预算并为培训和招聘目的确定技能组合需求。通常，它们被开发出来，然后被推入平局或存档在服务器上。
2. 产品路线图。这些在提供软件产品和服务的公司中最为常见，但它们不必仅归入该领域。产品路线图定义了将来可供现有和潜在客户使用的产品和功能。对于商品项目，产品路线图不太重要，可能会延伸到未来。对于短命的产品，例如变化更快的软件，产品路线图很可能在更短的时间内完成。
3. 能力路线图。能力路线图不太常见，但对于战略执行至关重要。它们定义了企业在某些时候需要具备执行战略的能力。什么是能力？它们是在定义的水平上执行的能力。例如，识别具有特定投资回报率的零售店位置的能力或在特定时间范围内完成订单的能力。这些能力会随着时间而变化，应该制定路线图以了解公司的运营需求。

现在我们知道路线图的类型是什么，我们将深入研究谁负责创建它们、它们之间的相互依赖关系、它们具有的外部依赖关系以及它们的使用方式。

路线图通常（但不总是）是企业架构 (EA) 的领域。这来自 EA 在创建技术路线图方面拥有最长的经验。产品管理可能对产品路线图负责，或者他们可能使用架构服务来协助或执行大部分工作。能力本质上更具战略性，可以由首席执行官或 CSO（首席战略官）等 CxO 执行，无论是否有企业架构组的帮助。

我相信企业架构应该参与所有的路线图。这是因为路线图是相互依赖的。至少，EA 将提供反馈，尤其是以会影响能力和产品路线图的调度和预算现实的形式。这种反馈是必不可少的，并证明了 IT 在战略执行中的重要性。能力和产品路线图都依赖于技术路线图。如果预算不能满足实施该技术的需求，或者实施该技术的时间表不切实际，则需要对能力和产品路线图进行更改。

Figure 1 — Interdependencies and dependencies of roadmaps

每个路线图都取决于其先前的迭代。也就是说，路线图应该是活生生的实体，它们是必要的更新，以反映业务和技术环境的不断变化。这并不意味着它们应该每天进行调整，而是按照反映组织需求的时间表进行调整。与在更加稳定的市场中运营的企业相比，处于更加活跃的市场中的企业应该更频繁地调整路线图。之前的路线图代表了愿望。它是根据实际情况调整的。你没有达到能力目标吗？调整它和所有相关的能力以反映现实。是否更改了战略，删除了不相关的功能，添加新功能并修改其他功能以反映新的战略方向。

所有路线图的核心是企业战略。战略是创建所有路线图的镜头，有助于做出创建路线图的决策。战略本身取决于许多其他因素。这包括当前的组织状态，包括当前市场、当前财务状况、当前能力和收购。外部因素也在战略制定中发挥作用，例如 COVID 19 等世界事件、战争、市场状况和技术进步。

另外两个外部依赖项是产品路线图的市场和技术路线图的当前架构状态。市场变化也会影响战略，但在宏观范围内。对于产品路线图，我们正在根据竞争对手的新产品以及我们客户对新功能或产品的需求来研究直接影响产品路线图的变化。这些可能不会改变基本战略，但仍可能需要迅速解决，以确保企业的声誉和市场份额。

当前的架构状态非常重要，并证明了企业架构的重要性。 EA 通常将其保存在存储库（企业架构存储库或 EAR）中。架构的当前状态受到许多因素的影响，包括内部和外部。对于依赖内部软件或硬件开发的组织而言，其中最关键的一项就是架构。糟糕的架构会导致产品死板，不能成为增长的平台。它们可能无法满足不断增长的性能需求，可能无法提高规模效率，或者可能不容易修改以支持新功能。

对当前状态的外部影响包括供应商产品的变化。也许一个供应商与另一个供应商合并或倒闭，改变他们的产品战略或将他们的许可费用提高到一个令人不快的水平。也许出现了一种新产品，以更低的价格带来了额外的好处。这两种情况都可能导致 IT 环境的当前状态发生变化。巨大的辞职也带来了重大变化，人员配备的不确定性（以及由此产生的时间表的不确定性）以及对远程工作和在不同地点工作的人才的需求和期望的变化。有时，新的概念和技术会颠覆计划。大规模的破坏者，例如迁移到云、微服务架构和 NoSQL 数据库，可以影响内部架构，开辟新的可能性和能力。

最后，我想指出，能力也可以在其他层次上使用。 正如我在上面列出的那样，它们是在企业级别定义的。 对于大型企业，也可以根据组织结构在部门级别进行定义。 在部门层面也是如此，以帮助确定在哪里投资以提高部门的能力。 例如，IT 部门可以将其提供商业智能服务、云解决方案、可扩展性或快速生产功能的能力视为能力，并根据技术路线图加强其在必要领域的执行能力。

本文：https://jiagoushi.pro/mapping-future-using-capability-product-and-techn…

许多企业声称，开放组架构框架 (TOGAF) 是一种瀑布模型，无法满足他们对现代企业架构的期望。相反，他们采用规模化敏捷框架 (SAFe) 方法来设计他们的企业。¹

需要注意的是，企业架构的三大支柱是：一致性、洞察力和质量。

• 一致性：企业架构 (EA) 将战略与运营、业务需求与 IT 供应保持一致，并确保变更符合企业战略和目标。
• 洞察力：EA 提供对组织、信息系统和技术的当前和期望状态的洞察力。
• 质量：EA 有助于提高单个解决方案的质量并简化其开发和维护。

作为背景，每一个都用于解决企业今天面临的最大挑战，例如：

• 变得敏捷
• 全球化和数字化
• 系统复杂性增加
• 产品型开发
• 市场竞争

 

采用 EA 的陷阱

根据作者最近作为企业架构师的经验，以下内容通常与企业架构的采用有关：

• 组织专注于 EA 的技术方面，因为大多数 EA 计划都是由 CIO 或 IT 主管推动的。
• 企业架构团队花费更多时间选择 EA 框架和 EA 工具，而不是定制和使用它来开发企业架构。
• 企业架构师经常被拖入运营活动或日常项目工作中。这意味着虽然他们看起来很有生产力，但实际上他们在解决企业层面的组织问题方面几乎没有做任何事情。

然而，跨行业对企业架构师的看法正在发生变化。为了赢得组织的尊重，企业架构师应该在编码的同时参与制定战略和端到端的实施。今天的企业架构师现在需要与定义企业的业务战略密切合作。此外，企业架构师监督如何以实施的形式实现业务战略。

 

基于以上问题，定义企业架构需要敏捷最佳实践。以下部分展示了敏捷方法与企业架构之间的联系。还详细解释了企业架构师在敏捷开发中的作用。

敏捷企业架构

敏捷是一种用于软件开发和项目管理的方法。在敏捷方法中，单个项目被分解成更小、更易于管理的部分，以加快设计过程并尽快生产出高质量的产品。

 

敏捷 EA 框架

使用敏捷，企业架构师的重点是：

• 通过早期和持续交付有价值的软件使客户满意；
• 接受需求（无论处于开发阶段）；
• 交付频繁工作的软件，从几周到几个月不等（越短越好……）；
• 在整个项目中与业务部门和软件开发人员保持持续的日常协作；
• 制定向开发团队和在开发团队内部传达信息的有效方法（通常通过面对面的会议）；
• 衡量工作软件的持续开发进度；和
• 持续关注卓越的技术和良好的设计。

下面描述的敏捷 EA 框架 (AEAF) 的安排是为了打破 IT 和业务之间的障碍，从而通过单位和通过为新项目联合的快速形成的团队来提高协同定位的水平。它的功能是根据实时客户反馈发展和迭代改进最小可行产品 (MVP)。 AEAF 同样通过实施必要的架构来支持云、DevOps、微服务、数据分析、测试自动化和 API 来帮助企业数字化。

AEAF 通过使用迭代生命周期来定义架构，以允许架构设计随着各种问题和约束变得更加清晰而逐渐演变。体系结构和系统的逐步构建必须齐头并进，其后续迭代必须解决或实施任何和所有问题和决策，以促进真正灵活的体系结构。

AEAF 以下列方式涵盖每个活动、目的和相关架构关系的详细信息：

(a) 敏捷 EA 规划

此步骤涵盖架构愿景和所有前期架构规划。在这个阶段，目标是解决核心业务问题和利益相关者的担忧。

架构愿景期间的努力提供了进行进一步目标架构开发所需的文档。它涵盖了问题的整个范围，同时也解决了利益相关者的担忧、优先事项和偏好。

架构待办事项涵盖了产品的价值、复杂性、依赖性和紧迫性。

(b) 敏捷架构定义

此步骤涵盖了与业务、应用程序、数据和技术相关的领域架构的定义。它建立了一组利益相关者批准的域架构，其中包含一致同意的差距列表以及清除它们的相应方法。它还解决了使企业能够满足利益相关者偏好的变化。作为敏捷架构定义的一部分，迭代计划将通过每日“站立”会议和“燃尽/燃尽”图表进行。

在此规划期间，每日站立会议和自组织团队共同开发架构。

 

(c) 敏捷 EA 分类法

敏捷 EA 分类涵盖了要在整个企业中采用的敏捷架构原则和敏捷价值观等工件。它还涵盖了最佳实践、指南和清单，以帮助那些遵守敏捷架构领域工件的人。

Sprint 交付工作产品的有用部分。 EA backlog 的核心是适当限制的 EA Landscape。

工作软件清楚地表达了预期的结果，而无需详细讨论如何开发和执行某些东西。它将工作限制在相对较短的时间间隔内，以最大限度地减少正在进行的工作量。此外，它还标识了所有的前任和后继包。工作产品可​​以追溯到一个目标，因此如果它的交付延迟（或失败），企业将面临改变目标架构的后果。

 

(d) 执行

敏捷团队不是采用大爆炸式的方法来决定整个程序的架构需求，而是采用增量方法来确保设计可扩展并与愿景保持一致，同时详细说明和满足企业需求。为了最有效，它有助于架构团队继续着眼于更大的图景，而团队则专注于他们基于冲刺的可交付成果。所有决策都应该一起做出以确保适当的平衡——无论是从商业价值的角度对项目阶段的协议、接受新的技术债务，还是特定框架或组件的设计细节。

作为敏捷架构实施的企业架构师，应重点关注：

• 有意架构（架构即协作）；
• 构建可能可行的最简单架构（既定设计原则）；
• 对其进行编码或建模（尖峰、原型、域和用例模型）；
• 构建它，测试它（为可测试性而设计）；和
• 实施架构流程（架构史诗和投资组合看板）。

(e) 敏捷 EA 组织

EA 实践需要相应的敏捷环境才能蓬勃发展。架构团队必须由企业架构师和解决方案架构师组成，业务架构团队必须将企业架构师与业务专家相匹配。 EA 团队需要每天与敏捷团队密切合作，以确保成功执行愿景，同时整合团队和客户的挑战和反馈。

• 敏捷首席架构师：敏捷首席架构师在整个企业中推广敏捷方法。这个职位的作用各不相同，就像仆人、领导者和促进者一样，可以顺利执行并消除可能的障碍。敏捷首席架构师是组织企业架构计划的最佳产品所有者。作为产品所有者，ALA 确定组织所需的架构。 ALA 拥有 EA 开发冲刺中使用的验收标准。
• 企业架构师：企业架构师是敏捷团队的组成部分，有助于开发、改进和维持企业架构。敏捷架构师是开发团队的活跃成员。他们在适当的地方开发软件，并担任团队的架构顾问。
• 敏捷团队：服务很小，由小团队开发。敏捷使得以小块频繁发布成为可能，从而显示业务进展。遵循 CI/CD 以提高弹性水平。

使用 LeanIX 实施 TOGAF 的敏捷框架 [海报]：逐步说明如何使用精益 EA 工具遵循 TOGAF 原则。 »

(f) EA 存储库

EA 存储库有助于存储敏捷架构和开发工件。

 

(g) 敏捷 EA 治理模型

敏捷 EA 治理就是在整个组织内创造价值，而不仅仅是在单个项目中。敏捷治理在高层管理人员和正在完成项目的团队之间架起了一座桥梁。

已建立的敏捷 EA 治理模型支持：

• 敏捷团队的自主决策；
• 跨学科敏捷团队处理复杂主题的能力；
• 减少企业架构的管理开销；和
• 企业架构的范围和影响。

概括

不要将所有这些都视为 EA 与敏捷。

敏捷 EA 框架对于任何企业转型都起着重要作用。这种转变有四个维度：功能性；技术的;操作;和业务。在这四个维度中的每一个维度中，EA 和敏捷都支持对方的目标。

在敏捷中，架构师需要始终与团队保持投资。重要的是他们要有远见，同时管理变化和复杂性。敏捷架构师必须参与项目所有功能规范的定义，同时与业务团队共同审查功能规范以了解期望并确保所写的内容是预期的。

不断与利益相关者和团队核对，以确保他们没有偏离既定的设计。架构师必须在很多时候保护团队免受不必要的官僚主义的影响。

产品负责人、敏捷架构师和团队应共同决定 sprint 的范围。架构师应仅在范围界定期间出现问题（或在最后一刻引入更改时）进行干预。

向业务部门演示冲刺输出以获取客户反馈，适应所有必要的更改，并确保团队由经验丰富的工程师和新晋工程师组成。最后，虽然敏捷并未明确推荐文档，但它确实有助于创建尽可能多的文档，以简化未来支持团队的生活。

原文：https://www.leanix.net/en/blog/agile-and-enterprise-architecture-a-stra…

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

什么是Architecture Repository应用程序？

Architecture Repository是Dragon1应用程序，可用于记录所有企业体系结构数据。 它是数据和企业所有元素的完美存储和管理。 这是您的架构CMDB工具。

使用体系结构存储库，您可以为所有数据构建单一的事实来源。 这提高了工作效率，因为人们可以更快地找到他们正在寻找的正确版本的数据。

Screenshot of Architecture Repository showing a list of Business Capabilities

 

您可以输入实体数据并将它们组合到列表中，称为目录，然后管理和调节这些目录。 您可以在上面看到一个业务功能列表，这些功能可以转换为目录，然后在模型，视图和可视化中反复使用。

输入丰富的数据

体系结构存储库应用程序支持您输入丰富的数据。 不仅可以输入数据项的名称，描述，类型和标题。 您可以定义自己喜欢的属性。 您甚至可以定义新的实体类和实体类型。

 

Screenshot of Architecture Repository showing a Business Capability from a list (catalog)

您可以在上方看到所选的业务功能。 您可以使用数据类型和值范围添加任意数量的属性。

数据的导入和导出

为了提高您的工作效率，Dragon1为您提供了非常灵活的导入和导出功能。

可以导入（智能）任何.dragon1文件，.d1文件，.doc文件，.ppt文件，.vsd文件，.xls文件，.txt文件，.csv文件，xml文件或公共打开格式文件。

Screenshot of Architecture Repository showing the quikckand easy Import Dialog for CSV files.

 

假设您想要或需要从您的帐户导出部分或全部数据，您可以选择以任何常见和开放格式导出它，如.dragon1，.d1，.pdf，.xml，.txt和.csv

数据存储的自由结构

Architecture Repository为您提供了一个可以存储数据项的自由灵活的逻辑结构。有三种结构元素：机柜，档案和文件夹。

橱柜是最高的结构元素。一个柜子包含一个或多个档案。档案包含一个或多个文件夹。您可以在一个帐户中创建任意数量的文件柜，档案和文件夹。您可以将多少数据项存储在您喜欢的文件夹中。

400多个数据实体类供选择

Dragon1有400多个实体类，您可以立即输入数据。以下是您可以输入数据的实体类的列表。

关于企业架构，您可以存储数据项的最重要的实体类是：架构，结构，企业，业务，功能，功能，流程，产品，服务，应用程序，需求，需求，利益相关者，所有者/客户，概念，元素，组件，对象，构建基块，原则，模式，视图，观点，规则和设计。还有很多很多。

支持的语言

这些广泛的预定义实体类确保您可以使用Dragon1上的任何框架，方法，方法，语言或标准。

Dragon1支持以下语言的文档数据：

• ArchiMate（第四次认证的ArchiMate工具）
• BPMN
• UML
• Dragon1 Enteprise架构建模语言（EAML）

下面你可以看到我们拥有的实体类的常见形状或符号（来自Dragon1 EAML）。体系结构存储库还支持仅使用ArchiMare，BPMN或UML形状。

Screenshot of the most important data entity classes (1)

Screenshot of the most important data entity classes (2)

数据库和基于角色的访问控制

用户在Dragon1上输入的所有数据都存储在我们的安全数据中心的数据库中。 Dragon1上的每个帐户都有自己的数据库实例。帐户数据是混合的，但是分开存储。这称为多租户数据库。

在Dragon1上，每个用户登录都连接到一个帐户，一个帐户可以有许多用户登录。这意味着您作为个人或团队可以在一个存储库上一起工作并共享数据。对数据的访问由机柜，档案，文件夹或数据项的创建者控制。并且帐户的管理员登录控制谁拥有一组操作的权限。

元元建模

体系结构存储库使您可以在数据项之间创建关系。通过这样做，您可以创建模型。

通过体系结构存储库，您可以创建元模型，用户模型和实例模式。例如，元模型可以存在实体类，如“进程”和“应用程序”，以及每个进程必须由至少一个应用程序支持的规则。用户模型可以存在实体类型，如“销售流程”和“采购流程”，以及支持这两个流程的“CRM应用程序”。您可以选择此用户模型是否必须符合元模型。实例模型可以存在于进程和应用程序的实例之外。也许该组织有五个执行销售流程的地点，可能还有10个CRM系统的安装。

Architecture Repository的屏幕截图

文件夹列表视图

Create Links

 

典型应用景观数据

示例生成的企业架构档案

Dragon1为您提供EA档案标准。 默认情况下，Architecture Repository以“My Cabinet”打开，其中包含作为EA Dossier标准一部分的所有文件夹和空文件。 这可以节省大量的时间和资源，并防止重新发明轮子。 当然，您可以重命名机柜，档案，编辑和删除以及创建文件夹和文件。

 

 

通过移动、云、物联网和大数据改造企业

这本书的目的就在于这篇文章。第一章可以在这个链接上找到。

第2章：重新定义企业架构师的角色和职责

介绍

本描述性章节重新定义了企业架构师在现代化和转型环境中的重要角色、职责和责任。

不幸的是，这些架构师的传统角色和职责不适合这些复杂程序的需求。

因此，后续章节中提供的15分不是工作角色、职位头衔或一般职责。

相反，这些要点帮助招聘人员和人力资源专家认识到企业架构师的关键作用，特别是在企业现代化方面。

对于有抱负的企业架构师来说，了解这些技能对于规划他们的工作角色发展很有价值。

在本章中，上下文至关重要。我们并不专注于创建全新的企业架构。

相反，我们正在努力使现有的企业架构现代化，以满足不断增长的消费者需求，创造新的业务见解，并创造新的商业机会和潜在的收入流。

以下各节介绍企业架构师的日常活动和互动，以增强现代化计划和相关技术解决方案的能力，从而实现战略成功。

1-架构和设计责任

应用严格的企业架构方法对于现代化计划至关重要，包括人工智能、物联网、移动性和大数据分析等多种新兴技术。

如果企业架构过程在现代化计划中出错，那么其他一切都会出错。

其他架构类型，如解决方案、系统、基础设施、集成和其他架构领域，取决于企业架构过程的质量。

除架构外，现代化生命周期中的后续设计活动也受到不利影响。

在支持现代化战略的经过验证、以业务为中心和实用的架构之后，高级和详细的设计活动是现代化生命周期中需要仔细考虑的以下重要方面。

因此，企业架构师也在企业级扮演设计权威的角色。

然而，这并不意味着企业架构师执行设计活动。他们无法承担大量设计活动的责任。

例如，对于各种组件，可能存在多个架构师和解决方案设计。企业架构师的角色是使用业务组织中的设计权限结构来监督设计。

设计权威由多个在不同领域具有不同专业知识的架构师组成。

企业架构师就像交响乐团的领导者。同样，他们利用对战略、架构、技术问题和业务问题的广泛知识和理解来协调活动。

他们通过使用组织技能以及深厚的架构技能和商业头脑来管理设计权威。

企业架构师必须具备战略、架构思维和设计思维技能。

此外，他们还需要向发起业务的主管阐明当前的企业环境，并设定未来的企业环境目标。

最后，他们需要展示如何弥合这两个环境之间的现代化目标差距。

企业架构师必须在较高的层次上理解企业的整体现代化范围、需求和现代化解决方案的用例。此外，企业架构师需要进行可行性评估。

这些评估对于现代化项目的成功至关重要。因此，他们必须定期评估风险、问题、依赖性和约束，考虑日常优势、劣势、机会和威胁。

2-灵活的治理支持

企业架构师负责架构和技术治理。企业现代化计划需要特定的治理模式。灵活的治理模式是必要的。

传统的、严格的、极其基于规则的、压迫性的治理模式可能成为进步的障碍。敏捷原则最适合动态治理模型。

企业架构师通常在重要的现代化项目中扮演技术治理负责人的角色。

此外，他们可以承担正式的治理角色。例如，这些架构师可以运行架构审查委员会。他们还可以领导为复杂程序建立的设计权威论坛。

行业中技术治理的通用框架之一是COBIT（信息和相关技术的控制目标）。

该框架可以通过平衡收益、优化风险水平和改进资源使用，帮助组织从技术投资中获得最佳价值。

然而，其他治理模型可以基于企业所属和所坚持的行业。

3-技术卓越

执行现代化项目的企业架构师必须具有涵盖各种技术领域的独特技术专长。此外，他们必须在技术上杰出。

技术卓越是指杰出的技术专长。它们得到组织内部和外部的认可。这些技术领袖在技术和商业界都有影响力。

企业架构师的专业深度和技术优势需要技术和架构领域的专业知识。他们还需要更广泛地理解相关领域。

强大的行业技能对企业架构师至关重要。他们在多个领域展示了思想领导力。因此，他们因其想法和对商业组织活力的贡献而受到高度重视和追捧。

领导企业实现现代化需要多个技术领域中的独特因素，包括广泛和深入的理解。因此，技术卓越和专业卓越是为现代化项目招聘企业架构师的先决条件。

4-技术和业务沟通

企业架构师需要同时使用业务和技术语言。他们必须在所有部门和业务线之间传达业务愿景、战略、组织价值观、战术、项目计划和业务目标。

此外，他们需要沟通架构战略、目标和目标，以提高整个企业的意识。

出色的沟通技能对企业架构师至关重要。他们的沟通技巧受到同行、经理和客户的尊重。

他们可以自信地在各个层面进行沟通。他们可以向所有利益相关者阐明最复杂的情况和技术事项。他们还可以根据业务组织中的受众配置文件自定义消息。

企业架构师需要鼓励他们的团队成员进行清晰有效的沟通，以便在架构团队或直接团队之外共享他们的知识。

他们被期望成为导师和教练，因为他们可以观察团队成员的行为，并就他们的沟通能力提供建设性的反馈。

企业架构师必须特别清楚地使用正确的术语和引用，向技术人员详细、简洁地向业务涉众阐明复杂的技术问题和工具。

5-促进变革

在企业现代化计划中，变革是不可避免的。一切都在迅速变化。因此，变革领导和促进是至关重要的职能。

然而，应对快速变化并非易事，需要软硬技能、丰富经验和深刻见解。

企业架构师可以成为同行和下属的榜样，从而成为持久变革的催化剂。通过促进变革，他们可以将文化更新为敏捷、协作和创新的环境。

他们的专业属性，如对变化做出反应，以敏捷的方式相互分享和学习，以及在友好的团队环境中享受快乐，可以对提升和积极变化的文化产生重大影响。

6-创新管理

企业架构师必须是组织中传播创新的创新者和催化剂。人们期望他们具有创造性和创造性。

这些架构师可以组合、比较和对比事物，为业务创建新的含义、理解、用例和价值主张。

他们需要用新的眼光看待事物。这些架构师必须从旧的概念、术语和想法中创造新的价值。他们必须从多个角度看待事物。

这种创造性思维是实现复杂企业现代化目标的基本要求。

企业架构师必须理解创新对组织各级的价值。它们需要成为采用创新的催化剂。这些架构师有望创造创新文化，并将其嵌入组织的生态系统。

7-专业支持

指导和辅导是现代化环境的核心文化要求。必须有自上而下的培养和知识转移。

为此，企业架构师可以成为团队成员、其他团队成员和合作组织人员的导师。他们可以慷慨地分享他们的知识，并将其转让给任何需要的人。

这些架构师可以通过积极听取同事、下属和其他团队成员的意见来指导他们。不幸的是，下属团队成员很容易被这些复杂程序中的快速变化所淹没。

根据我的观察，一些杰出的企业架构师是出色的听众。他们非常优秀，甚至可以为团队成员的福祉做出贡献，为压力大的同事提供辅导课程，从而产生治疗效果。

这些都是备受尊敬和追捧的领导者，他们进行了根本性的文化变革，以满足大型商业组织的需求。

企业架构师可以为技术知识不丰富、难以满足复杂计划需求的经理和高管提供技术指导。

他们的指导和辅导能力可以帮助非技术团队成员在企业中发挥更好的作用。

他们可以在一对一的基础上对这些非技术团队成员进行指导，必要时可以分组进行。指导和辅导可以是企业现代化计划中的一项持续活动。

8-独特的学习方法

在传统企业的现代化过程中，学习是一个永无休止的过程。由于技术堆栈、流程、技术和工具的快速变化，企业架构师必须快速学习。

他们可以有不同的学习风格。根据条件，他们可以正式或非正式地学习。他们可以将非正式互动转化为潜在的学习机会。

企业架构师可以为团队成员创造学习机会。他们可以根据需要教育其他人。

通过教团队成员，他们学到了更多。这种新的学习和教学方法对于满足企业现代化目标的教育需求至关重要。

9-支持人才

企业现代化解决方案包括人才。因此，企业架构师必须理解人才对现代化项目的价值和重要性。

没有人才，这些项目就无法取得有效进展。

企业架构师必须非常谨慎地将人才保留在高绩效团队中。他们可以有意识地努力在部队中保留有价值的人才。

人才是现代化企业核心产品和服务的关键推动者，这一点再怎么强调也不为过。

没有人才，企业组织就无法保持竞争力。我们知道，为了确保这些稀缺的资源，该行业不断地寻找人才是显而易见的。

企业架构师可以执行人才管理和促进角色。他们可以鼓励年轻团队成员更好地服务，并逐渐将他们转变为有才华的团队成员。这些架构师可以识别团队中的低绩效。

在需要时，他们将以更有能力和资格的团队成员取代他们，他们能够坚定地为组织的愿景和使命做出贡献。

10-建立高绩效团队

企业现代化计划需要能够不断执行和生产的团队成员。期望这些团队成员在任何时候都能以最佳的表现满足业务需求。

此外，必须测试和验证他们的技能和能力，以适合他们正在执行的工作类型。

建立高绩效团队对于这些项目的成功至关重要。因此，企业架构师需要创建协作和高性能的团队来设计和运营成功的项目。

这些经验丰富的架构师需要创建参与的技术团队和实践社区，作为回馈活动。这些高绩效团队和协作实践社区可以一起使用敏捷方法生成创新解决方案。

11-检测盲点

我们都有盲点。这是不可避免的。然而，如果未识别盲点，则可能是危险的。我们需要有经验的人的支持来找出我们的盲点。

我们的习惯和思维模式可能会导致盲点。例如，关注细节而不注意全局可能会导致思维混乱，并导致危险的盲点。

企业架构师是敏锐的观察者。他们可以从多个角度寻找大图片。他们可以在需要时深入研究问题。因此，他们可以快速识别盲点、故障和不稳定性。

这些架构师可以通过积极的反馈、澄清示例和使用伟大的隐喻来表达条件。这种表达方法可以帮助人们看到他们的盲点，理解他们的缺陷，并将其转化为优势。

此外，隐藏的议程和隐藏的成本是这些变革起源中的盲点类型。因此，企业架构师也需要处理这些复杂的情况。

12-衡量进展

采取必要的进步措施对于企业现代化计划的成功至关重要。企业架构师可以关注定性和定量的进度度量。

这些架构师可以管理复杂的矩阵结构。使用面向度量的方法，企业架构师可以使用关键性能指标。他们使用仪表板来观察趋势，从而以可视化格式对进展进行定性和量化。

企业架构师必须鼓励团队成员创建他们的仪表板，并利用共享仪表板来监控进度。

他们可以将他们的单位转变为一个数据驱动的机构，以结构化、有条不紊和主动协作的方式衡量目标。

取得进展的关键措施之一是客户支持机制。这些架构师确保提供以客户为中心的前景，专注于通过可测量的分数不断改善客户体验。

13-思想和想法领导力

企业架构师是组织中的思想和想法领导者。思想领导力是改变文化和改变生态系统的关键要求。

这些建筑师可以数字化思考。这是一种传统文献中不存在的新型思维。因此，数字转型计划中出现了文化转变。

我们现在使用数字思考者和数字思想领袖这一术语。在过去，我们通常称这些类型的人为技术头脑的领导者。这方面的关键点是通过观察数字趋势并迅速将其应用到组织中，成为一个榜样。

企业架构师可以在个人和组织层面推动普遍的数字化转型。由于现在许多企业组织都在进行现代化项目，因此领导这些业务的企业架构师必须进行数字化思考。他们必须是数字倡议前沿的数字思想领袖。

14-成果重点

有形成果是企业现代化举措成功的主要重点。这些程序需要迭代的结果，而不是统一的结果。F

例如，一些实际效果可以是虚拟化平台、创建虚拟容器、生成可重用和共享资源、审查产品和验证商定的服务。

企业架构师必须特别注意在各个团队成员的支持下提供切实的结果。现代化的环境呈现出快速变化，任何变化都会产生切实的结果。

这些快速变化可以在现代化的后期阶段带来更显著的实际成果。例如，系统可能需要松散耦合、软件定义、完全自动化、面向服务、自学习、自管理和自恢复是本文中要提到的几点。

15-商业头脑

业务理解对企业架构师至关重要。他们不仅必须理解业务细节，还必须来自深厚的技术背景。

来自技术背景的企业架构师与来自技术知识、技能和经验有限的管理背景的同行有很大的不同。

虽然这两种类型的架构师对业务都很有价值，但从创新、敏捷性、协作和技术卓越的角度来看，其微妙之处可能有所不同。

我的观察表明，企业架构师从广泛的技术背景中挑选出来，具有出色的业务和人际关系技能，在这些复杂的环境中可以更高效地工作。

我注意到，来自坚实技术背景的架构师非常动手，在决策过程中听起来更加自信和权威。

我们知道，并非每个技术人员都能成为一名称职的企业架构师。因此，招聘人员需要探索使技术人员成为优秀企业架构师的属性。

感谢您阅读本章。

我希望你觉得它很有价值。我很乐意在评论部分回答您的问题。

本文：https://medium.com/technology-hits/a-modern-enterprise-architecture-app…

 为什么企业架构师必须与道德黑客密切合作？

网络犯罪率大幅上升，网络安全措施需要修改。安全性需要嵌入系统开发生命周期的所有级别，包括概念性的…

利用移动性、云、物联网和大数据实现企业转型

第 1 章：企业架构基础

介绍

本章涵盖了企业架构的基础知识。

在任何商业冒险中，必须首先满足基本面，以便进一步取得进展。出于这个原因，我从现代化背景下企业架构的定义开始，介绍了处理企业复杂性的基本技术。

在连续的章节中，作为另一个基本方面，我谈到了企业架构师在领导成功的现代化计划中不断变化的重要角色和责任。

最后，在设置了这些基础之后，我强调了这个独特框架中的其他必要支柱。

企业架构的定义

信息技术 (IT) 中的企业架构 (EA) 学科定义了企业级别的宏观 IT 架构。它侧重于使用治理方法将 IT 功能映射到业务需求。

传统上，企业思想领袖引入城市规划隐喻来定义和可视化 EA。到目前为止，这个城市规划比喻是提供对 EA 的共同理解的最引人注目的解释。因此，在本书中，我时不时地用这个比喻来传达信息并阐明抽象点。

EA 的重点是定义和描述企业中的关系、逻辑流程、业务流程、活动、功能、数据、信息、应用程序、底层技术和支持工具的实现。

愿景、流程和计划是 EA 的基本方面。这三个方面——愿景、流程和规划——是由企业级的业务需求、能力和要求驱动并与之紧密结合的。

EA 有五个不同的阶段。按照成熟度的顺序，这些阶段是初始阶段、基线阶段、目标阶段、集成阶段和优化阶段。因此，企业现代化计划必须考虑这些阶段，并以单独和综合的方式处理它们。

EA 有几个参考模型来解释其基本领域。最常见的模型是：

• BRM（业务参考模型），
• CRM（组件参考模型），
• TRM（技术参考模型），
• DRM（数据参考模型），
• PRM（性能参考模型）。

这些模型涵盖业务能力、功能、技术标准、IT 系统、数据描述和质量测量。这些模型已经很成熟了。例如，最常见的 EA 方法之一，FEA（联邦企业架构）使用这些模型。

有许多用于企业架构的传统方法。流行的是 TOGAF、Zachman 和 FEA。

此外，一些大型组织有其既定的专有方法，这些方法用于内部目的，不公开共享。

但是，通过学习已建立的方法并广泛理解企业架构原则，企业架构师可以快速学习其他专有技术。他们可以在相对较短的时间内审查它们并使用实际的工作产品。

管理企业复杂性

企业环境可能非常复杂，涵盖多层系统、技术、工具和流程。因此，企业架构师的关键角色之一是管理复杂性。我们可以使用不同的方法和技术来管理企业的复杂性。

一种常见的简化技术是分区方法。一些企业架构师可能会使用不同的术语进行分区，例如划分、细分、分离和分配。

这些术语的意思都是一样的。划分的过程是指使一个重要点的较小部分。例如，在处理网络系统时，首先，我们将整个网络划分为更小的组，例如广域网或局域网。接下来，我们可以从路由器、交换机等设备等工具的角度来划分广域网。

一旦我们划分了一个主要系统，我们就可以开始简化。简化是一种扩展技术。我们可以为不同的场景和活动定制化简过程。

简化系统的一种有效方法是减少其数量。以服务器的数量为例。与十台服务器相比，查看一千台服务器可以产生巨大的差异。

另一种技术可以是从一大群集群项目中移动一个项目，但仍然保持关系以保持其核心身份。本书有一章介绍了简化对于企业现代化的重要性，因为它是一个关键因素。

在划分和简化之后，第三个关键方法是迭代。迭代以较小的步骤和块进行活动。迭代是处理复杂性和不确定性的最佳方法之一。

通过迭代步骤，我们取得了特定的结果。如果效果是积极的，我们就会取得进展并进入下一次迭代。如果影响是负面的，我们会失败但学会不这样做并尝试另一个迭代。

这种负面结果的积极方面是我们以便宜且迅速的方式失败。从财务和项目进度的角度来看，廉价而迅速地失败并没有太大的不同。我的意思是我们不会消耗很多预算。

由于迭代在企业现代化中至关重要，本书提供了一章介绍成功的现代化计划的敏捷方法和途径。

简而言之，我们可以通过日常示例记住这三种基本方法。我们有不同的团队负责不同的工作职能。这就是分组的划分。我们属于一个国家。这是一个简化。我们逐章计划学校或认证考试。这是迭代。

我们还为这些技术使用了不同的工具。在本书的各个章节中，我们将介绍它们。

企业解决方案成本

企业转型中的一切都会产生高昂的成本。我们称它们为已知和隐性成本。处理已知成本会更舒服。然而，挑战在于处理隐性成本。

隐性成本类似于冰山中更重要的部分。即使财务团队管理成本，企业架构师也需要找到降低企业现代化解决方案成本的方法。我们需要在不影响质量的情况下逐步降低价格。质量考虑是企业现代化计划的关键要素。

人们认为，在不影响质量的情况下使解决方案具有成本效益是不可能的，因为在架构开发阶段要进行许多权衡。当然，要实现这一目标，需要考虑许多挑战和因素。

但是，可以通过使用系统方法进行权衡来降低解决方案成本。我们可以从业务和技术部门获得协作输入。我们也可以使用敏捷过程。通过应用专业的勤奋、架构严谨性、交付敏捷性和智能协作，可以提高解决方案的质量。这些方法对于保持和提高质量至关重要。

有趣的是，企业架构师需要参与成本模型开发。例如，一旦他们制定了解决方案策略并完成了所有高级设计工件，他们就可以制定解决方案的物料清单 (BOM)。

需要注意的是，项目经理和采购人员可能会对生成前期 BOM 施加巨大压力。但是，我们可以指出，没有经过批准的架构，任何 BOM 都不能正式化。企业架构师的这种自信和直率的投入可以为项目节省大量资金并节省紧张的预算。

一般基础设施和维护成本与大型数据中心、服务器场、移动 BI、大数据和云基础设施相关。但是，从成本的角度来看，这些基础架构组件可以使企业解决方案更加可行。

了解为消费者服务的设备或一组设备中的单个故障或缺陷可能会影响服务水平并导致服务提供商的高成本是至关重要的。

系统的可用性和性能对于惩罚性服务水平起着重要作用。自动化 SLA（服务水平协议）可以识别低可用性和低性能。这些自动化的 SLA 触发规则并迫使违反协议的组织支付合同约定的罚款。

停机时间是产生过多罚款的最关键因素。系统关闭的时间越长，惩罚就越高。因此，根据商定的费率，服务停机成本可能非常高，并且当组织因服务级别违规而累积时会导致过度处罚。

服务级别违规会对组织的产品和服务产生战略性不利影响。例如，服务中断或产品缺陷会导致客户满意度下降。如果我们也从消费者的角度来看，他们会因为服务停机而失去业务。即使消费者组织得到了服务提供商支付的 SLA 罚金，这也是一种不受欢迎的情况。

企业架构师需要关注早期现代化解决方案生命周期阶段的 SLA。解决方案的质量越高，当解决方案投入生产和运行状态时，SLA 就越容易满足。每个阶段对质量的严格要求可以对降低 SLA 风险做出积极贡献。

解决 SLA 问题的一些关键考虑因素可能是自主状态监测和远程维护。关于这些技术有独特的解决方案。聘请自动化专家在我们的现代化解决方案中设计这些功能会很有帮助。

服务水平管理在企业现代化计划中也很重要。业务主管普遍担心的问题之一是性能和可用性问题可能会损害其组织的客户满意度并损害业务收入。为了减轻与这种业务恐惧相关的风险，企业架构师需要尽早以集成的方式特别关注 SLA 战略、规划、设计和实施。

企业现代化方法

企业现代化是企业从混乱走向和谐的漫长征程。该流程包括企业的各个方面。在本书的范围内，我将重点放在企业 IT 系统上。

尽管企业 IT 系统看起来像是总体企业中的一个组织的一小部分，但这个领域本身可能是巨大的，尤其是对于大型企业组织而言。

企业 IT 系统包括业务 IT 流程、业务数据、业务应用程序、IT 基础设施和 IT 服务交付。加上多个国家等地理因素，这些域甚至会变得更加复杂。然而，这些主要领域可以并行迭代地进行现代化改造。

自上而下和自下而上的方法都可以应用于现代化计划。例如，在顶层业务、IT 流程和底层 IT 基础设施中。

这两个领域可以使用并行活动独立地进行现代化改造。但是，集成方法至关重要，因为从多个角度总是存在依赖关系和相互依赖关系。

一旦业务和架构团队制定了现代化战略，企业架构师就会对其进行改进并将其转换为新结构。战略文件是将所有各方和利益相关者放在同一页面上的关键工件。然后，企业架构师根据短期、中期和长期考虑确定这些领域之间必要的依赖关系。

使用该策略并考虑依赖关系，企业架构师制定了一个高级路线图来通知发起人的高管。该路线图可以指示整体现代化的主要成果、时间表和估计成本。这些迹象可能非常高，因为可能有许多因素会影响项目时间表和成本。

一旦确定了企业现代化的路线图，企业架构师需要考虑范围内计划的当前状态、指示性未来状态以及达到最终状态的策略，进行全面的可行性评估。

这种可行性评估必须包括关键风险、假设、约束和依赖关系。可行性评估是企业架构师可以提供给发起人的高管做出明智决策的解释性工具。

在审查和批准可行性评估后，企业架构师通过收集基于前面提到的领域的解决方案的高级需求来调查环境。

由于处理这些领域的需求可能是压倒性的，企业架构师需要将需求收集过程委托给领域专家、程序架构师和业务分析师。

在这个需求收集阶段，企业架构师的角色是协调和促进需求管理团队。 该团队由多名架构师和业务分析师组成。

在合理地收集和分析需求之后，下一个重要的活动是根据业务影响对需求进行优先级排序。

企业架构师需要制定一套标准，根据战略、路线图文件中描述的因素以及发起人设定的财务和业务优先级来确定需求的优先级。

原文：https://medium.com/illumination-book-chapters/a-modern-enterprise-archi…

本文：https://jiagoushi.pro/modern-enterprise-architecture-approach-chapter-1

企业现代化和数字化转型的核心架构组件

介绍和背景

本章涵盖了使用经过验证的方法解决快速技术变革和消费者对数字产品和服务日益增长的需求的关键点。它包括我作为框架和解决方案开发方法使用的创新模型的经验，我制定和描述了利用技术和企业架构基础。

任何规模的商业组织都面临着应对快速技术变革和消费者对数字产品和服务日益增长的需求的挑战。因此，商业组织寻求找到最佳解决方案来解决因技术和商业原因而出现的日益严重的商业问题。

根据我在大型商业组织中的经验和观察，解决当前和新兴问题的最佳解决方案，尤其是与人工智能项目相关的问题，是在企业层面构建数字化转型要求和目标，并按照以下 14 个步骤所述有条不紊地设计它们。

1 — 架构愿景

每个架构计划都始于一个愿景。作为一种自上而下的方法，架构思维方法要求首先在高层次上设定愿景。愿景是指在概念层面具有创造性想象力、集体智慧和洞察力以实现预期目标的未来。愿景设定了场景，向我们展示了我们未来想要达到的目标。尽管每个人都有想象力和梦想，但战略眼光指的是领导能力。它需要大量的智慧、知识、技能、专业知识和经验。

2 — 架构策略

一旦我们对数字世界有了一个令人信服的愿景，现在就是制定战略的好时机。我们知道我们现在在数字化旅程中所处的位置，并为我们想去的地方而努力。首先，我们的目的地需要被标记。我们的数字战略帮助我们使用总体规划实现目标。总体规划可以是一个高级路线图，将我们带到我们设定的目的地。我们需要制定明确的战略路线图；否则，我们可能会迷失在细节和不断的噪音中。

3 — 业务和技术现状

理解和接受我们目前的情况是至关重要的。不管好坏，但我们需要接受在这个初始阶段的现实。当前状态是我们的基线和起点。知道我们在哪里可以帮助我们设定我们的愿景。但是，传统企业的当前情况可能很复杂且难以编译。

在企业系统中，一切都是相互关联的。可能会注意到某些旧系统或解决方案可能没有充分记录。甚至可能根本没有文档。因此，我们需要进行差距分析并采取适当的行动来解决差距。

尽管存在各种挑战和风险，但我们需要从某个地方开始，以识别当前环境并通过采取必要措施收集尽可能多的信息。在转换生命周期中，这项任务可能令人生畏。因此，我们不应该气馁。相反，这是一个必要的步骤，从长远来看是有回报的。

4 — 业务和技术要求

企业现代化和数字化转型计划可以从多个角度提出许多要求。此外，数字化转型的要求可能是相互关联的，并且有很多方面。大多数情况下，需求从一开始就很简单。但是，它们实际上并不容易管理。

因此，我们需要齐心协力，以结构化的方式从各个角度理解需求。需求涉及多个过程和利益相关者。这些利益相关者可以来自组织的不同部分，具有不同的目标、角色和职责。我们需要识别它们。

用户和系统都有其独特的标准要求。此外，对不同类型的用户有不同的要求。例如，内部和外部用户、技术、执行和管理用户可以在需求格式中定位其他条件。同样，系统也可以有其独特的要求。

5 — 架构背景

在做出架构决策并获得必要的批准后，下一个具有挑战性的任务是在单个页面上提供解决方案的代表性图片。这种图解表示通常称为显示关键依赖关系的解决方案上下文。解决方案上下文是在许多已建立的方法中作为示例找到的工作产品模板。

创建解决方案上下文需要抽象技能。我们需要通过在组件之间设置简洁的关系来在小图片中表示大量信息。我们可以在一张图片中应用一千个单词的谚语原则。

这种抽象思维技能是增加数字化转型解决方案流程的架构和设计智能的一个例子。为任何解决方案设置上下文可以帮助我们以易于理解的方式将其传达给相关的利益相关者。上下文增加了理解整体解决方案的清晰度。

6 — 产品和服务的用例

了解数字化转型解决方案的用例是一项重要的架构责任。处理用例需要不同的思维模式，比如站在用户的角度看事物。因此，同时观察和成为观察者是一种关键的心理能力。

更具体地说，用例是描述消费者使用解决方案的产品或服务的特定情况。我们从用户的角度开发用例。我们需要了解消费者打算如何使用解决方案的特定组件或方面。

通常，功能需求可以帮助我们制定用例。或者，在某些情况下，用例有助于准备适用的需求。用例和需求是相互关联的。我们需要在不孤立的情况下一起分析它们。

7 — 架构解决方案的可行性

架构方法可以通过查看沿途的风险、依赖关系和约束来指导我们思考转型解决方案路线图的可行性。

解决方案的可行性需要企业架构学科中的可行性评估工作产品。它是一个从可操作性角度涵盖我们解决方案所有方面的模板。例如，我们可以使用 TOGAF 等既定方法或我们组织的专有方法中的可行性工作产品模板。

请注意，可行性评估可以在各种专有方法中以不同的名称进行分类。我们可能会检查我们组织的方法中使用了哪个工作产品来捕获风险、问题、假设和依赖关系。

制定全面的可行性评估可以帮助我们减轻关键风险、解决现有问题、捕捉假设并解决具有挑战性的依赖关系和可能的相互依赖关系。从长远来看，在我们的数字解决方案方法中错过这一关键步骤可能会导致可怕的后果。因此，这是解决方案生命周期中的强制性步骤。

大多数时候，评估可行性还需要进行许多权衡以达到最佳解决方案结果。我将在后续部分中解释解决方案的架构权衡。

8 — 从当前状态到未来状态的过渡

在了解需求并阐明解决方案的用例之后，我们需要将它们应用到当前状态。当前状态向我们展示了我们现在所处的位置。通过了解当前状态及其转型要求，我们设定未来状态并制定路线图以实现目标转型目标。

未来的状态需要大量的分析和预测。我们可以在此阶段咨询多位主题专家，以确保未来状态反映我们的愿景、使命和解决方案战略。我们需要确保它满足已确定的要求。

这种理解当前环境和设定未来状态的架构方法适用于我们日常使用的任何数字解决方案。这种结构化的方法有助于我们数字化转型计划的成功。

一旦我们设定了未来状态，下一个关键步骤就是评估构建、部署和消费目标的可行性。

9 — 架构权衡

在构建包括人工智能、云计算、物联网和大数据等新兴技术在内的数字化转型解决方案时，我们进行了大量的权衡取舍。在进行权衡时，我们需要考虑关键因素，例如成本、质量、功能、可用性以及其他几个非功能性项目，例如容量、可扩展性、性能、可用​​性和安全性。

我们进行权衡以在两个必需但不兼容的项目之间建立平衡。换句话说，权衡是两个选项之间的折衷。例如，可以权衡单个对象的质量和成本。

有时，权衡取舍可能会造成两难境地。例如，我们可能会在两个相互竞争且令人信服的选项之间左右为难。在这些困难的情况下，我们必须重新审视我们的优先事项。重新审视我们的优先事项，尤其是关键利益相关者为解决方案目标设定的优先事项，可以提供有价值的线索和必要的指导。

此外，我们还可以重新审视我们批准的愿景、使命和解决方案战略，因为有时我们的记忆可能无法记住企业现代化和数字化转型计划等快节奏转型环境中的确切细节。

有时我们可能会在架构上做出一些权衡来处理不确定性和模糊性。我们可以通过考虑处理这些权衡的关键风险来对比和比较情况。在不冒险的情况下开发架构解决方案是不可能的。

但是，也可以将这些风险转化为机会。因此，我们可以有条不紊地和可衡量地减轻它们。现在让我介绍下一个涉及架构决策的关键点。

10 — 架构决策

每个权衡都需要一些架构决策来支持愿景。此外，这些关键决策可能对我们数字解决方案的成败产生重大影响。

我们需要非常谨慎和可衡量地做出架构决策。每个决策都可能对解决方案结果产生严重影响和多重影响。在解决方案生命周期的后期阶段更改架构决策可能代价高昂。

一些影响可能与成本或合规性限制有关，而另一些可能与非功能方面有关，例如性能、可伸缩性、容量、可用性、安全性或可用性。

此外，我们的架构决策必须经过主题专家的验证，并与多个利益相关者进行沟通，以获得他们的接受和批准，以就决策的有效性达成最佳共识。

11 — 架构模型

我们需要为数字化转型解决方案开发多种模型，涵盖人工智能和物联网等新兴技术。模型是架构解决方案中必不可少的工作产品。模型是建议的结构，通常比其原始结构更小。

一旦我们在抽象层面起草了一个具体的解决方案并且我们的利益相关者理解它，架构思维过程中的下一个重要步骤是通过描述每个组件和关系来更详细地表示概念层面。

详细描述抽象表示需要大量的脑力锻炼，包括处理多种模式和激发我们的思维能力。

我们可以应用于潜在的现代化解决方案的一些重要架构模型是组件模型、操作模型、性能模型、安全模型、可用性模型、服务模型和成本模型。

12 — 高级设计

一旦架构模型到位，我们需要创建基本的高级设计。数字化转型计划需要开发多个工作产品，涵盖基于解决方案上下文的高级设计。

使用基本的高级设计来了解每个解决方案构建块的大局，这有助于数字化转型解决方案。然而，首先，高层设计需要得到所有利益相关者的充分理解、接受和认可。

请注意，在解决方案生命周期的后期阶段更改这些设计可能具有挑战性且成本高昂。为此，我们确保使用我们的战略和路线图生成高级设计，并完全一致以达到最佳解决方案的目标。

13 — 详细设计和规格

与任何其他企业 IT 系统一样，涵盖新兴技术的企业现代化和转型解决方案都需要正确交付其详细设计和规范。因此，在处理规范时，为解决方案组件应用全面的配置管理实践可能是实用且有用的。

在数字化转型和企业现代化的解决方案中，规范准确地标识了企业生态系统项目。由于规范要求精确，因此提供正确的规范对于企业应用程序和相关的关键业务和应急响应至关重要。

在收集数据、交流信息、共享数据和做出正确决策时，系统规范需要准确、可靠和快速。然而，各种孤岛对规范的不可靠沟通、这些规范做出的错误选择以及它们繁琐的布局可能会在尝试详细说明数字转换解决方案时导致灾难性的结果。

由于大量的返工要求，在实施和生产支持阶段发现不准确的详细设计或错误的规范可能会非常昂贵。这些意外错误从各个角度破坏了整个解决方案，作为数字化转型架构师，我们首先要对后果负责。

14 — 动态、敏捷和灵活的治理

技术治理是数字化转型计划的核心要求。由于其性质，这些转型计划需要特定的治理模型。因此，动态和灵活的治理模型对于转型计划至关重要。

传统的严格和极端的基于规则或压迫性的治理模式可能成为进步的障碍。根据我的经验，敏捷原则最适合动态和灵活的治理模型。

数字化转型计划中的治理委员会可能在多个层面上都非常复杂和复杂。因此，治理委员会有许多角色和责任。例如，转型架构师可以运行为复杂的数字转型项目建立的架构审查委员会或设计权威论坛。

我们可以根据我们的解决方案域使用多个治理框架。例如，行业中技术治理的常见框架之一是 COBIT（信息和相关技术的控制目标）。

COBIT 框架可以帮助组织从其 IT 投资中获得最佳价值。因此，他们通过获得收益、优化风险水平和使用资源来保持平衡。其他治理模式可以基于企业所属和坚持的行业。

结论

在处理人工智能、云计算和物联网等新兴技术时，企业现代化和数字化转型计划的系统方法是强制性的。 架构和设计思维技能可以指导计划的治理。 企业架构师的收获是，虽然严格遵循自上而下的战略方法，但许多计划还需要勤奋地采用自下而上的战术方法。

本文：https://www.jiagoushi.pro/node/2179

请参阅使用Sparx EA -tool创建的精益企业架构框架（LEAF）的参考实现。

Sparx EA模型以HTML格式发布，可通过以下方式访问：

链接

LEAF的第一层如下图所示（图1）。

Figure 1: Lean EA Framework (LEAF) – the 1st layer.

 

LEAF的第二层如下图所示（图2）。

Figure 2: Lean EA Framework (LEAF) 2nd layer.

LEAF的第二层从位于Architecture Landscape部分的内容占位符打开，如下面的图3所示。

Figure 3: LEAF layers.

这个LEAF框架不断更新，更适合用于结合设计思维，企业架构方法和目标驱动方法（GDA），服务驱动方法（SDA）等方法的通用框架。更多信息 LEAF可以在这里找到：链接。

可以从此博客站点下载Sparx EA EAP模型。

 

如果您在为大型组织建模现实，全尺寸架构方面拥有一些经验 - 当然，最好是使用ArchiMate语言 - 您可能会遇到以逻辑和可管理的方式组织模型的挑战。在这个由两部分组成的系列文章中，我们将分享我们组织您的架构模型的前6种方法。这六种方法应该可以帮助您保持模型整洁，同时为您的战略计划提供更好的结果。

1.按业务域，信息域和技术堆栈组织模型存储库

在大型组织中，您需要一些子结构用于集成的当前状态模型。可以按业务域或高级业务功能组织功能，业务功能和业务流程。这是商业世界的一个自然细分，既有相关人员容易识别，也有企业的典型责任和授权结构。

模型存储库的应用程序和数据部分可以根据信息域进行组织，包括：

1. 通常属于一起的信息项集
2. 处理此信息的应用程序
3. 这些应用支持的业务功能

例如，您可能拥有客户数据的信息域，包括您在客户上捕获的相关个人数据以及用于存储和处理它的应用程序（例如CRM系统）。另一个信息域可能是客户交互，例如，您可能会在其中找到呼叫中心和社交媒体应用程序。

对于体系结构的技术部分，面向业务的结构通常没有多大意义，因为企业的大部分技术基础架构都跨越业务或信息域。相反，在许多情况下，通过技术堆栈进行组织更有意义。然后，这些堆栈模型可由具有必要技术专业知识的独立团队进行管理。

设置导航页面以帮助人们找到绕过此结构的方式也非常有用。下图显示了这个例子。

另外两个模型类别是1）外部参考模型和2）标准。例如，上图中显示的银行业BIAN标准或ISO / IEC 207001安全标准描述了您的工作方式，包括：

• 建模过程
• 命名约定
• 架构角色
• 和更多

在同一个存储库中访问这些非常方便。当然，这些领域可能存在交叉和重叠的方面。要对这些进行排序，您需要在相关专家之间建立定期协调，最好由协作平台支持，该平台允许您设置正确的权限，创建审阅工作流以及组织要完成的工作。我们的Enterprise Studio和HoriZZon产品提供支持架构建模这一方面的工具。

2.分离当前和未来状态模型

重要的是要明确区分您所描述的关于世界的内容，以及您所了解的未来。关于现在的事实和关于未来的想法应该在您的架构模型中清楚地区分。

实现此目的的一种方法是创建当前状态的可读，集成参考模型（可能是每个域，如上所述）和单独的项目级模型，这些模型描述了未来设计时的各个方面。这些未来状态模型的可见性仅限于针对它们的特定项目团队，因此人们不会对未来状态设计的工作感到困惑。在这些未来状态模型中，可以重用当前状态的元素，这些元素可以被重用。一旦将项目结果投入生产，未来状态模型将成为现实，并将转变为集成的当前状态模型。

值得注意的是，创建这些模型的过程非常不同。在描述当前状态时，通常最容易从ArchiMate建模语言中所谓的“结构”开始：企业中容易看到的组织，应用程序，软件平台和设备。从那里，您可以查看它们的行为：这些结构元素提供的流程，服务和功能。在下一步中，您可能会寻找协同或合理化的共性和机会，仅作为示例。

但是，在设计未来状态架构时，您通常会以相反的方式工作：首先定义解决业务问题所需的服务，然后概述提供服务所需的流程和功能。完成后，您才会决定将执行此行为并提供这些服务的结构元素。这避免了通过您所知的结构（即组件，系统，产品等）约束您可能的设计解决方案的常见陷阱，尤其是在设计过程的早期阶段。

3.将模型内容与该内容的视图分开

在体系结构建模中，通过以适当的方式可视化部分内容，将您的体系结构的内容与解决特定利益相关者关注点的此内容的视图区分开来非常重要。相同的模型元素可能出现在不同的视图中;反之亦然，所有视图共享相同的底层内容。

通常，您根据已建模的元素类型组织模型内容，例如使用ArchiMate语言的层（动机，策略，业务，应用程序，技术，实现和迁移），或者通过定义更细粒度单独的业务流程，应用程序组件等集合。

有关该内容的观点最好根据您所涉及的利益相关者类型进行组织，并为业务经理，流程设计人员，应用程序所有者，数据管理员，项目经理，系统管理员等组提供视图。

更多架构模型组织理念

在本系列的下一部分中，我们将讨论命名和建模约定，以及讨论模型的治理和质量保证的结构。敬请关注！

原文:https://bizzdesign.com/blog/6-ways-to-organize-your-architecture-models-part-1/

本文:http://pub.intelligentx.net/enterprise-architecture-6-ways-organize-your-architecture-models-part-1

讨论: 加入知识星球【首席架构师圈】

 

在这个架构模型系列的前一部分中，我写了关于根据业务，信息和技术领域组织模型库的文章。我还解释了创建单独的当前和未来状态模型以及模型内容和视图之间的分离的必要性。在本系列的这一部分中，我还有一些关于命名和建模约定的内容，以及有关如何在模型周围建立治理和质量保证结构的建议。

4.定义命名和其他建模约定

为了能够在大型模型中找到任何东西，您必须知道要寻找什么。用简单的语言，您需要知道模型中所谓的内容以及标记方式。这就是定义明确的命名约定至关重要的原因。不同的组织将有自己的特定命名方案，因此没有普遍的约定适用于所有情况。

不过，这里有一些常见的技巧可以帮助您创建命名过程：

1. 让业务专家“拥有”功能，业务流程，功能等的名称和定义。如果IT人员为这些人创造了新名称，那么企业往往无法识别其中的“业务”，从而导致误解和误解。
2. 为特定类型的元素定义特定的命名约定。例如，对过程名称使用现在时动词加名词（例如'Handle Claim'）。这样，元素的名称已经为您提供了有关被建模事物类型的信息。
3. 在大型组织中，使用名称的前缀或后缀，例如元素的业务域。如果这些域使用相同的名称，这一点尤为重要。例如，在保险公司中，“健康”，“生活”或“财产”等不同的域可能都有“处理索赔”流程，但这些流程会有所不同。称他们为“处理索赔 - 健康”或“处理索赔 - 财产”有助于区分他们。
4. 在建模的同一现实生活实体的不同方面之间进行明确分离。如果您为作为参与者参与流程的客户建模，请不要对您在该客户上捕获的信息使用相同的名称。您还应该在存储该信息的客户文件或数据库中使用不同的名称。将所有这些元素称为“客户”肯定会让使用您的模型的人感到困惑。
5. 在使用建模概念时要有选择性。像ArchiMate这样的语言非常丰富和强大，但你很少需要他们所有的概念。选择将哪些概念用于哪些目的并限制自己的基本要素是保持架构易于理解的关键。

5.建立'编委会'

要在大型联合组织中创建协作，您不能依赖中央部门的简单自上而下控制。必须有局部差异的空间，因为在大型组织中，没有标准适合所有情况。

尽管如此，您确实需要在不同的部门和域之间进行协调，以确保他们的工作方式兼容，并分享彼此的经验，从而建立自己的组织特定最佳实践库。

与这些庞大而复杂的组织合作，我看到创建一种“编辑板”通常很有帮助，该编辑板由来自组织不同领域的代表性架构和建模专家组成。他们可以在您的架构中找到共享的工作方式和其他共性（例如前面提到的建模惯例和结构），并且他们可以指导他们经验不足的同事应用这些实践来推广高质量的模型。

但是，“编辑板”与典型的架构板不同，后者决定架构内容本身。相反，这个编辑委员会负责监督架构的建模和描述方式。这是两个截然不同的能力：良好的架构可能记录得很糟糕，而且糟糕的架构可能有很好的文档记录。确保两者都做得好。

6.明确职责，访问权限，用户组和程序

在任何大型组织中，您必须清楚谁做什么以及谁有权访问哪些材料。如果每个人都可以编辑您的架构模型中的任何内容，您可以猜测会发生什么。事情可能会被移动或整个模型可能被删除。

一般而言，我不主张从视图中隐藏部分体系结构（除非出于特定的安全相关原因）。应该信任建筑师，看看同行的工作并充分利用它。但是，您可能需要限制对在创建或更新模型中具有已定义角色的人员的写访问权限。否则，你的模型很快就会变得一团糟。

实现此目的的一种方法是在项目中组织未来状态体系结构的工作，每个体系结构都有自己的特定模型，如上所述。项目团队有权更改他们的项目模型，但结果只有在他们已经足够准备好时才会发布到更广泛的体系结构存储库，这是由组织中的首席架构师或决策者决定的。

Enterprise Studio的团队平台支持组织为设计人员和首席设计人员提供的不同项目，角色和权限，并提供可组织为项目团队的用户组。 此外，HoriZZon门户中的工作流程设施允许您创建批准和审核工作流以组织体系结构开发过程。

有兴趣了解我们支持大规模架构工作的方式吗？ 加入我们的网络研讨会或预订演示

 

原文:https://bizzdesign.com/blog/6-ways-to-organize-your-architecture-models-part-2/

本文:http://pub.intelligentx.net/node/380

讨论：加入知识星球【首席架构师圈】

 

发布 TOGAF 的组织 The Open Group 的总裁兼首席执行官 Steve Nunn 最近就 2022 年的计划提供了一些见解。很高兴看到他的陈述进一步证实了我在 2020 年对未来发展的假设托加夫。本文总结了最重要的陈述，将它们置于上下文中，并有助于理解 TOGAF 在未来的相关性。

The Open Group 的现状

在他关于 The Open Group 2021 年成就和 2022 年新发展的文章中，史蒂夫谈到了几个有趣的话题，其中包括：

•  The Open Group 去年庆祝成立 25 周年
•  认证人数现已达到115,000人。我已经在我的一篇文章中谈到了认证 TOGAF 个人的强劲增长，当时它刚刚达到 100,000 大关
• The Open Group 的几个特定领域达到了里程碑。其中，OSDU数据平台Mercury发布、SOSA参考架构技术标准、FACE培训计划
•  正如我在 2020 年指出的，全球 TOGAF 认证中只有 3% 是在中国获得的。作为中国如此巨大的市场，The Open Group 显然应该更加关注在中国的扩张。因此，2021 年的一项特别成就是将许多文件翻译成普通话，以简化使用并提高接受度
•  还专门针对其他增长中的市场，例如巴西和印度
•  已收集 ArchiMate 3.1 的反馈，计划于 2022 年中发布
•  IT4IT 也计划在不久的将来发布 3.0 版本
•  开放组正在主持一个工具包星期二广播系列，我觉得听这个系列很有趣！
•  The Open Group 还有几个论坛，致力于解决当前紧迫问题，例如网络安全、供应链安全和大规模疫苗接种活动
•  最后，Open FAIR 认证计划惠及 1,000 名获得认证的个人

2022 年对 TOGAF 有何期待

我经常听到这样的问题：TOGAF 仍然与企业架构师相关吗？现在 TOGAF 仍然有用吗？ 2022年？什么将取代 TOGAF？ TOGAF 过时了吗？我的观察是，即使在今天，TOGAF 仍然具有一定的相关性。但是，它的某些部分已经过时。此外，The Open Group 似乎针对 TOGAF 及其其他认证、框架和标准制定了新战略。史蒂夫纳恩最近的信息证实了这些想法。

什么是 TOGAF 路线图 2022？

TOGAF 的相对相关性下降

TOGAF 认证的（相对）相关性很可能在未来减少，这似乎也是 The Open Group 的意图：

•  Open Group 最近专注于许多其他认证，其中部分还涵盖了人们对 TOGAF 标准本身的期望（例如，数字从业者）
•  当前版本，TOGAF 9.2，有几个过时的章节，但是，快速更新似乎不是优先事项
•  相比之下，TOGAF 标准应该是框架的稳定中心，而补充指南列表应该涵盖更频繁变化的主题
•  与9.1版本相比，TOGAF 9.2合并了160多页

TOGAF 标准正在重组

Steve Nunn 为我的上述想法提供了证据： The Open Group 目前正在对 TOGAF 标准进行重组。但是，仍然没有官方沟通的时间表表明何时发布新的 TOGAF 版本。无论如何，重组的一个关键方面是 TOGAF 系列指南的当前工作和详细说明。与 TOGAF 标准中的内容相比，这些主题关注的主题变化更频繁，需要更频繁地更新。考虑到数字化转型以及 IT 的当前趋势和发展，很可能更多的内容将被归类为“经常变化”而不是“稳定”。因此，另一个明确的迹象表明该标准将变得不那么相关（而指南将变得更加重要）。

TOGAF 系列指南将取代 TOGAF - 至少在部分

鉴于 TOGAF® 系列指南在未来可能具有的重要性，让我们来看看当前涵盖的主题：

•  组织映射
•  架构成熟度模型
•  建筑技能框架
•  信息映射
•  商业模式
•  业务能力
• 建筑项目管理
•  从业者遵循 TOGAF® ADM 开发企业架构的方法
•  建立和发展 EA 能力的 TOGAF® 领导者指南
•  TOGAF 集成信息基础设施参考模型 (III-RM)：无边界信息流的架构方法™
•  价值流
•  业务场景
•  TOGAF® 技术参考模型 (TRM)
•  使用 TOGAF® 框架来定义和管理面向服务的架构

对于 2022 年，Steve Nunn 表示，The Open Group 将进一步集中数字标准组合，并专注于整合各种标准，创建一个用于数字企业的有用组合。

原文：https://digitalroadmap-management.medium.com/new-togaf-developments-in-…

本文：https://jiagoushi.pro/new-togaf-developments-2022

2022 年 4 月 25 日，The Open Group 发布了 TOGAF 第 10 版。这不仅是 The Open Group 的重要里程碑，也是整个企业架构行业和所有从业者的重要里程碑。作为企业架构师的首选标准，第十版“标准”长期以来一直受到人们的欢迎。它还必须满足很高的期望。

谁是 TOGAF 标准 10 的幕后？

TOGAF 10 的发布者是 The Open Group，这是一个开发开放的、供应商中立的技术标准和认证的全球联盟。 Open Group 成员来自不同行业的许多大型全球组织，包括 IBM、甲骨文、华为和飞利浦。这确保了所开发的框架和最佳实践也适用于各个行业。总而言之，TOGAF 是可以参考的企业架构内容的最重要来源。

TOGAF 的历史 — TOGAF 10 版本的意义是什么？

TOGAF 的第一个版本于 1995 年发布。第 9 版是最后一次重大更新，于 2011 年发布。2018 年，作为 9.2 版发布了一个小更新。作为一个次要版本，9.2 版到目前为止还不足以解决过去十年中 IT 内部及其周围发生的巨大变化。 2018年，我分析了TOGAF 9.1和9.2版本的变化。我得出的结论是，在解决整个数字化转型方面几乎没有做出实质性的改进。

结果，TOGAF 的重要性下降了，企业架构最佳实践的新资源出现了，尤其是关于数字化、云计算或敏捷性等主题的问题得到了 TOGAF 以外的其他资源的回答。尽管如此，每个人都在等待 TOGAF 版本 10 的下一个大版本，从他们的角度为这些问题提供答案。

TOGAF 第 10 版于 2022 年 4 月 25 日发布，这对于 The Open Group 和整个企业架构社区来说是一个重要的里程碑。

什么是 TOGAF 10？

最重要的是，TOGAF 版本 10 是对企业架构内容的重组，使标准更易于阅读、使用、管理和更新。其关键是内容的进一步模块化。这种模块化已经从 9.2 版本开始，最初引入了 TOGAF 系列指南，以提供有关更频繁变化并很快过时的主题的附加内容。相比之下，TOGAF 标准的大小从超过 692 页减少到 532 页，并且只包含随时间推移相当稳定且不需要每隔几年完全更改的内容。

在版本 10 中，The Open Group 在这条道路上走得更远。更多内容已从核心内容中删除并添加到 TOGAF 系列指南中。此外，TOGAF 库已正式添加到整体 TOGAF 内容概述中，该库包含更多、非常有用的内容并在过去几年中不断增长。结果是一张看起来像洋葱的图片，中间的内容最稳定，外层的内容变化更快。

TOGAF 10 的内容

TOGAF 基本内容分为 6 个单独的文档，它们是：

•  简介和核心概念（88 页）
•  架构开发方法（ADM）（154 页）
•  ADM 技术（88 页）
•  应用 ADM（36 页）
•  建筑内容（120 页）
•  企业架构能力和治理（64 页）

此外，TOGAF 系列指南涵盖了许多以前包含在标准本身中的内容，但现在作为单独的指南发布。此外，还添加了全新的指南——其中一些在过去几个月中已经添加：

•  业务架构
•  信息架构
•  安全架构
•  企业架构/敏捷架构
•  企业架构/数字化企业
•  技术架构
•  MSA/SOA 架构
•  调整 ADM
•  …

最后但同样重要的是，TOGAF 库包含支持 TOGAF 基本内容和 TOGAF 系列指南的更多文档。例如，该库包括不同的翻译、特定行业的指南（例如能力图）和更主观的文档，以及白皮书、网络研讨会、学习指南和参考卡。

TOGAF 10 有什么新功能？

根据 The Open Group 的说法，TOGAF 的大多数更改都涉及将内容重组为可消化文档的模块化片段。然而，这并不是唯一显着的变化。我还没有机会详细浏览所有内容。但是，在第一次研究新材料后，我特别注意到以下变化：

TOGAF 系列指南现在是 TOGAF 10 标准的一部分

在 9.2 中，有 TOGAF 标准和 TOGAF 系列指南，后者现在是 TOGAF 标准的官方部分。虽然 TOGAF 系列指南以前是标准之外的进一步支持材料，但这个角色现在由更广泛的 TOGAF 库承担，提供更多、更快的变化内容。

TOGAF 架构层移至系列指南

旧 TOGAF 的一个主要方面是对不同层的解释。在版本 10 中，将业务架构、信息架构和技术架构的层移到了系列指南中。作为业务架构的一部分，业务能力的主题从基础内容转移到了系列指南中。这强调了将可能不太稳定的主题（例如定义、重要性、方法）移到系列指南中并从基本内容中移出的意图。

安全架构成为增量部分

安全架构的主题已被添加到与其他架构层相同的重要性级别。然而，它还没有被添加到架构开发方法 (ADM) 中。

数字化和敏捷现在是 TOGAF 10 的一部分

更现代的主题，如数字和敏捷现在在 TOGAF 标准中得到解决。现在每个都有其系列指南。

信息和数据内容已添加到 TOGAF 10

有关信息映射和主数据管理的可用内容显着增加。

TOGAF 的更广泛受众

新版本试图与更广泛的受众相关。它为特定受众提供步骤和内容。此外，某些章节的 IT 重点已被删除，以与业务相关。例如，围绕 EA 能力和治理这一主题。

TOGAF 定义

已经添加、更改或删除了相当多的定义（例如，产品或数字架构的定义）。

新版本肯定有更多变化隐藏趋势，等有机会详细回顾 TOGAF 10 后再写。

TOGAF 10 值得吗？

我对 TOGAF 10 的最初印象是非常积极的。让我们总结一下论点：

• The Open Group 已设法将 TOGAF 标准切成更小、更易消化的部分。新的模块化结构使内容更容易掌握。具有不同架构风格的不同组织也可以更好地选择考虑什么和不考虑什么。
•  TOGAF的核心内容进一步巩固，整体一致性增加，多余内容被删除。可能随时间快速变化的内容已移至 TOGAF 系列指南，以便 TOGAF 基础内容的整体重要性和相关性增加。
•  新结构允许通过简单地发布新的 TOGAF 指南更频繁地向 TOGAF 标准添加新内容。这也是在标准的正常发布周期之外完成的，以解决新出现的想法。
•  添加、改进或更详细地描述了过去几年大大增加其重要性的几个新概念或主题。这些包括上面提到的大多数主题，包括架构场景的概念、信息管理的重要性和客户主数据管理。

总而言之，我对新版本感到非常惊讶。尤其是模块化结构以及将 The Open Group 创建的更多内容纳入更广泛的 TOGAF 标准（例如，许多“操作方法”指南）使其成为所有企业架构师非常有价值的内容。

TOGAF 10 认证

目前，没有关于 TOGAF 10 的发布如何影响 TOGAF 认证的信息。可以想当然地认为，即将推出 TOGAF 10 的新培训要求和新培训。但是，尚不清楚在以前的 TOGAF 版本中获得认证的人是否需要重新进行认证。我假设对于那些获得 TOGAF 9 认证的人来说会有一个较短的考试，主要是解决内容的重组和一些新概念。一旦有新信息，我会提供。

原文：https://digitalroadmap-management.medium.com/togaf-10-is-now-released-a…

本文：https://jiagoushi.pro/togaf-10-now-released-and-available

企业架构研究人员Svyatoslav Kotusev写道，对于许多人来说，企业架构（EA）的概念与EA框架密切相关，如果不是完全同义的话。

据称，这些框架为实践企业架构和解决组织中的业务和IT协调问题提供了必要的指导。

现有的EA框架包含在许多主流来源中。这些来源包括Roger Sessions的一篇相当著名的文章，其中介绍了四个主要的EA框架，Zachman、TOGAF、FEA和Gartner，其影响力甚至可以在最新的行业出版物中看到，还有一本相当著名的书“How to Survive in the Jungle of Enterprise Architecture frameworks”讨论了14个EA框架1。

此外，思考框架的类型在各种EA作者中非常流行。例如，学术文献提供了数十篇论文，专门用于分析、比较和制定EA框架的选择标准2。仅Gartner就发布了近十几份价值数百美元的报告，就如何正确分析、选择和处理EA框架提出了建议3。当地咨询公司和软件工具供应商也提供了自己的比较和框架选择指南。

乍一看，当前的文献从所有可以想象的角度对所有现有的EA框架进行了详尽的分析。然而，尽管现有框架分析丰富多样，但这些分析有一个非常重要的共同点：所有这些分析都是完全推测性的。具体而言，所有这些人都认为EA框架所承诺的一切都是真实的，即代表了真正的最佳实践和有效的参考模型，这些模型在一些组织中被证明是有用的，并且可能对其他愿意实践企业架构的公司有益。出于这个原因，所有现存的EA框架分析基本上只关注这些框架给出的充分承诺，并将其承诺视为理所当然，但从不质疑它们或分析这些承诺是否实际兑现，或在多大程度上兑现。

那么，除了这些推测之外，我们对流行的EA框架了解多少？虽然之前的所有分析都只比较了EA框架的声明和承诺（例如，哪些框架对EA实践的哪些方面提出了更多的指导），但本文比较了它们的实际后果和结果（例如，EA框架是否真正兑现了承诺，以及它们的真正价值是什么）。特别是，本文重点介绍了四个最广为人知的EA框架：Zachman框架、FEAF、DoDAF和TOGAF。

Zachman框架

Zachman框架最初出现于20世纪80年代，是一种用于架构描述的二维30单元分类法4。今天，它被广泛宣传为企业架构的基本结构甚至“本体论”，其在EA学科中的作用相当于化学元素周期表的作用。

该框架由当时的IBM营销专家约翰·扎克曼（John Zachman）提出，作为其“仅仅是为了改进遵循BSP'5的规划方法”（第xvi页）（BSP是他自20世纪70年代以来推广的早期IBM信息系统规划方法之一）的一部分。该框架源自Zachman对制造业和建筑业中使用的建筑表现之间存在的相似性的观察。也就是说，Zachman推测“在构建任何复杂的工程产品（包括信息系统）的过程中，可能会产生一组类似的体系结构表示”4（第281页）。虽然该框架最初是为单个信息系统设计的，但在20世纪90年代末，它很容易被“提升”到企业级，并重新定位为企业架构的框架，即使其结构没有任何明显的修改6。

Zachman开发的工程产品和信息系统之间的潜在类比的根本缺陷早就被发现了，除了其他许多人之外，甚至他的IBM7同事也发现了。然而，Zachman继续强调推广他的框架，并不断追问：“为什么有人会认为企业的描述性表示会与其他任何已经创建的描述表示有所不同？”8（第41页）此外，他毫不留情地为制作“令人痛苦”的详细描述而辩解，甚至进一步保证此类正式的、工程风格的图纸对组织来说是必要的：

“总有一天，我向你保证，你会希望[Zachman框架]中确定的每一个模型都明确化，每一个都明确化为企业范围的模型，所有模型在每一行中水平整合，所有模型垂直向下整合到每一列中，所有模型都明确到了令人痛苦的细节级别”9（第9页）

当然，Zachman没有明确说明他的担保可以在哪里兑现，也没有在传播这些想法时冒着自己的风险。现在很难估计有多少人对他的处方感到困惑，有多少钱在全球组织中白白浪费，试图开发扎克曼所建议的“所有细节层次上明确的模型”。然而，一些按照他的建议行事的组织的研究报告表明，他们的EA实践导致了巨大的失败，“带来了数百万美元的后果”10（第85页），轶事证据表明，类似的经历在整个行业都很典型：

“我们大多数人都听过约翰·扎克曼（John Zachman）经常引用的一句话：“总有一天，你会希望所有这些模型都能清晰地、企业范围内、横向和纵向地集成在一起，达到令人痛苦的细节水平”。这句话太过夸张，导致太多的EA团队将自己锁在象牙塔里，被数百个无人能跟上的模型所淹没。11（第10页）

由于Zachman出色而持久的宣传努力，我们今天所拥有的是一种纯粹的符号分类法，它被认为是基本的，但显然是基于不恰当和令人困惑的假设，无法对真正的EA工件进行分类，没有其实际应用的示例，没有组织中的用例，如前所述，对EA从业者没有任何影响，也不会为EA学科增加任何理论或实践价值。除此之外，与广泛的观点相反，Zachman框架在历史上没有引入架构的概念，也不是第一个架构分类法，甚至没有像前面所报道的那样定义“企业架构”一词。

目前，可以公平地说，对Zachman框架的广泛兴趣已经消退，在未来几年内，由于其莫名其妙的实用性，EA社区很可能会忘记它。然而，一些架构师仍然喜欢Zachman框架，因为与其他EA框架不同，它易于使用——“使用它”不需要研究大量的材料，也不意味着要做任何特别的事情。

联邦企业架构框架（FEAF）

联邦企业体系结构框架（FEAF）是1990年代末专门为美国联邦政府制定的相当全面的EA指南12。从修辞上讲，FEAF基于约翰·扎克曼（John Zachman）和史蒂文·斯佩瓦克（Steven Spewak）的开创性思想，他们被视为“架构概念化和企业架构规划领域公认的两位领导者”12（第19页）。

然而，在现实中，FEAF直接源自1960-1970年代的古代信息系统规划方法。例如，FEAF利用了Spewak的企业体系结构规划（EAP）方法，这反过来“植根于IBM的BSP”，正如其作者明确承认的那样5（第53页）。因此，与早期的架构（architecture）规划方法类似，FEAF基于一个天真的假设，即整个组织的长期目标状态可以由一组专门的规划人员定义，通过大量的正式图表和关系矩阵进行详细描述，然后按计划实施。

早在FEAF13、14、15开发之前，BSP和类似的机械规划方法就被证明是不切实际的。此外，就连Steven Spewak自己也承认，“绝大多数进行企业架构规划的企业都不成功”5（第19页）。毫不奇怪，FEAF也失败了，而且失败得惊人：

“联邦政府内部的企业架构一直不起作用，而且往往没有产生有用的结果。此外，联邦EA计划的重要部分已经完成，完全失败了16（第6页）

FEAF的彻底失败可以被公平地认为是有史以来EA计划中最昂贵的一次失败：

“到目前为止，联邦政府在企业架构上花费了超过10亿美元，如果不是大部分的话，也有很多被浪费了”16（第52页）

更糟糕的是，FEAF的出现也代表着逻辑和常识的明显失败：早些时候在多家公司中被证明无效的规划方法被“放大”到了联邦层面，结果再次失败，损失更大。鉴于之前关于正式架构方法论13、14、15的大量负面研究结果，FEAF的失败可以被视为一种自然的、完全可预测的，甚至是唯一可能的结果。

今天，FEAF可以说不值得EA从业者社区的任何关注。它没有提供任何可以帮助任何人建立EA实践的合理指导，没有任何实用价值，只有一些模糊的图片和一堆奇怪的参考模型，即使是为美国政府工作的建筑师也没有真正理解其含义16。

国防部体系结构框架（DoDAF）

国防部体系结构框架（DoDAF）于2000年代中期出现，是美国国防部（DoD）体系结构的一种通用方法，代表了1990年代诞生的早期C4ISR框架的演变17。DoDAF定义了体系结构中应涵盖的视图、应创建用于描述这些视图的特定产品以及开发这些可交付成果应遵循的步骤。

从概念上讲，DoDAF体现了与早期架构（architecture）规划方法所启发的FEAF基本相同的理念和信念，例如，一旦您生成了描绘期望未来的全面架构，它自然会帮助您做出更好的决策（不知何故）。然而，除了其他架构（architecture）方法学13、14、15的类似发现外，这些信念的幼稚性在以前甚至特别是在与C4ISR框架（DoDAF的直接前身）相关的情况下被注意到：

人们普遍认为，如果有人建造了这座建筑，业主和运营商就会来。然而，历史表明，很少有组织真正“运营”了该体系结构，所有者和运营商也没有来。从一开始，固有的缺陷就是缺乏标准框架或方法，无法将架构插入决策过程18（第2页）

正如上文讨论的FEAF的情况一样，这些早期关于体系结构方法缺陷的观察并没有阻止国防部在更大范围内再次重复同样的错误。特别是，国防部打算为其业务任务领域创建一个全面的体系结构，该体系结构由DoDAF19（第40-41页）规定的几乎全套26种产品组成（顺便说一句，本案例清楚地表明，EA框架最初的设计目的是“按原样”实现，而不仅仅是像许多人今天所说的那样作为灵活的体系结构工具包）。然而，提交给国会委员会的官方报告得出的结论是，开发的架构交付成果基本上是无用的：

“它生产的产品没有提供足够的内容和实用性来有效地指导和约束正在进行的和计划中的系统投资。因此，尽管国防部花费了近4年的时间和大约3.18亿美元，但它没有一个有效的体系结构计划19（第二页）

几年后的另一份官方报告也证实了同样的结论：

“尽管国防部在其企业架构上花费了超过10年的时间和至少3.79亿美元，但其使用该架构指导和约束投资的能力仍然有限”20（第二页）

因此，DoDAF并没有在国防部建立一个成功的EA计划，而是消耗了近4亿美元，以类似于FEAF16的方式，只生成了一堆不适合决策目的的神秘文件。正如国防部的一份报告简洁地总结的那样，“数亿美元已用于商业企业架构（BEA），但其用途有限”21（第1-2页）。

目前，DoDAF可以说是最好的，因为它是一个松散的多样模型目录，其中一些模型偶尔会被经验丰富的架构师发现有用或启发，主要是在解决方案架构领域。任何一个理智的人都不应该像国防部那样，认真考虑DoDAF的处方作为其EA实践的可操作指南。

开放组架构框架（TOGAF）

开放集团架构框架（TOGAF）由开放集团于20世纪90年代中期根据早期TAFIM框架22的材料创建，该框架本身基于20世纪80年代中期启动的一些早期模型。TOGAF为EA实践提供了端到端的整体指导，包括开发架构（ADM）所需的步骤和子步骤、描述架构（ACF）所需工件和可交付成果的全面集合、治理和成熟度模型，以及许多其他不同的建议22。目前，TOGAF已成为最流行的EA框架，并被许多人视为企业架构中事实上的行业标准。

与FEAF和DoDAF类似，TOGAF遵循的基本上是与所有先前的架构（architecture）规划方法（例如BSP、方法/1和信息工程）相同的机械化逐步逻辑，这些方法在很久以前就已经失去了信誉，因此基本上没有提供任何新的东西，在实践中根本无法成功工作23。例如，与所有正式架构（architecture）方法论相关的众所周知的问题在早些时候已经被报道过，并最终导致了TAFIM的退出（从而导致了TOGAF的出现）：

TAFIM无疑需要大量的时间和资金投入。[…]生成体系结构所需的时间使其在完成之前接近过时。[…]最终结果通常是面向商业的受众无法理解的，并且很难追溯到商业战略。[…]也许部分由于这些缺陷，TAFIM于24年突然被取消（第79页）

那些或多或少遵循ADM步骤并开发ACF规定的至少一半可交付成果的架构师将不可避免地面临类似的问题，经历失望，最终放弃TOGAF作为实际指导：

“经过密集的熟悉阶段和最初的研讨会，TOGAF被介绍给了相关的利益相关者，我们决定：谢谢，对我们来说太复杂了”25（第14页）

然而，正如早些时候23、26所报道的，目前TOGAF的荒谬性已经在经验丰富的EA从业者中得到了广泛认可。现在，在几乎所有的情况下，TOGAF都仅仅被视为一个标签，并被纯粹声明性地“使用”——其规定被简单地忽略，取而代之的是其他更合理的规划方法。

可以说，很难准确地评估过去试图采用TOGAF“最佳实践”的组织浪费了多少资金，但EA团队将其活动与TOGAF相结合，制作了大量货架，并被淘汰或重组的故事在地球的每个角落都很丰富。考虑到TOGAF作为公认的EA标准，在全球范围内以不同的力度大力推广至少20年，并得到咨询公司、专家和其他商业支持者的全球基础设施的支持，这些支出确实令人望而生畏，远远超过所有其他EA框架的总费用。除此之外，围绕TOGAF课程、培训和认证，还形成了一个价值数百万美元的独立产业，除了象征性的徽章外，什么都没有。

尽管TOGAF推荐的整体分步规划方法不适合真正的组织，但可以公平地说，500页长的TOGAF手册中提到的一些单独的术语、概念、想法和工件在实践中肯定会有所帮助。然而，为了能够“解读”本手册，请将一些好的想法与众多不好的想法区分开来-​好的，并确定它们在具体情况下的适用性，架构师应该充分认识到EA实践实际上是如何工作的。从这个角度来看，TOGAF可以被讽刺地视为随机EA相关想法的“垃圾桶”，在那里偶尔可以找到有用的东西，但只有那些已经知道所有这些的成熟EA从业者才能理解要寻找什么以及如何正确解释它。

顶级企业架构框架概述

上面的讨论从务实、实用的角度对四个最突出的EA框架进行了现实的看法和分析。图1简要总结了前四个EA框架的比较。

Figure 1. A Comparison of the Top Four Enterprise Architecture Frameworks (click to view larger image)

那么，哪一个更糟？从图1中提供的比较可以明显看出，前四个EA框架中没有一个得到任何人真正的最佳实践的证实；所有这些都只是一些早期建筑规划方法的翻新复制品，这些方法曾被咨询公司宣传过，但被证明不切实际并消失了，除了Zachman框架，它代表了对其中一种方法进行改进的肤浅尝试。所有这些框架都提倡简单化的想法，这些想法受到经典工程风格思维的启发，体现在形式化的文档或分步流程中，不适合具有活力、社会性质和巨大复杂性的真实组织。每一个著名的EA框架都对试图以浪费资金和精力的形式使用它们的组织造成了明显的损害，即使这些框架是专门为具体组织定制的，如FEAF和DoDAF。不用说，他们中的每一个承诺都比实际实现的要多得多，如果有的话。出于这个原因，可以得出这样的结论：这些EA框架都更糟糕。

尽管前四个EA框架中没有一个被证明是有用的，但每一个仍然被其销售人员积极宣传为某种形式的“最佳实践”：Zachman框架“在围绕企业架构定义方面具有深远意义”，FEAF和DoDAF“被证明具有即时适用性”，“是非常强大的框架”，而TOGAF是“一种经过验证的企业架构方法”和“最突出和可靠的企业架构标准”。通常，整个EA框架流是由商业利益驱动的，而不是常识。许多咨询公司、供应商和专家为了自己的金钱目的兜售EA框架，而不顾其对EA纪律的不利影响。

总的来说，EA框架的现象无疑是一种宏大的管理时尚，被EA社区可耻地吞噬了。此外，它可以说是管理史上最荒谬的时尚之一，或者说是“世纪时尚”，相对于以前的现有方法，它提出的新想法太少，在全球组织中浪费了太多资金，给实践带来的价值太少，考虑到所有这些，仍然没有被一致认为是一种时尚。更糟糕的是，EA框架并没有因为不切实际和被遗忘而被彻底拒绝，而是以大学课程和建筑师的先决条件认证的形式慢慢融入社会结构，使其永久化，并在整个EA社区中造成修辞和现实之间的永久性认知失调。

由于需要丰富的想象力、坚定的信念或强大的商业动机，才能在成功的EA实践实际工作的方式和流行的EA框架规定的内容之间找到任何相似之处，因此这些框架不值得认真讨论，只会被嘲笑和抛弃。不要试图实现EA框架，请注意下一个流行趋势！

TOGAF 10 最近发布并且现在可用。我们退后一步，从从业者的角度看待在组织中开展企业架构工作。但是，本文区分了不同的 TOGAF 10 受众和用例，并认为组织内已经有正在进行的企业架构活动。本文有助于了解如何使用全新版本。TOGAF 10 的主要改进之一是新的模块化结构。

TOGAF 标准现在由具有以主题为中心的结构的单独文档组成。此外，主题按其重要性和随时间的稳定性排序。这意味着基本的企业架构主题，例如 ADM，位于 TOGAF 的基础部分的中心。

相比之下，最佳实践位于 TOGAF 系列指南中，现在已成为标准的官方部分最后，

存储在 The Open Group Library 中的各种出版物和文档描述了新兴的和更不稳定的想法。这些包括袖珍指南、白皮书、指南、数据表、参考卡和其他有用的文档。TOGAF 10 具有模块化结构新结构很重要，因为大多数组织已经在运行企业架构活动。不同成长的组织需要不同的架构、流程和治理。使用旧的 TOGAF 版本，组织总是不得不删减一些零碎的东西来补充他们现有的流程和工件。TOGAF 10 的模块化结构使这变得更加容易。 Open Group 将此称为“主题支持”。

除了已建立的企业架构实践之外，还有其他原因导致从业者可能不想适应完整的 TOGAF 标准而是对其进行定制。哪种 EA 模型适合我的组织？EA公司的要求可能非常个性化。它们取决于一般参数，例如

• - 公司规模
• - 行业
• - 安全要求
• - 合规性要求

它们还取决于业务模型和竞争优势参数，例如

• - 客户前端
• - 数据集成
• - 数据货币化策略
• - 产品生命周期
• - 发布周期

最后，他们还取决于治理和运营模型决策，例如

- 敏捷性级别

- 决策机构谁应用企业架构，

谁使用 TOGAF 10？

除了上述参数之外，架构师工作的角色和用例对于决定是否和如何使用标准。例如，The Open Group 提到了与 TOGAF 10 相关的四个角色。这些是 EA 从业者、EA 顾问、EA 工具供应商和 EA 培训师。虽然每个不同的角色都会以不同的方式使用 TOGAF 10 标准，但我们今天关注的是 Enterprise Architect Practitioner 的子组。该角色可以进一步细分为需要为其战略、投资组合、项目或解决方案架构工作提供解决方案的角色。它们中的每一个都需要不同的框架、最佳实践和 EA 用例。幸运的是，EA 支持各种各样的用例。其中包括数字化、实现成本节约、简化和协调 IT 环境，以及提高可靠性和弹性。TOGAF 10 的模块化结构允许不同的从业者找到他们需要的东西旧的 TOGAF 版本具有相当单一的结构。如果您想申请 ADM，您必须阅读非常冗长的 TOGAF 标准的一半。在第 10 版中，向内容模块化方法的转变已经完成。

Open Group 现在为特定目的提供材料。这有助于企业架构从业者找到他们需要的东西。那是什么内容？TOGAF 10 基本内容以下文档是 TOGAF 标准基本内容的一部分：

• - 简介和核心概念（88 页）
• - 架构开发方法（ADM）（154 页）
• - ADM 技术（88 页）
• - 应用ADM（36 页）
• - 架构内容（120 页）
• - 企业架构能力和治理（64 页）

什么是 TOGAF 系列指南？

除了基本内容之外，TOGAF 系列指南还提供了以主题为中心的模块化最佳实践，用于应用企业架构.截至 2022 年 5 月，TOGAF 10 在 The Open Group Library 中包含 23 个 TOGAF 系列指南。它们是：

1. - 价值流
2. - 在数字企业中使用 TOGAF 标准
3. - TOGAF 数字业务参考模型 (DBRM)
4. - TOGAF 技术参考模型 (TRM)
5. - TOGAF 集成信息基础设施参考模型 (III-RM)：
6. 一种架构方法到无边界信息流-组织映射
7. -微服务架构（MSA）
8. -信息映射
9. -政府参考模型（GRM）
10. -启用企业敏捷性
11. -数字技术采用：准备评估和路线图开发指南
12. -业务场景
13. -业务模型
14. -业务能力（版本 1 和 2)
15. - 架构技能框架
16. - 架构成熟度模型
17. - 使用敏捷冲刺应用 TOGAF ADM
18. - 从业者遵循 TOGAF ADM 开发企业架构的方法
19. - 业务架构
20. - 使用 TOGAF 框架定义和管理面向服务的架构
21. - TOGAF 领导者建立和发展 EA 能力的指南
22. - 信息架构：Cus前主数据管理 (C-MDM)
23. - 架构项目管理

如何使用 TOGAF 10 的示例

让我们考虑一些人可能想要使用 TOGAF 10 的情况。他或她应该做什么？

• 作为企业架构领域的初学者, 我想了解基础知识，以便我可以快速为我的组织创造价值初学者想要了解基础知识，不想被大量信息和最新发展所淹没。因此初学者会考虑 TOGAF 的基础内容.特别是，他或她会从阅读引言和核心概念开始。通读前 88 页后，他或她将继续学习剩余的基础内容，或前进到适合他或她当前挑战的特定最佳实践指南。
• 作为正在运行的项目的云架构师，我想了解 TOGAF´ ■ 及时有效的云架构观点云架构师可能已经熟悉TOGAF 的基础知识。他或她不会阅读完整的文档，而是会对与云相关的特定主题感兴趣。浏览系列指南，以下内容会引起他或她的注意：
  • - TOGAF 集成信息基础架构参考模型 (III-RM)：
  • 无边界信息流的架构方法
  • - 微服务架构 (MSA)
  • - 使用 TOGAF 框架定义和治理面向服务的架构
• 作为产品负责人，我想了解我的开发团队所应用的业务能力的概念和方法，以便我们能够更好地协调所描述的产品负责人希望了解 TOGAF 描述的特定概念。新的主题结构允许他或她直接下载业务能力指南并开始阅读。
• 如您所见，不同的角色需要新 TOGAF 10 标准的不同内容。模块化的结构让不同的角色可以轻松专注于 TOGAF 10 值得他们阅读的内容！

 

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

TOGAF 10 最近发布。 对旧版本的主要更改包括对内容的重组，以便更容易理解、更少的不一致和更少的重复。

内容的模块化也取得了进展。 现在有六个单独的文档构成了 TOGAF 基本内容，目前在 TOGAF 系列指南中还有 23 个文档。 与微服务架构类似，这允许更轻松地使用或修改单个内容片段，并且还可以快速添加新内容。

TOGAF 标准现在正式包括在过去几年中添加到库中的 TOGAF 系列指南。 虽然起初这似乎是一个微小的变化，但这意味着 TOGAF 标准现在的内容发布和更新周期要短得多。 Open Group 已经表示，未来将如此。

此外，新版本提供了有关中心主题的更新和更详细的视图，例如信息和主数据管理、敏捷性、弹性和适应性。

最后但同样重要的是，TOGAF 词汇表内容已收到更新。已添加、更改或删除定义。

为什么需要新的 TOGAF 版本 10？

对 TOGAF 的一个主要批评是它包含相当陈旧的内容，在很大程度上已经过时了。例如，旧版本没有充分或从十年前的角度解决数字化、云计算和敏捷主题。

此外，TOGAF 标准很难阅读、太长，而且结构相当单一。 TOGAF 标准在 9.2 版中几乎没有改变，但是通过系列指南建立了新的和更现代的内容，并添加到了 The Open Group Library。因此，除了来自其他组织和公司的内容之外，这些资源作为架构工作的输入变得更加相关。

很高兴看到 The Open Group 在版本 10 中解决了其中的许多批评。

TOGAF 10 如何改变 TOGAF 标准的相关性？

我在另外几篇文章中详细分析了 TOGAF 9.2 的相关性。我的结论显示结果喜忧参半，TOGAF 的特定方面已经过时，而其他方面仍然相关。

基本 TOGAF 内容

我认为今天仍然相关的内容主要是关于基本架构方法、框架、元模型和治理。回顾 TOGAF 的基本内容可以发现，这些内容构成了新版本中最大的部分。

TOGAF 10 认证

在通过 TOGAF 10 认证发出信号方面，我认为没有任何改变。对于寻求新工作机会的企业架构师来说，拥有 TOGAF 认证一直是非常有益的。新版本不会使任何事情变得更好或更糟。

TOGAF 10 内容更新

在新版本中更新了很多我认为过时的内容，例如关于数字和敏捷的内容。这两个主题现在都有专门的系列指南。此外，隐私、架构服务、架构替代方案和业务场景等主题获得了额外的部分或描述。

我发现 TOGAF 词汇表的更新特别有价值。对于许多组织，即使是那些不严格遵循 TOGAF 标准的组织，这些定义为其组织范围内的一致性和共同基础奠定了基础。很高兴看到它们现在是最新的并且与当今的 IT 环境兼容。

TOGAF 10 中的业务和 IT 受众

最后但同样重要的是，新版本指定了 TOGAF 标准的受众。不同的角色被分别处理，以定制他们对内容的个人体验。其中包括企业架构从业者、企业架构团队的领导者和企业架构团队的发起人。这是一个好主意，因为企业架构在组织和业务利益相关者中变得越来越普遍，现在积极执行企业架构活动。如果您是这样一个团队的一员，我建议您对 TOGAF 有基本的了解。

TOGAF 10 值得吗？

自然，新版本并没有完全涵盖我的想法和改进的愿望。例如，TOGAF 架构开发方法 (ADM) 仍然具有相同的阶段，并不能反映当今在安全和数据架构方面的架构优先级。我也希望看到业务利益相关者比今天更多地参与其中。

然而，新的 TOGAF 版本给我留下了非常好的印象。许多缺点和批评已得到解决。 TOGAF 作为一个易于理解和兼容的框架，以及一组支持和指导的文档，变得更加相关和有价值。

新版本通过内容更新使 TOGAF 更有价值，特别是因为更容易找到您需要的内容，易于应用整个框架的各个部分，以及允许更频繁地更新标准的新结构。

原文：https://digitalroadmap-management.medium.com/what-makes-togaf-10-a-valu…

本文：https://jiagoushi.pro/what-makes-togaf-10-valuable-contribution

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

在今天的第四部分中，我谈到不同云组织提供的培训包含重要的 IT 和企业架构方面。此外，现代、敏捷的框架涵盖了企业架构的管理方面。

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

谁仍然对企业架构感兴趣？

– 第 4 部分，共 6 部分

EA 最佳实践也受到云组织提供的培训的推动

在上一部分中，我们认为 IT 和企业架构对于现代云提供商和云组织具有高度重要性。因此，云解决方案架构师的角色是 AWS、Azure 和 GCP 最重要的角色之一。因此，获得此类角色证书的课程不仅关注云和 IT 架构方面，还包含企业架构元素。这些要素包括：

• 一般订阅管理，
•  云成本管理，
•  混合或多云管理，
•  以及与非云系统的数据流/接口。

敏捷框架为 EAM 的管理方面提供最佳实践

因此，技术和架构最佳实践主要由云提供商和云组织推动。但是，还有更重要的方面需要考虑。其中包括：

•  EA 角色，
• 责任，
• 委员会，
• 和决策过程。

传统建筑设计机构或建筑治理委员会的现代替代方案涵盖了这些方面。它们由多个敏捷框架提供，其目标是在整个部门和组织中建立敏捷流程。规模化敏捷框架的一个突出例子是 SAFe。它定义了企业架构师的角色，将其置于其精益投资组合管理层。

然而，不仅 SAFe，其他框架也提供了使组织和流程现代化的解决方案。另一个例子是有纪律的敏捷或 Spotify 模型。例如，他们提议将公会作为跨越组织层级和部门的网络或人员社区工作。如果您想了解更多关于 EA 地区社区的好处，请查看相关文章。

你对今天这个系列的部分有什么看法？很高兴在下面阅读您的评论！

原文：https://digitalroadmap-management.medium.com/who-drives-modern-ea-best-…

本文：https://jiagoushi.pro/who-drives-modern-ea-best-practices-and-content

Salesforce 运营、治理和架构框架 (SOGAF) 将 MIT-CISR 企业架构框架应用于 Salesforce 实施和程序。

介绍

为共同实体（即卓越中心）制定一个明确的定义是很棘手的。 转换程序中的通用实体 (CoE) 有多种名称：

1. “卓越中心”、“C4E”、“专业中心”、“专家网络”
2. 术语“设计授权”或“平台授权”也用于通用实体，这会造成一些混淆
3. 不同的描述会导致不同的期望——当没有得到满足时会感到沮丧
4. 此类问题在难以确定是转型、能力还是最佳实践中心的实体中很常见

共同实体也可以扮演任意数量的这些角色，增加了混乱：

毕竟，通用实体 (CoE) 什么都做。

• 这是转型计划与政府最接近的事情，跨部门工作
• 有时它是裁判，确保业务和 IT 都遵循平台“规则”
• 有时它是经纪人，在 LoB 或市场之间达成妥协
• 从一些 LOB 或市场的角度来看，它是一种资源，遵循它们的优先级

在 SOGAF 中，Common Entity 的使命围绕着 4 个组成部分和 20 项活动展开，重点是建立运营模型的目的、愿景、价值观、角色、流程和指标。

主要考虑因素

• 建立序列以帮助组织学习数字思维方式
• 设计、构建、实施和支持体验的策略和定义
• 分享小组实践并为类似小组之间的标准化和重用创建指南
• 专注于通过专业知识和指导持续改进，提高团队能力
• 测试新的业务模型、流程和功能，以消除摩擦并识别新的客户体验。

组件

下图描述了 4 个组件（项目和产品管理、平台和产品支持、产品开发和平台优化以及采用和运营）及其主要职责。

活动

下表将上述每个组件的职责扩展为成功的关键活动。

CoE 组件	关键活动
CoE Mgmt & Salesforce PMO	设置 CoE 目标、范围和计划、预算、规模和风险管理、人员/团队管理、员工入职和报告
Bus. Reqts, Value & Change Control	需求管理、项目范围治理会议、变更控制委员会会议、利益相关者升级、
Product Portfolio & Innovation	设立创新实验室和创新中心（福传）。 产品组合管理/3 次年度发布，构建 POC/原型
Security & Compliance/ regulations	与公司安全准则保持一致，在计划中实施安全护栏，对员工和承包商进行合规培训
Architecture Oversight	组织战略、配置和代码质量、集成、数据量、归档、备份和恢复、CD/CI 的监督和专业知识
Design Authority	建立、拥有和应用原则、标准、政策。 保证合规性和质量（用户体验、应用程序、数据、安全性、重用、可扩展性和可持续性）。 确保灵活性以满足业务需求并利用新技术，包括 AppExchange
Product/ Platform/ CoE Standards	为平台和应用程序的实施、部署和维护定义规范和 SOP、可重复的方法
Roles & Skills, Communications	定义角色和技能、培训路径和证书、工具包。 就新功能、计划升级和服务中断进行沟通
Internal projects consultancy & QA	项目 QA 方法（敏捷、混合、瀑布）和用于发现、设计、构建、测试、部署的工具； 评论和专业知识
Shared service for product devt	拥有资源、团队、组织（包括 PO）和工具包，能够以工厂模式交付产品——单独或与 SI 一起交付
Best practice Community	定义、验证和传播流程、工作方式、经验教训和解决方案配置，无论是强制性的还是临时性的
Reusable Assets Mgmt	收集、集中、管理和流通潜在资产（解决方案配置、代码、集成模式、文档）
Environment Mgmt	支持所有环境——从沙箱到生产、营销 BU 等——监控状态和质量。 数据和元数据迁移
Release Mgmt & Integrations	使用工具建立主要和次要发布时间表。 监督版本控制、分支、频率、组件、集成
Data Migration & Quality Mgmt	监督数据模型和元数据，更新生产数据、数量、质量、合规性以及数据报告
License & Usage Mgmt	监控 Salesforce 许可证的使用情况并定期更新使用情况。 工具选择
Deployment, Training, Adoption, NOE	流程/LoB/市场最终用户部署和培训。 应用程序和业务采用。 卓越网络
Administration – App, UI, Data, Platform	运行应用程序 - UI 和使用（Lightning/Mobile）、自动化、标准和自定义对象、报告和仪表板、Chatter。 数据。 运行平台环境、归档、备份和恢复。 监控、安全。 发布和路线图 (SF)
Access, Identity, Authorization	用户配置、授权和访问（Profile & P-set）。 身份和 SSO、身份验证、证书、（停用）
End User Support & Ticketing	运行票务流程。 解决级别 2（管理员）并与 L3（开发）（应用程序缺陷）和/或 L4 (SF) 协调以获得支持

原文：https://architect.salesforce.com/govern/change-management/sogaf-coe/

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

项目上下文图显示了作为更广泛的转型路线图的一部分来实现的工作包的范围。项目上下文图将工作包与将被添加、删除或受项目影响的组织、功能、服务、过程、应用程序、数据和技术联系起来。项目环境图对于项目组合管理和项目动员也是一个有价值的工具。

UML/BPMN  EAP Profile 

External actor: An actor that is external to the enterprise.

Internal actor: An actor that belongs to the enterprise.

Requirements: In this context, these are business requirements.

Interaction application component: Represents the top level components that manage the interaction with elements outside the IS. In most cases, it is a GUI component, such as here a web interface.

Database application component: Represents a repository. In pure SOA architecture, these elements should not appear. However, for legacy analysis or technology architecture, modeling repositories or repository deployment can be useful.

Application: This application component corresponds to legacy applications, off the shelf products, or can be an assembly of application components.

System federation: A system federation is the coarser-grained application component. It assembles systems to federate them, such as in the example of cooperation between different information systems between different companies.

Use case: Represents an interaction between an actor and the system, in order to fulfill a business need. A use case is further described by a set of scenarios that express the interactions between the system and the actors.

Business service: Represents a service provided by the business, which may then be realized by one or more IS services.

Business process: As presented in process maps (event diagrams). The business process is detailed in flow diagrams.

Information flow: dDefines the flow of any kind of information (business entity, event, product, informal, etc) between active entities of the enterprise.

Consumes link: Expresses that participant (e.g. an actor) consumes an element of the IS (service, operation, application component).

Realizes link: Component realization. An application component realizes the designated element, for example a business process.

Satisfy link: Expresses that an element of the IS satisfies a requirement.

Archimate :

在这个图表中，上下文的中心是“DiscountTravelOrderingSite”。

原文：https://www.togaf-modeling.org/models/opportunities-and-solutions/project-context-diagrams.html

本文：

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

视图是ArchiMate中非常重要的概念之一。每个视图都包含一组专用的ArchiMate元素，允许架构师设计人员对企业架构的特定方面建模。正式的ArchiMate 3规范提供了23个ArchiMate示例视图供架构设计人员遵循。在这个ArchiMate视图指南中，我们将回顾所有23个ArchiMate视图，并对每个视图进行清晰的描述和ArchiMate图表示例。

什么是ArchiMate视图?

在ArchiMate语言中，视图是ArchiMate元素和关系的相关子集，在表示体系结构的特定部分时，将它们放在图上。

什么是ArchiMate示例视图?

ArchiMate建议了一组可以用作建模工作的起点的示例视图。每一个ArchiMate视图都包含来自不同ArchiMate层的元素，处理特定的涉众关注点。欢迎组织在其体系结构模型中应用任何这些视图示例，或者定义他们自己的视图示例。

ArchiMate建议的示例视点主要分为四类:

• 基本视图:可以使用来自业务、应用程序和技术三层的概念。
• 动机视图:用于建模架构的动机方面。
• 战略视图:通过描述企业的高层战略方向和构成来描述企业的战略方面。
• 实现和迁移视图:对于架构变更的管理建模，从基线到目标架构的转换以及程序和项目之间的关系。

如何应用示例视图?

重要的是要注意ArchiMate规范中正式发布的示例视点不应该约束建模活动。您应该修改示例视点，或者甚至定义您自己的视点来处理特定的涉众关注点。

 

基本视图

ArchiMate基本视图包括ArchiMate元素和ArchiMate三个主要层的概念:业务、应用程序和技术。下面列出的是ArchiMate 3.1示例视点表，分为四类，指明了它们所涵盖的方向和范围:

• 组合:定义元素的内部组合和聚合的视图。
• 支持:您所查看的元素被其他元素所支持的视图。通常从一层往上到上一层。
• 合作:朝向相互合作的对等元素。通常跨不同的方面。
• 实现:您正在查看实现其他元素的元素的视图。通常从一层向下到下一层。

 

组成视图

名字	透视图	关注点
组织	企业在角色、部门等方面的结构。	识别能力、权力和责任
信息结构	显示企业中使用的信息的结构。	使用的数据和信息的结构和依赖关系，一致性和完整性
技术	网络、设备和系统软件等企业信息系统的基础设施和平台。	基础设施的稳定性、安全性、依赖性和成本
分层	提供架构的概述。	一致性、降低复杂性、变更的影响、灵活性
物理	物理环境以及它如何与IT基础设施相关联。	物理环境的关系和依赖关系，以及它们与IT基础设施的关系

支持视图:

名字	透视图	关注点
产品	显示产品的内容。	产品开发，企业产品提供价值
应用使用	将应用程序与其在例如业务流程中的使用关联起来。	一致性和完整性，降低复杂性。
技术使用	展示应用程序如何使用技术。	依赖关系、性能、可伸缩性

合作视图:

名字	透视图	关注点
业务流程合作	显示各种业务流程之间的关系。	业务流程、一致性和完整性、责任之间的依赖关系
应用合作	显示应用程序组件及其相互关系。	应用程序之间的关系和依赖、服务的编排/编排、一致性和完整性、复杂性的降低

实现视图:

名字	透视图	关注点
服务实现	显示如何通过必要的行为实现服务。	业务流程的增值、一致性和完整性、责任
实现和部署	显示如何将应用程序映射到底层技术。	应用平台的结构以及它们与支持技术的关系

在接下来的部分中，我们将详细介绍ArchiMate的所有基本视图。对于每一个视点，涉众都是有目标的，要处理的关注点，目的和范围都被涵盖了。此外，还将提供ArchiMate图示例。

除了指定的元素之外，分组元素、连接和或连接可以在每个视点中使用。

 

原文： https://www.visual-paradigm.com/guide/archimate/full-archimate-viewpoints-guide

本文：http://jiagoushi.pro/node/1309

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

价值链图提供了企业的高级方向视图，以及企业如何与外部世界进行交互。与阶段B(业务体系结构)中开发的更正式的功能分解图相比，价值链图关注于表示的影响。此图的目的是为了快速地将涉众与特定的变更活动结合起来，以便所有的参与者理解架构约定的高级功能和组织上下文。通常的做法包括显示一个简化的业务流程图，并为每个任务定义其价值因素和所需的更改。

UML/BPMN EAP Profile 

Function: Describes one function of the organization

Sequence link: Represents a sequence between functions.

Archimate 

折扣旅游公司的价值链

原文：https://www.togaf-modeling.org/models/architecture-vision/value-chain-diagrams.html

本文：

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

所有人都可以看到我征服的这些战术，但没有人能看到的是战胜胜利的策略。

 - 孙子

 

Enterprise Architect推动自适应设计和工程实践，并推动产品组合的架构计划。 Enterprise Architects还促进了投资组合中各种解决方案的思想，组件，服务和经过验证的模式的重用。

糟糕的战略技术规划，沟通和可见性可能导致整个企业的系统性能不佳，从而促使重大的重新设计。为了防止这种情况，并支持当前和近期的业务需求，这些系统通过一些架构跑道和架构治理（例如，在整个企业解决方案中推动通用可用性和行为构建）而受益。为了解决部分问题，SAFe强调了系统和解决方案架构师的角色，他们在计划和大型解决方案级别提供了大部分指导。

在投资组合层面，挑战更大。兼并和收购，基础技术和竞争的变化，新兴标准以及其他因素往往会使企业超出敏捷团队的范围。为了解决这个问题，Enterprise Architects拥有跨解决方案培训和敏捷发布列车（ART）的权威和知识。他们可以提供可以改善结果的战略技术方向。该策略的各方面可能包括开发和交付技术堆栈，互操作性，API和托管策略的建议。这些方法产生了结果，因为Enterprise Architects在与团队工作保持联系的同时促进了增量实施。

细节

总结角色描述

Enterprise Architects与业务利益相关者以及解决方案和系统架构师合作，实施跨Value Streams的技术计划。他们依靠持续的反馈，促进适应性设计和工程实践，并推动计划和团队围绕共同的技术愿景团结起来。

责任

Enterprise Architect主要关注以下职责：

•     与精益投资组合管理协作，提供企业解决方案和开发计划的高层次，全方位的愿景
•     通过Enabler Epics定义支持精益预算的关键技术计划
•     帮助价值流坚持退休解决方案的预算护栏（地平线0）
•     参与建筑和维护建筑跑道的战略
•     理解并向系统架构师和非技术利益相关者传达战略主题和架构的其他关键业务驱动因素
•     推动Portfolio Kanban系统中的架构计划，并在适用的情况下参与史诗分析
•     影响常见的建模，设计和编码实践
•     促进持续交付管道和DevOps功能
•     收集，生成和分析在整个企业中使用的创新想法和技术
•     促进代码，组件和已证实的模式的重用
•     在适用的情况下，跨解决方案同步以下规则：
  • 系统和数据的安全性和质量
  • 生产基础设施
  • 解决方案用户体验（精益UX）
  •  可伸缩性，性能和其他非功能性需求（NFR）

企业架构战略

企业拥抱组织变革的能力是关键的竞争优势，企业架构战略是一个至关重要的因素。 图1说明了这种策略的五个关键方面，下面简要介绍每个要素。

图1.企业架构策略的五个要素

1.     技术和用途的选择 - 选择合适的技术是战略制定的关键要素。支持活动包括研究和原型设计，了解适用性和范围，以及评估创新技术的成熟度。
2.     解决方案体系结构策略 -  Enterprise Architect与解决方案和系统架构师密切合作，确保各个计划和产品策略与业务和技术目标保持一致。例如，针对本地问题的新兴解决方案应与整体企业战略保持一致。如果情况并非如此，则应明确决策，因为不一致的选项可能会影响未来的企业战略。
3.     基础设施战略 - 当它正确地履行其职能时，开发和部署基础设施就会被忽视。但是，构建和维护基础架构的策略是一项关键挑战，与System Architect职责重叠。其中一些职责包括重用配置模式，通用物理基础设施，跨ART和解决方案列车的知识共享，尤其是系统团队。此外，一些开发和部署基础架构可能与内部IT系统相交叉。企业架构师也可以在那里提供方向。
4.     跨计划协作 - 架构工作的各个方面发生在不同的团队和计划中。这就是为什么确保在适用时使用通用技术，设计实践和基础设施是有帮助的。然而，价值流和ART具有足够的自由度也很重要。否则，创新就会减少。因此，应通过联合设计研讨会，设计实践社区（CoPs）等在ART之间积极共享共同和可变的架构方面。
5.     实施战略 - 有效，渐进的敏捷实施战略的重要性几乎不为人知。将业务史诗的技术基础构建到建筑跑道必须是一个渐进的过程。持续的技术学习和快速反馈使架构和业务功能随着时间的推移同步增长。敏捷团队和程序在必要时进行重构并保留多种可能的设计选项的能力支持这一点。抽象和泛化有助于过早地避免绑定特异性，这为未来的业务需求保留了架构灵活性。

尊重个人和不懈改进

精益敏捷心态创造了一个健康的环境，每个人都在事实而非假设的基础上运作。这对于企业架构师来说尤其重要，他们在日常开发活动中执行一个（或两个）步骤。这就是为什么企业架构师通过以下活动明智地保持与每个ART，解决方案培训和架构师的个人联系：

•     收到有关当前企业范围计划的反馈
•     参与架构和设计CoP
•     在重要的重新设计或基础工作正在进行时参加演示

开发人员和测试人员将更好地信任由了解当前挑战和背景的人所驱动的策略。同样，Enterprise Architect将更好地信任提供其当前上下文完全可见性的团队。

学到更多

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[2] Bloomberg, Jason. The Agile Architecture Revolution. Wiley, 2013.

[3] Coplien, James and Gertrud Bjørnvig. Lean Architecture: for Agile Software Development. Wiley, 2010.

 

原文：https://www.scaledagileframework.com/enterprise-architect/

本文：https://pub.intelligentx.net/safeenterprise-architect

讨论：请加入知识星球或者小红圈【首席架构师圈】

我们要权衡什么以及为什么要权衡？

我们所说的“软件架构”有很多定义和含义。构成“软件开发”、“软件设计”和“软件架构”的内容之间也存在相当大的重叠，因为这三个概念在许多方面融合在一起。

从本质上讲，它有助于将软件架构的学科视为在我们以这种或那种方式构建应用程序时做出的选择所产生的权衡之间做出有意识选择的学科。

为什么会有权衡，我们为什么关心？

我们在选择如何构建软件时必须进行权衡的原因与我们在其他学科中进行权衡的原因相同。计算系统很复杂，复杂度越高，我们为特定系统实现全方位目标的方式就越微妙。这些目标可以是功能性的（即为用户提供自助服务、处理特定事件、接受一些输入和产生输出的能力）也可以是非功能性的（即每秒处理数百万个请求的能力，实现零信任安全性） ，低于 100 毫秒的响应）。

例如，在金融投资中，对风险和回报之间的权衡有着内在的理解。一项投资的风险越大，其潜在的经济回报就越大。投资越安全，我们可以从该投资中预期的收益就越小。

同样的规则也适用于计算——尤其是在构建分布式应用程序时。许多组织遇到的问题不是他们必须做出某些让步或权衡。问题在于，大多数组织要么没有意识到他们正在做出的权衡，要么缺乏系统、清晰和有效的方法来进行这些权衡。

这个“架构权衡”系列的目的是在涉及到软件架构的不同原则之间的权衡以及此类决策的具体技术含义时，阐明决策过程。

我们在权衡什么？

正如我们在上面看到的，与您的系统和应用程序架构相关的大多数决策都涉及某种程度的权衡。

既然我们知道为什么架构权衡是需要讨论、权衡和有意识地推理的事情，我们就可以谈谈我们实际上在权衡系统和应用程序的哪些方面。

这些架构权衡有时分为两大类。第一个与关于系统的基本架构特征（即可扩展性与简单性）的决策有关。第二个与更具体的技术、机制和架构风格（即同步通信与异步、Kafka 与消息总线等）的决策有关。前者，更一般的权衡类别，也决定了更具体的权衡。

在本文中，我们将重点关注第一类架构权衡——即基础架构特征。

因此，当我们谈论架构权衡时，我们实际上是在谈论我们想要支持哪些架构特征并将其纳入我们的主要目标。硬币的另一面是，我们也在识别那些我们有意识地决定较少关注或完全放弃的架构特征，以支持我们认为更重要的那些特征。

下面是几个架构特征和一些常见权衡方案的示例。

建筑特点

在谈论系统或应用程序架构的固有或基础特征时，我们实际上指的是表征特定系统或应用程序的关键属性的集合。以下是这些特征的一小部分作为示例。无论如何，这不是一份详尽的清单。还有许多其他的建筑特征

• 可扩展性
• 可观察性
• 可审计性
• 弹力
• 响应能力
• 可测试性
• 互操作性
• 可维护性
• 可支持性

这些特征有时被称为“系统属性”、“架构属性”或通常简称为“ilities”。

乍一看，这些系统特征或属性似乎彼此独立。但实际上，它们中的许多都非常交织在一起，可以具有直接或反向的关系。

互操作性与可扩展性、弹性和响应性

让我们以互操作性为例。为了使系统具有互操作性，它需要能够轻松地与其他系统交互和通信。这通常意味着所有这些系统都需要使用通用协议。他们需要使用共同和商定的标准，这些标准的构建方式也使得未来的系统也可以相对轻松地“插入”到该通信中。

但是，如果互操作性是系统的优先事项，那么这很可能会影响系统的扩展能力。

要将这一切归结为一个具体示例，请考虑一个场景，您有一些使用 REST 协议（依赖于 HTTP）进行通信的现有应用程序。假设我们正在引入一个新系统。为了使这个新应用程序可以与现有应用程序互操作，我们决定这个应用程序的所有入站和出站通信也将通过 REST/HTTP 完成。这似乎是有道理的。

但是，如果您的新系统需要处理大量请求，则将您的新系统限制为依赖于 HTTP 的通信可能会限制其响应能力和可扩展性。想象一下，这个新系统必须每秒处理来自该调用者的数百万个请求，并且也是异步的（即调用者不需要等待应用程序确认它已经处理了请求）。由于对异步的要求以及专有的 Kafka 协议（至少在理论上）比 HTTP 的开销更少，因此这种情况可能更适合 Kafka 等事件驱动技术。

换句话说，在这个特定场景中，互操作性与响应能力和可扩展性成反比关系。

简单、易于上手和可支持性与响应性

在决定将相对容易支持的架构作为主要架构驱动程序时，可能会发生另一个技术性更少但组织性更强的权衡。这可能意味着使用组织内技术团队熟悉的技术。这也可能意味着使用业内广为人知和使用的技术和范式，以便新的团队成员可以更快、更高效地开始使用它们。

将可支持性作为首要任务听起来很容易，因为谁不想要一个易于理解、支持和介绍给新开发人员的系统？不过，与往常一样，存在成本和权衡。

根据大量专业人士所了解的技术或范式来选择它们可能会阻碍我们架构的许多其他特征。系统的可扩展性、响应性、弹性、可用性、安全性和许多其他方面很可能会排在第二位。

例如，考虑一个需要设计一个需要处理和存储事务性和强关系数据的金融应用程序的情况。假设实现此应用程序的团队熟悉 MongoDB 等 NoSQL 数据存储。现在，虽然 Mongo 是松散相关文档类型数据的绝佳选择，但它并不适合具有严格和复杂相互关系的数据。

不同实体具有复杂关系以及需要临时复杂查询来检索该数据的数据通常不适合 Mongo 之类的东西。这种类型的数据通常更适合“传统”关系数据库，例如 Postgres 或 MySQL。

如果我们将可支持性作为这个应用程序的主要架构驱动因素，它很可能会设置应用程序以防万一，并会引入一系列挑战，最终导致应用程序完全无法扩展，并且数据库成为一个展示 -塞子瓶颈（通常是这样）。

寻找平衡

上述架构权衡的三个示例可能更多地涉及极端情况。然而，它们代表了许多团队和组织在规划和选择正确的架构权衡导航过程中面临的一些非常现实的挑战。

好消息是您不一定非要选择其中之一。软件架构权衡和一般软件开发的现实要微妙得多，并且确实代表了选项的梯度。例如，您可以在此处选择具有一定程度的可扩展性，同时具有一定程度的简单性和互操作性。

关键是要知道如何在不同的架构特征之间找到平衡，并知道如何对这些特征做出明智的、有意识的选择。

有意识并意识到架构权衡

正如我们在开始时所说的，我敢说，许多组织——大多数组织都会无意识地选择权衡取舍。这通常会导致这些组织做出错误的权衡，这对他们的业务和底线产生长期且有害的影响。

由数字系统驱动的企业必须制定适当的计划和流程来制定软件架构、技术决策和权衡。如果没有围绕架构权衡建立适当的意识，这些组织会承担不合理的风险，其影响和可能性都很大，在最好的情况下会显着减慢组织的进度，在最坏的情况下会损坏到无法修复的程度。

下一部分将讨论这一点——如何为架构权衡以及一些特定和常见的情况进行推理和规划。

原文：https://medium.com/@yt-cloudwaydigital/software-architecture-tradeoffs-…

本文：https://jiagoushi.pro/software-architecture-tradeoffs-series-part-1