架构师篇-5、架构语言-ArchiMate

进步一下

于 2024-06-27 17:10:36 发布

阅读量1.1k

点赞数 15

文章标签：经验分享

本文链接：https://blog.csdn.net/shanshe7934/article/details/139927291

版权

内容摘要：

TOGAF内容元模型
TOGAF架构语言ArchiMate3
ArchiMate实践案例分享

TOGAF内容框架【核心内容元模型】

在这里插入图片描述
作为一个通用且开放式的标准，TOGAF需要采用一种非常灵活的方式来对其内容元模型进行定义，从而使得不同的企业可以根据自身需要对其进行裁剪和改造。为了达到这一目标，TOGAF中的内容元模型将所需构建块类型的最小集合定义为核心内容元模型，并在此基础上使得整个元模型体系能够支持后续扩展内容的插入。

TOGAF内容框架【内容元模型各实体及其关系】

在这里插入图片描述

在这里插入图片描述
下图展示了内容元模型中所包含的各个实体以及他们之间的关系，并通过图例标明了每个实体所隶属的扩展部分。

TOGAF内容框架【企业架构开发方法各阶段中的内容元模型实体】

在企业架构开发方法的进行过程中，各个阶段都会涉及到一些相关的构建块，而下图展示了他们之间的关系。
在这里插入图片描述

TOGAF企业连续体和工具之架构资源库及架构工具

在这里插入图片描述

问题：
企业架构设计用过哪些工具？
Visual Paradigm
Archi
drawio（推荐）直接有Archimate的支持
Enterprise Architect
beeart（ddd推荐）

Archimate3.0映射TOGAF的ADM

在这里插入图片描述
ADM的各个阶段对应的ArchiMate建模视图如下：

预备阶段和架构前景阶段使用ArchiMate的战略&动机层进行建模
业务架构阶段使用ArchiMate的业务层进行建模
信息系统架构阶段使用ArchiMate的应用层进行建模
机会和解决方案阶段、迁移计划、实现治理阶段使用ArchiMate的实现&迁移层进行建模
需求管理作为一个贯穿始终的工作，各个层次建模都涉及
架构变更管理阶段基本上也是各个层次的建模都涉及

什么是ArchiMate

是面向企业架构的建模语言
可以建模架构的6个层次，每个层次都有4个方面

ArchiMate建模企业架构的6个层次：

战略层：指定企业架构的战略目标、成长路线图。
业务层：企业架构的驱动力来源。
应用层：支撑业务的信息系统的组织与集成。
技术层：构架应用的网络、软件和硬件技术。
物理层：支持应用的物理设备和网络。
实现与迁移：实施企业架构的项目过程管控。

ArchiMate建模企业架构的4个方面：

动机：企业架构涉及、改进的目标和原因
主动结构：发起各种行为的主体。
行为：提供各种能力的活动及其组成的流程和实现的服务
被动结构：被处理的各种课题。

战略地图是战略实现路径分析的架构

在这里插入图片描述

IT顶层设计方案

在这里插入图片描述

ArchiMate语言-主要设计元素

业务层元素
动机元素
结构和行为元素
战略元素
核心通用关系

TOGAF-架构语言【ArchiMate3.0】

类似UML的一个东西
在这里插入图片描述

ArchiMate语言构建企业架构简图

在这里插入图片描述

ArchiMate语言-业务层元素

在这里插入图片描述

ArchiMate语言-构建业务行为元素

在这里插入图片描述

ArchiMate语言-构建业务主动结构元素

在这里插入图片描述

ArchiMate语言-战略元素

在这里插入图片描述

ArchiMate语言-构建能力、资源和行动方案

在这里插入图片描述

ArchiMate语言-构建具有能力交叉映射的价值流

在这里插入图片描述

ArchiMate语言-动机元素

在这里插入图片描述

ArchiMate语言-构建动机元素-利益相关者-驱动因素和评估

在这里插入图片描述

ArchiMate语言-构建目标-结果-原则-需求和约束

在这里插入图片描述

ArchiMate语言-动机元素-意义和价值

在这里插入图片描述

ArchiMate语言-结构和行为元素概述

在这里插入图片描述

ArchiMate语言-核心通用关系

在这里插入图片描述

ArchiMate语言案例分享

动机与战略-建模
业务架构-组织建模
业务架构-流程建模
应用架构-组件建模
应用架构-服务建模
技术架构-部署建模
技术架构-过程建模
实现和迁移
架构跨层视图-业务-应用-技术

动机与战略-建模

在这里插入图片描述

这个图比较重要，当取一个公司是总监级别的岗位的话，使用这个图去捋清楚业务和相关方非常好。
用途：描述企业架构设计、改进的目的和原因
元素：驱动器、评估、目标、利益相关者、价值、成果、原理、约束、需求、含义、资源、能力、价值流、行动方针、位置
关系：风险承担者<关联>驱动器，驱动器<引发>目标，输出成果<实现>目标

业务架构-组织建模

在这里插入图片描述

业务架构-流程建模

在这里插入图片描述

业务架构-组件建模

在这里插入图片描述

应用架构-服务建模

在这里插入图片描述

技术架构-部署建模

在这里插入图片描述

技术架构-过程建模

在这里插入图片描述

实现和迁移

在这里插入图片描述

架构跨层视图-业务-应用-技术

在这里插入图片描述

企业架构开发的各个阶段对应的建模视图如下

在这里插入图片描述

TOGAF-架构成熟度模型

在这里插入图片描述

问题思考-软件设计和架构开发过程中其实存在很多断沟

业务架构到技术架构的不一致
业务架构到业务需求的不一致
业务架构和实现的不一致

思考：

业务架构需要做到什么粒度？
- 架构是产品的上层框架（在产品前面），只需要到具体功能模块以及主要业务功能就行，具体的业务规则和异常处理都不需要考虑，那是需求分析的事情
业务架构是否需要做原型？
- 需要，只是会很粗，并且不在意具体的UE，但是需求阶段的原型应该可以从业务架构阶段的原型中细化下来
有没有统一的规则表模版？
- 不同业务的规则是不一样，不同小组的设计能力也是不一样，不同平台支持的规则DSL也是不一样的，这个需要根据自己的情况来定义自己的格式，但必须能够把规则描述清楚，做到自己、开发人员和测试人员一看就明白
需求阶段需要出以前的详细需求规格说明书吗？
- 对于那部来说不需要。但是必须要有原型，还有上面说的几个文档，一定要保证同步。