ToB企服应用市场:ToB评测及商务社交产业平台
标题:
架构师篇-5、架构语言-ArchiMate
[打印本页]
作者:
石小疯
时间:
2024-7-14 02:57
标题:
架构师篇-5、架构语言-ArchiMate
内容摘要:
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也是不一样的,这个需要根据自己的情况来定义自己的格式,但必须可以大概把规则描述清楚,做到自己、开辟人员和测试人员一看就明白
需求阶段需要出以前的具体需求规格阐明书吗?
对于那部来说不需要。但是必须要有原型,还有上面说的几个文档,一定要包管同步。
案例架构刻意练习
目标:电商小程序
配景:中、大型酒楼每天的食材原材料采购管理系统。
酒楼每天需要从不同的供应商采购饭桌所需的原材料【比如:烟、酒、饮料、纸、鸡、鸭、鱼、猪肉、牛肉、青菜、特色菜、配菜等等】
每天提前一天或几天禀类下单:品类、数目
每月周期性结算、对账【支付系统外】
要求:接纳ArchiMate语言构建完整的企业战略图
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)
Powered by Discuz! X3.4