ArchiMate企业架构建模实战：从业务层到技术层

简介面向企业架构师、信息化规划人员及TOGAF学习者这是一份ArchiMate语言专业课件适用于企业架构评审、系统规划与架构建模入门培训等场景。课件共26页系统讲解企业架构建模的核心知识体系涵盖架构层次划分、架构开发方法与TOGAF框架、ArchiMate核心图例与视图视角以及架构金字塔、企业架构组成等关键概念。课内还逐一介绍每层通用描述、产品与服务、业务流程、信息、应用、技术等架构要素的建模表达方式并结合As-is与To-Be演进思路帮助读者掌握如何用ArchiMate对业务架构、信息架构、应用架构、技术架构进行统一描述进而开展架构视图设计与建模实践。资源为单个pptx演示文稿压缩包仅1.92MB轻量便于下载学习已有506人学习。适合希望快速理解企业架构描述语言、理清架构层次关系并提升架构建模能力的读者。1. 架构建模为什么需要ArchiMate这种“专业语言”先讲个我经历过多次的真实场景会议室里坐了一屋子人业务部门带了流程图研发拿了一份UML类图运维画了一堆服务器拓扑项目经理则甩出一份带箭头的PPT架构图。每一份图单独看都能看懂但放到一起没人能说清楚业务环节“订单审批”到底对应哪个系统模块系统模块背后的数据库在哪台服务器上出了问题该找哪个团队。架构建模的难题从来不是图不够多而是缺少一张能把业务、应用、技术串成一个整体的图。ArchiMate在这时候的价值就很直观它给企业架构提供了一套统一的描述语言让所有利益相关方用同一种语法表达架构。标题里的“建模”容易让新入门的同学产生误解。这里说的不是数学建模也不是3D建模而是企业架构建模——把组织的业务能力、流程、系统、数据、基础设施抽象成结构化的模型用来支撑架构规划、系统分析和演进决策。ArchiMate就是专门为这件事设计的一门建模语言由The Open Group负责维护目前的主流版本是3.x。它和UML最大的区别在于定位UML关注软件系统的设计细节ArchiMate关注整个企业组织的架构描述颗粒度更粗、覆盖面更广能横跨业务、应用、技术多个层次。对于刚接触企业架构的读者来说我的建议是先把ArchiMate当作一门“外企架构师通用的交流语言”来学。你不需要背下所有符号但要理解它的分层思想和关系语义。一旦掌握了这套语言再看团队里的架构图会清晰很多哪些图只是在画流程哪些图能真正回答“某业务能力由哪个应用支撑、落在什么基础设施上”这类架构核心问题。这篇就按我自己从入门到能落地建模的学习路径来整理配合一个完整案例把过程拆开讲。2. ArchiMate的底层结构拆解层次、元素与关系的设计逻辑2.1 三个核心层怎么切分ArchiMate最核心的设计是分层思想。它把企业架构切成三个主层业务层、应用层、技术层。业务层描述组织运转的业务行为比如客户下单、财务审批、市场活动应用层描述支撑这些业务行为的软件系统及其提供的服务比如订单管理系统、客户信息接口技术层描述承载应用的基础设施包括服务器、网络、存储、中间件。三个层之间的关系是“上层依赖于下层”业务流程调用应用服务应用组件部署在技术节点上。这个分层与常见的“业务-IT对齐”问题直接相关。我在实际项目里见过大量架构讨论业务的人说“订单流程慢”技术的人说“数据库负载高”两边根本不在同一层对话。ArchiMate要求你把每一层的模型分开表达然后通过“服务”和“实现”这类跨层关系把层与层接起来这样业务侧的需求就可以被追溯到技术侧的容量规划跨层问题时大家有了共同坐标系。在这三层的上层ArchiMate还定义了动机层和实施与迁移层。动机层描述架构背后的“为什么”包括利益相关者、驱动因素、目标、需求、约束实施与迁移层描述架构如何“落实”包括工作包、交付物、平台、实施里程碑。完整的ArchiMate模型通常不是只有三层的静态快照而是一套能表达战略目的和实施路径的动态体系。学习阶段建议先从三层核心模型入手动机层和迁移层放到后续进阶。2.2 元素分类结构、行为、信息ArchiMate中的元素按性质分为主动结构、行为元素、被动结构三类这是我上手后觉得最值得先记住的分类方式。主动结构是“发起行为的实体”业务层里有业务角色、业务参与者应用层里有应用组件技术层里有节点和设备。被动结构是“被行为操作的对象”对应业务层的业务对象、应用层的数据对象、技术层的制品。行为元素则描述“发生了什么”包含业务流程、业务功能、应用服务、技术功能等。用一个通俗类比解释三者关系把“一杯咖啡”当作被动结构业务对象把“咖啡师”当作主动结构业务角色把“制作咖啡”当作行为元素业务流程。没有主动结构行为不会发生没有被动结构行为没有对象行为元素是前两者之间的桥梁。ArchiMate模型中的所有内容几乎都逃不出这个三角框架遇到拿不准的元素类型时问自己三个问题它是谁在做它在做什么它对什么做2.3 关系类型决定模型的可推理性元素是名词关系是动词ArchiMate模型的价值一半以上靠关系体现。初学者最容易犯的错是用“箭头”把所有元素连起来却不区分箭头的语义。ArchiMate规范定义了多种关系核心的结构关系包括组合、聚合、分配、实现动态关系包括触发、流向以及贯穿各层的服务、访问、影响、关联等。不同关系在图形上用不同样式的线条区分但实际交流中大家更看重的是关系背后的逻辑含义。我工作中最常用的是服务和实现这两类关系。以业务层和应用层的接驳为例一个“订单处理流程”业务行为元素会“使用”订单服务业务服务这个服务被某个应用服务“实现”而应用服务又被某个应用组件“实现”。通过一组链条业务侧的流程最终落到具体的软件模块上。这种“上层的需求被下层实现”的语义模型让架构变更的影响分析变得可操作业务改了一个流程环节顺着实现关系就能找出哪些系统模块需要改。下表是入门阶段需要重点掌握的关系类型与使用意图我建议把它当速查表保存在手边建模之前先对照一遍避免把关系用乱。关系主要用途典型使用场景实现表示上层的抽象需求被下层的具体实体满足业务服务被应用服务实现应用服务被应用组件实现服务表示外部可访问的行为对外提供能力应用服务服务于业务流程访问表示行为元素对数据对象的读取或写入业务流程访问业务对象分配表示行为职责被分配给具体的主动结构元素业务角色被分配给业务流程触发表示行为元素之间的先后触发关系提交订单流程触发支付流程流向表示事物在元素之间流动或传递数据对象在业务流程之间流动组合表示一个元素包含另一个元素应用系统组合多个应用模块3. 一个订单提交场景的完整建模演示从业务层到技术层3.1 建模前先明确边界与视角实建模之前先花五分钟想清楚两个问题这个模型给谁看、用来回答什么问题。在我接手的项目中给CTO看的应用架构图和给开发团队的部署图虽然共享同一套ArchiMate模型词汇但视角完全不同。学习阶段建议给自己设定一个小目标用ArchiMate表达一个在线订单提交的完整链条让一个完全不懂系统的人看完模型之后能说出“客户点了提交订单系统做了哪些事数据存在哪里”。ArchiMate官方的“视角”概念就是为了配合这个场景而设计的。它规定某个视图只保留与某个利益相关者相关的元素与关系类似于从模型这个大数据库中提取出一张特定的报表。初学者不需要一次把所有视角全部学会先掌握“服务实现视角”和“部署视角”这两个常用视角前者回答业务如何被应用实现后者回答应用部署在什么技术上。下面这个案例演示的就是从业务服务一直到技术节点的完整建模过程。3.2 业务层先画流程与业务服务假设场景是客户在线提交订单系统校验库存并返回结果。业务层建模时我首先定义业务参与者“客户”以及“客户”作为业务角色“在线下单客户”所承担的行为。接着列出核心业务过程提交订单、校验库存、确认订单这些元素使用触发关系连接形成一个流程序列。为了让业务层能被应用层接上还必须定义一个业务服务比如“订单管理服务”并让这三个业务流程通过“实现”关系落到这个服务上。这一步要注意的建模要点业务流程和业务功能不要混淆。流程有明确的先后顺序和边界功能是同一领域内的能力集合。以订单为例“提交订单”“支付订单”是流程而“订单处理能力”是功能。如果建模目的是分析流程效率用流程如果建模目的是梳理能力地图用功能。ArchiMate允许两种元素共存但不能把同一概念同时当作流程和功能在图中来回切换否则越建越乱。3.3 应用层服务如何承接业务业务层定义完“订单管理服务”之后应用层需要把它落地。我在这里引入两个应用组件“订单管理系统”和“库存查询组件”。前者对外提供“订单处理服务”后者对外提供“库存查询服务”。跨层关系上“订单处理服务”实现“订单管理服务”“库存查询服务”实现“库存校验”这个业务功能。业务层向上保持业务视角应用层向下保持技术实现的开放性两者通过服务关系的接驳解耦。这个“解耦”值得多说一句。传统企业架构里业务和应用常常是强耦合的一块铁板业务部门一提需求对应的就是某个具体系统的某个具体按钮谁也说不清这个按钮背后到底是什么能力。ArchiMate要求你先把业务能力抽象成业务服务再通过应用服务去承接这样应用系统变了只要服务接口不变业务模型就不受影响。我在项目里用这个思路说服过好几个团队的负责人接受中间增加服务抽象层前期麻烦后期做影响分析时省了实在太多时间。关于应用组件之间的数据交互我给订单系统加一个“订单数据对象”被动结构库存查询组件访问它的同时处理库存记录用访问关系表达。之后做应用架构评审时看数据的产生者、消费者和维护者顺着访问关系就能统计出哪些组件之间耦合度高、哪些数据缺明确的owner。3.4 技术层落到节点与制品技术层建模要回答“应用跑在哪”。我创建一个应用节点“订单应用服务器”分配“订单管理系统”给它再创建“数据库节点”放置“订单数据库”制品。订单应用服务器与数据库节点之间用通信路径连接表示它们之间有网络交互。在技术层这里一个完整的从业务到技术的链条就打通了客户提交订单的流程由订单管理服务承接被订单处理应用服务实现部署在订单应用服务器上数据最终落到订单数据库节点里。技术层建模容易陷入过度细节。一个常见问题是把网络拓扑、IP地址、服务器型号全部画进去。ArchiMate不是网络监控工具它的技术层只需要记录到支撑架构决策的粒度。比如“这个服务是高可用应用还是普通应用”影响节点数量“数据是否需要两地三中心”影响部署结构这些是架构层面的决定而具体的IP规划、交换机端口配置则不应该出现在架构建模里。判断标准很简单去掉这个技术元素架构决策是否受影响如果不受影响不要加进图里。4. 结合“学习教案”场景ArchiMate与TOGAF的搭配顺序和工具选型4.1 TOGAF和ArchiMate各司其职ArchiMate经常和TOGAF同时出现很多学习教案也会把两者放在一起讲。初学者最常困惑的点是我学了TOGAF还要不要学ArchiMate我的理解是TOGAF是一套企业架构开发方法描述的是“怎么做架构工作”的流程体系核心是ADM架构开发方法告诉你要先做架构愿景、再做业务架构、信息系统架构、技术架构然后规划迁移和治理。ArchiMate是一套建模语言描述的是“怎么表达架构内容”的符号体系。打个比方TOGAF像施工项目管理流程ArchiMate像图纸绘制标准两者天然互补。在实际项目里我是用TOGAF的ADM循环来编排工作节奏用ArchiMate来表达每个阶段产出的架构模型。业务架构阶段画业务层模型信息系统架构阶段画应用层与数据模型技术架构阶段画技术层模型。如果只用TOGAF不用ArchiMate交付物容易沦为文档堆只用ArchiMate不用TOGAF建模容易失去阶段目标和推进节奏。面向考试或企业架构认证的读者建议把两者合并学先从ArchiMate的语言基础切入再上TOGAF的方法体系会顺畅得多。4.2 建议的学习顺序与练习节奏大多数人学习ArchiMate失败不是因为难而是顺序不对。我见过不少初学者一上来就去背ArchiMate规范里的全套符号结果坚持不了三天就放弃了。这里分享一个经过验证的学习路线也符合大多数“学习教案”类材料的编排逻辑第一阶段先用一天时间理解三个主层次的划分逻辑和服务导向思想能回答“业务层和应用层之间靠什么接上”。第二阶段花两到三天掌握常用元素和常用关系的语义建议把上表的关系类型反复对照实际例子理解而不是死记。第三阶段找一个自己熟悉的业务场景做完整建模最好是有业务背景的比如报销审批、项目立项、库存出库全程只用一个支持ArchiMate的工具实操一遍。第四阶段学习动机层和实施与迁移层把战略目标与架构模型连起来。整个过程两周左右每天一到两小时即可。4.3 工具选型从开源到商用工具是学习ArchiMate绕不开的话题。我的建议是学习阶段优先用Archi它是与ArchiMate语言同名的一款开源建模工具免费、轻量、跨平台完全支持ArchiMate 3.x规范内置多种视角模板学完基础操作之后可以立刻把注意力放在建模方法上而不是工具折腾上。等到了团队协作和大型建模阶段再考虑商用工具比如Sparx Enterprise Architect支持ArchiMate也有强大的模型管理能力BiZZdesign Enterprise Studio主打企业级架构建模与决策分析Avolution Abacus偏重组合式架构管理。选工具时最容易被忽视的一点是“模型交换”。ArchiMate官方定义了基于XML的开放交换格式好的工具应能导入导出这种格式。我在一个项目里就遇到过团队成员分别使用不同工具结果模型导来导去只能靠截图白白浪费了ArchiMate作为标准语言的优势。另外工具里的配色和布局不要随心所欲。规范推荐的颜色体系本身就能帮助阅读者区分层次业务层通常用黄色调、应用层用蓝色调、技术层用绿色调养成按规范配色的习惯模型的可读性会大幅提升。5. 学ArchiMate最容易踩的坑我的几点实操体会5.1 坑一把ArchiMate当成UML的简化版这是我见过最多人踩的坑。UML的类图画对象之间的精确关系时序图画消息交互顺序它关注的是一个软件系统的内部设计。ArchiMate关注的是一个企业的架构全貌它的元素描述的是业务概念、应用组件、技术设施这类粗粒度对象而不是代码层面的类和方法。如果用UML的习惯去建ArchiMate模型你会忍不住画出一堆细碎的数据模型和接口方法结果架构图变成了大号时序图失去全局视角。正确的心态是ArchiMate模型的要素越少、关系越清晰越好。好的ArchiMate模型不是把细节都装进去而是把细节过滤掉之后剩下的那些支撑架构决策的关键结构。我在评审其他同事的图纸时通常只看三个维度层次是否清晰服务关系是否明确技术依赖是否完整。如果过程序员视角去挑“这里少定义了一个字段”那就完全跑偏了。5.2 坑二建模只画静态结构不表达行为与关系很多ArchiMate新手画的图本质上是一张静态的系统部署图框框是系统线是网络连接看起来挺完整但没有任何行为信息。这样的模型无法回答“这个系统在业务上承担了什么任务”和“业务流程是如何被系统支撑的”。ArchiMate强调行为元素和主动结构元素的区分正是因为“谁做什么”才是架构的核心。业务层不画流程、应用层不画服务、技术层不画功能模型就只剩下空壳。我在自检模型时有个习惯从业务对象出发顺着关系链走通一遍。比如从“销售订单”数据对象出发看它被哪个业务流程访问这个流程被哪个业务服务实现业务服务又由哪个应用服务实现应用服务挂在哪个应用组件上应用组件部署在哪个技术节点上。只要能完整走通这样的链路模型的基本质量就有保证哪一步断了往往就是架构上存在空白或模糊的地方。5.3 坑三忽视“为什么”层导致模型无法支撑决策很多教案在用ArchiMate做案例时把重点全放在三层核心结构的搭建上这是学习阶段的必要步骤。但在真实业务中如果模型缺少动机层信息就无法回答“为什么要有这个架构”这个关键问题。企业架构建模的终极目的从来不是画出一张漂亮的分层图而是让架构决策有据可循。一个完整的ArchiMate模型应该可以回答哪个利益相关者关心这个架构目标目标由哪些需求细化需求要求哪些业务能力这些能力落在哪些应用上应用架在什么技术上。我在推动一个系统重构项目时正是靠着把“压缩订单处理时间”这个业务目标逐层分解到应用服务和基础设施才让管理层理解了预算投入的必要性。如果只画一张新老系统架构对比图决策推进会异常困难。因此学习阶段建议在自建模型时加一两个简单的动机层元素比如定义一个“提升客户响应速度”的目标用影响关系连到“订单管理服务”上再从“订单管理服务”用实现关系连到具体的应用改造工作包。这样模型就从“静态地图”升级成了“决策支持工具”。最后再分享一个小技巧完成初版模型后把它放一周再回来看看能否不借助任何注释的前提下讲清楚每一根连线代表什么。如果自己都讲不清说明模型中可能存在多余的关系或模糊的层次归属。ArchiMate的魅力正在于此——它逼你把“似乎是这样”的架构直觉转变成“确实是这样”的结构推理这个过程一旦习惯你会发现企业架构讨论的专业度有质的提升。本文还有配套的精品资源点击获取