博客

 作者：The Open Group
 

为探讨组织如何能通过综合利用标准来更好地推进必要的转型和变革，本博客发表了系列专题文章，本文系BiZZdesign管理顾问Marc Lankhorst 访谈实录的第二篇。
 

交付Enterprise Architecture (EA) 时面临的关键难题之一是解决不同利益相关者关心的问题。您如何看待EArchiMate®标准（一种The Open Group标准）与此的关系？您是否认为应该应用ArchiMate 建模语言来解决所有利益相关者关心的问题？
 

一种符号并不能满足所有受众的要求。ArchiMate 符号为专家提供了详细的图表，但如果您是业务用户，则需要不同的视图。ArchiMate 语言能够将可视化与底层模型相分离，所以您可以为不同的利益相关者构建视图。
 

“一种符号走天下”是行不通的；基于相同的模型可以生成不同的视图，所以可以使用不同的规范和符号来共享和呈现该模型的各个部分。相关数值存在于底层模型中，可以使用不同的可视化技术加以呈现。当然，这些视图可以是图示，也可以是事物列表（目录）、矩阵图或草图、动画或信息图。除这些可视化内容之外，您还可以添加颜色视图、热图等，并通过基于能力的规划、风险评估、变更影响、成本分析、变更计划优先级等分析解决不同利益相关者关心的问题。
 

您能否提供有关ArchiMate 建模语言如何与面向实施的建模符号（如UML 或BPMN）相关联的更多细节？如何解决可追溯性和集成问题？ 鉴于从业者通常拥有不同的工具套件，如何能实现全面实施？
 

ArchiMate 建模语言的设计初衷就是与UML 或BPMN 等其他建模符号相关联。出于这个原因，该语言中的一些概念“借用”了其他语言，所以会有一些重叠。例如，ArchiMate 应用构件概念与UML 构件概念之间具有一致性，所以您可以轻松地从架构层面迁移到更详细的设计。其他更多相关示例详见我的下列博文：https://bizzdesign.com/blog/combining-archimate-3-0-with-other-standards-uml-sysml-erd/.在使用BPMN 设计详细的业务流程时，或者为建模者创建详细的数据模型提供实体关系图，也可以采用类似的方法（详情请参阅https://bizzdesign.com/blog/combining-archimate-3-0-with-other-standards-bpmn/）。
 

有时，这种方法反过来同样奏效。如果没有可用的架构描述，则您必须反向设计不同的模型，并进行更高级别的集成，以创建您的Enterprise Architecture (EA)。您还可以从您的CMDB 中获取关于基础架构的信息，并进行更高级别的集成。
 

业务架构也可以使用ArchiMate。它通常始于组织的战略、动机以及业务模式，可通过商业模式画布(BMC) 等技术进行呈现。您可以从中识别能力、价值流和实现它们所需的资源（如人员、信息、系统、物理和其他资产）。就流程、应用、基础架构等而言，这就是Enterprise Architecture (EA) 核心的出发点，并与前面描述的详细设计息息相关。所以有不同的方法进行此类集成。
 

ArchiMate 建模语言旨在提供针对不同层面和不同方面的高级架构描述。其中一个方面便是动机和策略，您是否认为该语言自身就可以解决特定受众的问题，还是最好将其与BMM 等其他符号进行集成？
 

一些ArchiMate 动机概念借用了业务动机模型的概念（与UML 或BPMN 一样），因此很容易进行集成。您还可以从ArchiMate 模型映射到平衡计分卡和商业模式画布等战略级模型。例如，BMC 主要活动与ArchiMate 能力关系密切，关键资源可以映射到ArchiMate 资源，其他概念也可以轻松映射。如欲了解关于这些映射的更多信息，请参阅我的下列博文：https://bizzdesign.com/blog/combining-archimate-3-0-with-other-standards-bmm-bs-bmc/.
 

此外，为支持指标和KPI，还可以添加一些额外数据。具体方法是使用标准中描述的ArchiMate 配置文件机制，其中配置文件是面向某些特定用途的一整套属性。
 

这是一种极为有效的方式，可将业务和战略观点与运营和技术平台联系起来，并在秉持战略意图的情况下做出技术投资优先级等决策。
 

实施EA 时面临的挑战之一是将EA 框架（如TOGAF®标准，一种The Open Group 标准）与其他管理实践（如项目管理、项目和项目组合评估、风险评估等）联系起来。ArchiMate实施和迁移层如何与项目管理等实践一起提供并实施架构？对此您有何高见？
 

此处要强调的核心概念是Plateau 概念，即中转架构和过渡架构，支持您进行规划并考虑不同的规划选择和方案。此外，这个概念还应该与项目和项目组合管理的长期路线图相关联。
 

只有这样，才能够提供描述这些路线图的各种视图，并透过它们背后的架构来分析依赖关系，如查看延迟项目的影响。在架构模型中，您可以跟踪需要项目结果的对象，在这个过程中，您可能会发现一些应用因缺少这个项目结果而无法运行。在典型的规划和项目管理环境中，这类信息通常不可用，所以显得更为珍贵。
 

在敏捷方法中，架构跑道概念是这种方法支持的另一个相关主题。架构跑道有助于协调多个敏捷团队，并为他们的工作提供架构环境，以便他们能够在更快地交付架构的同时跟踪高级系统视图。
 

在技术层面，您可以将架构工具与项目管理环境（如Jira）集成在一起。 正如我在相关博文中所描述的那样，用户故事、特性、剧本（epic）和其他敏捷概念都可以轻松映射到相应的ArchiMate 概念中。如之前所述，您可以通过这种集成评估如果团队决定将某些特性设置推迟到下一个迭代中，总体结果会发生什么变化。
 

项目成本、风险和收益等其他信息都可以使用之前描述的配置文件机制与您的模型相关联，您可以使用这些信息进行各种交叉分析。
 

当前的业务和技术发展趋势要求进行大量集成，并了解客户旅程标识以及如何改进并提供真实的数字客户体验。ArchiMate 标准如何满足这一需求？
 

客户旅程地图也可以用ArchiMate 概念进行描述，详情请见：https://bizzdesign.com/blog/archimate-3-0-and-customer-journey-maps/。根据我的经验，ArchiMate 模型的这种可视化表示在市场营销等环境中非常有效。
 

在ArchiMate 论坛中，我们还讨论了对价值流等新概念的需求(https://bizzdesign.com/blog/why-adding-a-value-stream-element-to-archimate-is-key/)。这对市场营销和运营人员来说也大有用处。
 

谈到数字化，就不可避免地会提到云。从一开始，ArchiMate 语言就以服务为导向，这种从内部工作中提取出来的服务概念也是描述云解决方案的理想方法。
 

 数据管理和治理以及数据隐私都是需要解决的关键问题。如何使用ArchiMate 标准解决这些问题？这种方法是否也可以用来描述数据安全性和风险因素？ 
 

使用更详细的符号（如UML）可以更好、更容易地描述详细的数据模型，但是对于更高级别的视图或数据治理问题（如GDPR），您可以分析何时何地使用哪些数据、与谁共享数据以及如何保护数据。使用之前提到的配置文件机制对数据流和信息交换进行建模，并为您的数据添加隐私和安全属性，能够为您进行分析奠定良好的基础。如此一来，您便可以说明如何使用和存储数据，以及这是否符合适用的安全和隐私要求。
 

总结：ArchiMate建模语言需要与其他标准和符号一起使用。它并不是一种独立的语言。其在设计过程中的一个关键考虑因素是如何根据具体需求集成其他符号和实践。该模型可针对不同的利益相关者进行可视化分离，这点也非常重要，不容忽视。
 

点击此处，在领英上了解有关Marc 的更多信息。