改一个字段牵出十几个下游系统这种场面做过企业级IT的人多少都碰过。表面看是耦合太重往深里挖往往是业务怎么走、系统怎么切、数据谁负责、技术用什么这四件事从来没有被放在一张图上对过。企业4A架构业务架构BA、应用架构AA、数据架构DA、技术架构TA就是用来把这四件事摁在同一张桌面上讲清楚的方法论。它不产出代码也不直接产出需求但它决定了后面所有需求该落在哪、由谁承接、数据从哪来到哪去、靠什么技术底座跑起来。这套东西在头部ICT企业的大规模IT治理里被反复打磨过后来扩散到制造、金融、能源等行业成了不少企业做数字化转型时的通用语言。下面我按自己实际参与和旁观过的几个项目把4A掰开揉碎讲一遍重点放在边界怎么划、顺序为什么这么排、以及那些文档里不会写但一踩就疼的地方。适合正在做架构规划的技术负责人、刚转架构岗的工程师也适合被拉进架构项目却搞不清自己该干什么的业务侧同事。1. 四层架构各自管什么BA、AA、DA、TA的边界划分很多人第一次接触4A最容易犯的错是把四个A当成四个文档模板各写各的写完装订成册就宣告项目结束。真正的分界线不是文档而是每一层回答的问题不同且答案不能越界。业务架构回答企业靠什么能力赚钱、这些能力由哪些流程承载应用架构回答这些能力分别由哪些系统承接、系统之间怎么交互数据架构回答业务跑起来会产生哪些数据、这些数据的权威源在哪、怎么流转技术架构回答上面三层跑在什么底座上、非功能要求怎么满足。四层各说各话合起来才是一套完整的企业运行说明书。1.1 业务架构不是画流程图是定义价值如何被交付我见过太多团队把业务架构做成了流程图的堆砌几十张跨职能流程图铺满一面墙看着壮观实际没人看。业务架构的核心产出应该是三样东西业务能力地图、端到端价值流、以及关键业务流程的分层清单。能力地图回答我们会做什么价值流回答我们怎么把价值交付给客户流程清单回答具体每一步谁做、做什么、输出什么。这三样的关系是层层收敛的。能力地图通常按价值链展开比如从市场洞察到产品定义、从采购到交付、从服务到回款每个环节再往下拆一级二级能力。价值流则是横向穿透把跨部门的环节串起来看整体效率。流程清单才是颗粒度最细的那层落到具体岗位和表单。很多项目失败就失败在跳过了能力地图直接画流程结果流程画得再细也没法回答这个流程支撑的是哪项战略能力这种问题一旦战略调整整套流程文档就全废了。提示业务架构的验收标准不是图画得漂亮而是随便挑一个战略目标能顺着能力地图往下指到具体流程和责任人。指不到说明这层没做透。1.2 应用架构要回答的是系统切几块、边界在哪应用架构最忌讳的是把现有系统清单抄一遍就当成交付物。系统清单只是现状应用架构要做的是在现状和目标之间建立映射现有系统各自承载了哪些业务能力、哪些能力被重复建设、哪些能力压根没有系统承载、哪些系统该合并、哪些该拆分。判断应用架构做得好不好有个很朴素的检验方式拿业务架构里的每个L3流程去问它落在哪个应用上如果出现一个流程横跨五六个系统且没有主责方或者一个系统同时背了三个不相关的能力那说明应用边界没划清楚。我一般要求团队在应用架构文档里必须写出每个应用的主责能力、次要能力、对外提供的服务接口、依赖的其他应用这四项缺一项后面集成阶段必然出问题。1.3 数据架构和技术架构最容易被合并一旦合并就出事这两个A在实践中经常被塞进同一个人手里理由是都是技术的事。这是个很贵的错误。数据架构关心的是数据的语义、归属和生命周期技术架构关心的是计算、存储、网络、中间件这些基础设施。前者是业务语义的延伸后者是工程实现的底座混在一起做的直接后果是数据模型按照数据库表来设计主数据没人认领数据质量问题到了报表出来才被发现。我参与过一个供应链项目早期把数据架构和技术架构打包给一个基础架构团队做结果他们按分库分表的物理设计倒推逻辑模型导致同一个供应商实体在采购、质检、财务三个域里各有各的编码规则后期做统一供应商视图花了将近四个月。这个教训很直白数据架构必须由懂业务语义的人主导技术架构由懂基础设施的人主导两者的产出物要分开评审。2. 推演顺序为什么必须是业务先行从BA到TA的单向约束链4A的推演方向几乎是不可逆的业务架构约束应用架构应用架构约束数据架构数据架构和技术架构互相约束。这个顺序不是我拍脑袋定的而是由变更成本决定的。业务上改一个流程成本是一张纸应用上改一次系统边界成本是几个月工期数据上改一次模型成本可能是几年的数据迁移技术底座换一次成本是整个机房。上游动一下下游要跟着动所以上游必须想清楚再往下传。2.1 反向推演为什么必然返工现实里最常见的反向操作是先采购了一套技术平台然后倒推这套平台能支撑什么应用再倒推哪些业务可以上。这条路走通的情况极少因为技术平台的选型逻辑和业务价值的分布逻辑基本不重合。技术平台追求通用性和复用率业务追求的是特定场景下的效率和体验两者天然错位。我旁观过一个制造企业的数字化项目先上了一套低代码平台然后要求各业务部门把自己的流程搬到平台上。结果就是平台被用成了一个高级表单工具稍微复杂一点的审批流就要写大量脚本两年后这套平台成了遗留资产。如果顺序反过来先梳理清楚哪些业务能力需要通过数字化提升、这些能力对系统灵活性的要求有多高再决定用低代码还是定制开发结局会完全不同。2.2 一条需求如何从BA穿透到TA拿一个具体场景走一遍会更清楚。假设业务架构里识别出一项能力叫订单交付可视化对应的L3流程是订单状态实时追踪。这条信息传到应用架构层就要回答由哪个系统提供订单状态是订单中心主责还是各履约系统分别提供、由集成层聚合传到数据架构层要回答订单状态的事件模型怎么定义、状态变更的历史怎么留痕、状态数据的权威源是哪个系统传到技术架构层要回答状态事件的高频写入用什么存储、查询延迟要求多少、要不要引入消息中间件做削峰这条链路走完一项业务能力才真正落地。任何一环缺失最后都会在开发阶段以需求评审反复扯皮的形式暴露出来。这也是为什么很多企业做完4A之后感觉没起作用——他们只做了BA和AADA和TA还是按老办法由项目组各自决定链条断在了半路。2.3 什么情况下数据架构可以反向牵引单向约束链有个例外当企业要做数据驱动的业务创新时数据架构会反向牵引业务架构。比如企业积累了大量设备运行数据数据团队发现可以做预测性维护这时候是数据能力反过来定义了一项新业务能力。这种情况在制造、能源、交通行业越来越常见。但要注意这种反向牵引成立的前提是数据资产已经被治理过。如果数据还散在各系统里、口径不统一、质量参差不齐所谓的数据驱动创新就是空中楼阁。我的经验是先把数据架构的基础工作做扎实主数据、指标口径、数据血缘再谈反向牵引顺序不能乱。3. 业务架构的落地颗粒度从价值链到L3流程的拆解手感业务架构最容易失控的地方是颗粒度。拆得太粗后面应用架构没法承接拆得太细做完就过时维护成本高到没人愿意维护。我一般的建议是主路径拆到L3特殊情况才下探到L4L5基本不做那是作业指导书的范畴不属于架构层。3.1 能力、流程、组织三套语言怎么对齐业务侧同事说话用的是组织语言我们部门负责……架构师说话用的是能力语言这项能力叫……一线员工说话用的是流程语言我这个单子要过几道审批。三套语言不对齐业务架构做出来业务方看不懂看完也不认。我的做法是建一张对照表左边是能力项中间是承载它的端到端流程右边是流程各环节的责任部门。这张表不用很精细但必须每个能力项都能填满填不满的地方就是职责真空区往往也是问题最多的地方。有一次做某企业的售后服务架构对照表填到备件调拨这一项时发现流程上写的是服务部门负责但实际执行中仓储部门有否决权两边都没在架构文档里体现这就是典型的职责真空。3.2 L1到L5分层做到哪一层就该停手我的分层习惯是这样的L1是价值域比如研发、供应、营销、服务L2是能力组比如供应下面分采购、库存、物流L3是具体能力或流程比如采购下面分寻源、下单、对账L4是子流程L5是操作步骤。L3是架构层的最后一站因为L3还能对应到一个应用大致能承接的范围到了L4就开始涉及具体功能和界面那属于需求阶段的事。判断该不该继续往下拆有个实用标准如果这一层的每个节点都能对应到一个明确的责任主体和一个可识别的系统边界就停手。对应不上的说明还得往下拆一层对应得太细碎一个节点对应三四个系统说明拆过头了要往上收。3.3 业务架构变成墙上挂图的三个原因第一个原因是没有和考核挂钩。业务架构梳理出来的能力短板、流程断点如果不进入部门的年度重点工作就永远只是文档。第二个原因是没有版本机制。业务架构做完就封存第二年组织调整、业务变化文档还是老样子慢慢就没人信了。第三个原因是缺少业务侧的主人。很多企业的业务架构由IT部门主导业务部门只是配合提供信息做完之后IT部门自己维护业务侧不认自然用不起来。这三个原因里第三个最致命。我的经验是业务架构必须有一个业务侧的高管做OwnerIT部门做技术支撑否则做多少遍都是白做。4. 应用架构的拆分边界服务化怎么切才不返工应用架构的核心难题只有一个边界画在哪。画得太粗一个系统包打天下改一处动全身画得太细系统数量爆炸集成复杂度飙升。这个平衡点没有通用公式但有可以参考的判断维度。4.1 按业务能力切还是按组织切第一个分岔口按组织切的好处是落地快每个部门认领自己的系统责任清晰坏处是组织一调整系统边界就得跟着动而且跨部门的端到端流程会被切得七零八落。按业务能力切的好处是稳定能力相对组织更持久坏处是初期推行阻力大因为一个能力往往横跨多个部门谁也不愿意当主责方。我的实践倾向是以业务能力为主、组织映射为辅。具体操作上先用能力地图划出应用边界再标注每个应用当前由哪个部门主管如果发现某个应用横跨三个部门且没有主责方就在架构文档里明确标红作为治理项推进。这个方法比纯粹按组织切要慢但两年之后回头看返工率低得多。4.2 集成方式的选择点对点、总线还是事件驱动集成方式是应用架构里最容易拍脑袋决策的部分。点对点集成简单直接但接口数量随系统数量呈平方级增长五个系统还好二十个系统就是灾难。集成总线能收敛接口数量但总线本身容易变成瓶颈和单点。事件驱动解耦程度最高但对数据一致性和运维能力要求也最高。集成方式适用场景主要代价我的使用建议点对点系统数少于五个、交互简单稳定接口数量膨胀快只在不打算长期演进的边缘系统间使用集成总线系统数中等、需要统一协议和监控总线运维成本、单点风险中台化初期的过渡方案要有退出机制事件驱动高频、异步、需要削峰和解耦最终一致性处理复杂核心交易链路优先配套要做好幂等和补偿实际项目里很少只用一种通常是核心链路事件驱动、管理系统走总线、边缘系统点对点。关键是在架构文档里写清楚每类交互为什么选这种方式而不是开发时谁顺手用哪个。4.3 应用架构清单该记录哪些字段应用架构清单不是系统名录是个结构化资产。我一般要求至少包含这些字段应用名称、主责业务能力、承载的L3流程、对外提供的关键服务、依赖的上游应用、数据主责范围、技术栈、生命周期状态新建/在用/待退役、责任部门。字段看着多但每个都有用——尤其是数据主责范围它直接决定了数据架构层谁是权威源生命周期状态决定了后续投资往哪投。5. 数据架构的三件套主数据、模型与流转路径数据架构在4A里最容易被低估因为它的产出不像流程图和应用清单那么直观。但数据架构没做好的后果是最滞后的——往往上线一两年后才在报表口径不一致、跨域分析做不了这类问题上集中爆发。这一层我通常抓三件事主数据识别、数据模型分层、数据流转路径。5.1 主数据识别的判定标准与常见误判主数据的判定不是看数据量大不大而是看三个特征跨多个业务域被引用、变更频率相对低、一旦出错影响面广。客户、供应商、物料、组织、科目这几类是最典型的。反过来说订单、工单这类高频产生的业务数据不是主数据它们是交易数据。常见的误判有两种。一种是把所有基础数据都当主数据结果主数据范围膨胀到几十个实体治理成本高到推不下去。另一种是把主数据和参考数据混为一谈参考数据比如国家地区代码、计量单位变更极少治理方式和主数据完全不同。我的建议是主数据范围控制在十个实体以内先做最痛的两三个做出效果再扩。5.2 概念模型、逻辑模型、物理模型的分工三层模型的边界经常被模糊。概念模型是业务语言用来说清楚有哪些核心实体、它们之间是什么关系不涉及字段和类型逻辑模型是架构语言落到实体属性、主键、外键、规范化程度物理模型是工程语言落到表结构、索引、分区策略。三层之间是逐级细化的关系不能跳级。我见过最典型的问题是从业务需求直接跳到物理建模中间的概念和逻辑模型被省略。后果是同一个业务概念在不同系统里被建成不同的表结构语义漂移。数据架构师的职责就是把概念模型和逻辑模型管住物理模型交给开发团队按具体数据库特性实现但要在架构评审时校验一致性。5.3 数据流转图为什么比ER图更有说服力ER图回答的是数据长什么样数据流转图回答的是数据从哪来、经过谁、到哪去、谁是权威源。跟业务方沟通时流转图的说服力远超ER图因为它能直接暴露问题同一个数据项出现两个源头或者某个关键数据流转到下游后没人维护更新。我画流转图有个习惯每个数据实体必须标注唯一的权威源系统如果标注不出来或者标了两个这就是治理项。这个要求听起来简单实际执行时能挖出大量历史遗留问题比如客户信息在三个系统里都能改改完之后谁覆盖谁全凭运气。6. 技术架构的收敛尺度平台化不等于大集中技术架构层最容易被两种极端带偏。一种是放任自流各项目组自己选技术栈几年下来企业里跑着七八种数据库、四五套消息中间件运维成本高企。另一种是矫枉过正搞一个大而全的统一平台什么都要往上塞结果平台成了瓶颈业务等排期等到失去耐心。收敛是必要的但要有尺度。6.1 技术栈收敛到什么程度算合适我的经验是分三层收敛。基础设施层要求强统一计算、存储、网络这些底座必须收敛否则运维和安全都没法管。中间件层要求有限统一每个品类消息、缓存、任务调度、API网关允许一到两个标准选型特殊场景走例外审批。应用框架层允许适度多样不同业务场景对性能、开发效率、生态的要求差异大强求统一反而拖累交付。收敛的推进节奏也很关键。一刀切地要求存量系统全部改造成本高到不可能更现实的做法是新增项目必须遵循标准存量系统按生命周期自然淘汰。我参与过的一个项目用三年时间把数据库从七种收敛到三种靠的就是这条规则加一个明确的技术雷达发布机制。6.2 非功能需求在技术架构层怎么落地性能、可用性、安全性、可维护性这些非功能要求在业务架构和应用架构层只能提出目标落到技术架构层才变成可执行的设计。比如订单查询响应时间不超过两秒这个目标技术架构层要拆成查询走读库还是缓存、数据量级预估多少、索引怎么设计、降级策略是什么。这里有个常见误区非功能指标只写目标不写验证方式。我要求在技术架构文档里每个非功能指标旁边必须写明如何测量、在什么场景下测量、不达标时的处置方案。缺了这三项指标就是空话上线后没人能说清楚到底达没达标。6.3 云化与自主化替换对TA层的实际冲击近些年很多企业都在做基础设施的云化迁移和关键组件的自主化替换这两件事对技术架构层的冲击远比想象中大。云化不只是把虚机搬上去涉及应用的无状态化改造、弹性伸缩策略、分布式事务处理方式的变化组件替换涉及兼容性验证、性能基线重建、运维工具链适配。我见过一个项目中间件替换方案在测试环境跑得很好上线后才发现新中间件在长时间高并发下的内存回收策略和原产品差异很大导致每天凌晨出现周期性抖动。这类问题的根因是技术架构层缺少替换影响面分析这一环只做了功能兼容性验证没做非功能特性对比。建议的做法是建一张对照表把原产品和新产品在吞吐、延迟、一致性、运维接口这几个维度逐项对比差异项必须有应对方案。7. 4A之间最容易断裂的接缝与修补手法四层架构各自做得好不等于整体有效真正决定成败的是接缝处。我在评审过几十套架构文档之后发现断裂点高度集中在三个位置。7.1 BA到AA的断点能力项没有应用承载这是最常见的断点。业务架构梳理出一项能力应用架构清单里找不到对应的系统或者找到了但那个系统的主责能力写的是别的。造成这种情况的原因通常是业务架构做完之后直接交给应用架构团队中间没有做承接性校验。修补手法很直接做一张能力-应用映射表逐行填空。填不上的行分两类处理——如果这项能力确实需要系统支撑就列为新建应用需求如果这项能力靠人工或线下流程就能满足就在表里明确标注非系统承载避免后续误判。这张表做完应用架构的投资优先级也就自然出来了。7.2 AA到DA的断点应用产生的数据没人认领应用架构定义了系统边界但没定义数据归属结果是每个系统都在产生数据却没有一个系统对数据的质量负责。典型表现是同一个客户在不同系统里的名称、编码、联系方式不一致做跨系统分析时先要花两周做数据清洗。修补的关键动作是在应用架构清单里增加数据主责范围字段并且在数据架构层逐一确认。这里有个实操技巧优先认领那些被下游引用的数据比如客户、物料、组织这类被广泛引用的实体必须明确唯一权威源那些只在本系统内部使用的数据可以暂缓治理。7.3 DA到TA的断点数据量级和技术选型脱节数据架构给出了数据模型和流转路径但没给出量级预估技术架构选型就成了盲选。我见过一个项目日志数据按每天百万级设计存储方案实际跑起来是每天上亿条三个月后存储就告急了。修补办法是在数据架构文档里增加数据量级与增长预估这一列哪怕只是粗估当前量级、年增长率、峰值倍数也比没有强。技术架构选型时把这一列作为必读输入容量规划就有了依据。这个动作成本很低但能避免很多后期返工。8. 从文档到资产推进节奏、组织保障与翻车复盘4A项目最讽刺的地方在于它本身也是一场需要被架构的变革。我见过太多企业把4A做成了一次性交付物交付完就束之高阁。要让这套东西真正起作用推进节奏和组织保障的设计比方法论本身更重要。8.1 分阶段推进先做哪一块最不容易翻车如果企业是第一次做4A我建议的顺序是先做业务架构的局部选一个痛点最明显的域再做应用架构的现状映射然后做数据架构的主数据识别最后做技术架构的收敛规划。不要一上来就全域铺开全域铺开的典型结局是做了半年还在对齐术语业务方失去耐心。局部试点选哪个域也有讲究。选那种业务痛点明确、涉及部门不多、有明确业务负责人的域容易出成果。比如售后服务、采购寻源这类。选那种横跨全公司的域比如财务很容易陷入无休止的协调。8.2 架构治理委员会的实质作用与虚设风险几乎每个做4A的企业都会成立一个架构治理委员会但大部分流于形式。虚设的标志很明显委员会只评审文档格式不评审技术决策只在项目立项时开一次会执行过程中不再介入成员是各部门派的代表但没有决策权。真正起作用的委员会通常有三个特征有明确的否决权不符合架构规范的项目可以不予立项、有固定的评审节奏比如每月一次架构评审会、有跨部门的裁决机制应用边界争议由委员会拍板。这三条缺一条委员会就容易退化成橡皮图章。8.3 架构资产的版本管理与变更联动架构文档如果不同步更新半年后就没人信了。我的做法是把架构资产纳入配置管理和需求变更、项目立项做联动任何新项目立项前必须先在架构资产里做影响分析说明这个项目会影响哪些能力项、哪些应用、哪些数据实体分析结果作为立项材料的一部分。这个机制能倒逼架构资产保持更新因为它变成了流程上的必经环节。9. 几个翻车场景的复盘方法论讲完说几个实际踩过的坑比什么都有参考价值。一次性全域铺开导致业务方集体抵触。某企业启动4A项目时要求所有业务部门在三个月内提交本部门的业务架构材料结果各部门为了交差把现有的流程文件改个名字就交上来了质量惨不忍睹后面的应用架构和数据架构全部建立在沙子上。后来重新做改成选两个域深耕用了五个月做出可用的成果再向其他部门推广阻力小了很多。架构师脱离项目产出无法验收。有些企业把架构师放在一个独立的架构部门只做规划不参与项目交付。结果架构文档写得头头是道项目组照着做发现根本落不了地因为架构师不了解具体项目的约束条件。我倾向于让架构师至少深度参与一到两个项目边做边校验架构设计。只做现状不做目标架构沦为文档归档。现状梳理是必要的但如果架构文档只描述现在是什么样没有描述两年后应该是什么样以及从现状到目标怎么走那它对决策就没有价值。目标架构不需要很精确但必须有明确的方向和阶段划分。忽略数据架构后期返工代价高昂。前面提过的供应链项目就是典型主数据编码不统一的问题拖了四个月才收拾干净。这件事让我在后来的项目里坚持一个原则数据架构的主数据识别必须在应用开发启动前完成哪怕只识别出最核心的两三个实体。技术架构的例外审批形同虚设。技术栈收敛的规则定得再好如果例外审批是走过场收敛就失败了。我见过一个企业技术标准文档写得很规范但一年内批了四十多个例外最后技术栈比收敛前还乱。例外审批必须有人真正把关而且要定期统计例外原因如果是标准本身不合理就改标准如果是项目组图省事就该驳回。最后分享一个我在实际操作中的体会4A架构的价值不在于四份文档有多完整而在于它能不能在关键决策时刻提供依据。当一个新需求来了能不能快速判断它该落在哪个应用、动到哪些数据、需不需要技术架构支持当一次组织调整来了能不能快速评估哪些系统边界要跟着动。能回答这两个问题这套架构就是活的回答不了文档写得再厚也只是摆设。所以我现在的做法是每季度拿两三个真实需求去考一遍架构资产考不过的地方就是下一轮要补的地方。
改一个字段牵出十几个下游系统这种场面做过企业级IT的人多少都碰过。表面看是耦合太重往深里挖往往是业务怎么走、系统怎么切、数据谁负责、技术用什么这四件事从来没有被放在一张图上对过。企业4A架构业务架构BA、应用架构AA、数据架构DA、技术架构TA就是用来把这四件事摁在同一张桌面上讲清楚的方法论。它不产出代码也不直接产出需求但它决定了后面所有需求该落在哪、由谁承接、数据从哪来到哪去、靠什么技术底座跑起来。这套东西在头部ICT企业的大规模IT治理里被反复打磨过后来扩散到制造、金融、能源等行业成了不少企业做数字化转型时的通用语言。下面我按自己实际参与和旁观过的几个项目把4A掰开揉碎讲一遍重点放在边界怎么划、顺序为什么这么排、以及那些文档里不会写但一踩就疼的地方。适合正在做架构规划的技术负责人、刚转架构岗的工程师也适合被拉进架构项目却搞不清自己该干什么的业务侧同事。1. 四层架构各自管什么BA、AA、DA、TA的边界划分很多人第一次接触4A最容易犯的错是把四个A当成四个文档模板各写各的写完装订成册就宣告项目结束。真正的分界线不是文档而是每一层回答的问题不同且答案不能越界。业务架构回答企业靠什么能力赚钱、这些能力由哪些流程承载应用架构回答这些能力分别由哪些系统承接、系统之间怎么交互数据架构回答业务跑起来会产生哪些数据、这些数据的权威源在哪、怎么流转技术架构回答上面三层跑在什么底座上、非功能要求怎么满足。四层各说各话合起来才是一套完整的企业运行说明书。1.1 业务架构不是画流程图是定义价值如何被交付我见过太多团队把业务架构做成了流程图的堆砌几十张跨职能流程图铺满一面墙看着壮观实际没人看。业务架构的核心产出应该是三样东西业务能力地图、端到端价值流、以及关键业务流程的分层清单。能力地图回答我们会做什么价值流回答我们怎么把价值交付给客户流程清单回答具体每一步谁做、做什么、输出什么。这三样的关系是层层收敛的。能力地图通常按价值链展开比如从市场洞察到产品定义、从采购到交付、从服务到回款每个环节再往下拆一级二级能力。价值流则是横向穿透把跨部门的环节串起来看整体效率。流程清单才是颗粒度最细的那层落到具体岗位和表单。很多项目失败就失败在跳过了能力地图直接画流程结果流程画得再细也没法回答这个流程支撑的是哪项战略能力这种问题一旦战略调整整套流程文档就全废了。提示业务架构的验收标准不是图画得漂亮而是随便挑一个战略目标能顺着能力地图往下指到具体流程和责任人。指不到说明这层没做透。1.2 应用架构要回答的是系统切几块、边界在哪应用架构最忌讳的是把现有系统清单抄一遍就当成交付物。系统清单只是现状应用架构要做的是在现状和目标之间建立映射现有系统各自承载了哪些业务能力、哪些能力被重复建设、哪些能力压根没有系统承载、哪些系统该合并、哪些该拆分。判断应用架构做得好不好有个很朴素的检验方式拿业务架构里的每个L3流程去问它落在哪个应用上如果出现一个流程横跨五六个系统且没有主责方或者一个系统同时背了三个不相关的能力那说明应用边界没划清楚。我一般要求团队在应用架构文档里必须写出每个应用的主责能力、次要能力、对外提供的服务接口、依赖的其他应用这四项缺一项后面集成阶段必然出问题。1.3 数据架构和技术架构最容易被合并一旦合并就出事这两个A在实践中经常被塞进同一个人手里理由是都是技术的事。这是个很贵的错误。数据架构关心的是数据的语义、归属和生命周期技术架构关心的是计算、存储、网络、中间件这些基础设施。前者是业务语义的延伸后者是工程实现的底座混在一起做的直接后果是数据模型按照数据库表来设计主数据没人认领数据质量问题到了报表出来才被发现。我参与过一个供应链项目早期把数据架构和技术架构打包给一个基础架构团队做结果他们按分库分表的物理设计倒推逻辑模型导致同一个供应商实体在采购、质检、财务三个域里各有各的编码规则后期做统一供应商视图花了将近四个月。这个教训很直白数据架构必须由懂业务语义的人主导技术架构由懂基础设施的人主导两者的产出物要分开评审。2. 推演顺序为什么必须是业务先行从BA到TA的单向约束链4A的推演方向几乎是不可逆的业务架构约束应用架构应用架构约束数据架构数据架构和技术架构互相约束。这个顺序不是我拍脑袋定的而是由变更成本决定的。业务上改一个流程成本是一张纸应用上改一次系统边界成本是几个月工期数据上改一次模型成本可能是几年的数据迁移技术底座换一次成本是整个机房。上游动一下下游要跟着动所以上游必须想清楚再往下传。2.1 反向推演为什么必然返工现实里最常见的反向操作是先采购了一套技术平台然后倒推这套平台能支撑什么应用再倒推哪些业务可以上。这条路走通的情况极少因为技术平台的选型逻辑和业务价值的分布逻辑基本不重合。技术平台追求通用性和复用率业务追求的是特定场景下的效率和体验两者天然错位。我旁观过一个制造企业的数字化项目先上了一套低代码平台然后要求各业务部门把自己的流程搬到平台上。结果就是平台被用成了一个高级表单工具稍微复杂一点的审批流就要写大量脚本两年后这套平台成了遗留资产。如果顺序反过来先梳理清楚哪些业务能力需要通过数字化提升、这些能力对系统灵活性的要求有多高再决定用低代码还是定制开发结局会完全不同。2.2 一条需求如何从BA穿透到TA拿一个具体场景走一遍会更清楚。假设业务架构里识别出一项能力叫订单交付可视化对应的L3流程是订单状态实时追踪。这条信息传到应用架构层就要回答由哪个系统提供订单状态是订单中心主责还是各履约系统分别提供、由集成层聚合传到数据架构层要回答订单状态的事件模型怎么定义、状态变更的历史怎么留痕、状态数据的权威源是哪个系统传到技术架构层要回答状态事件的高频写入用什么存储、查询延迟要求多少、要不要引入消息中间件做削峰这条链路走完一项业务能力才真正落地。任何一环缺失最后都会在开发阶段以需求评审反复扯皮的形式暴露出来。这也是为什么很多企业做完4A之后感觉没起作用——他们只做了BA和AADA和TA还是按老办法由项目组各自决定链条断在了半路。2.3 什么情况下数据架构可以反向牵引单向约束链有个例外当企业要做数据驱动的业务创新时数据架构会反向牵引业务架构。比如企业积累了大量设备运行数据数据团队发现可以做预测性维护这时候是数据能力反过来定义了一项新业务能力。这种情况在制造、能源、交通行业越来越常见。但要注意这种反向牵引成立的前提是数据资产已经被治理过。如果数据还散在各系统里、口径不统一、质量参差不齐所谓的数据驱动创新就是空中楼阁。我的经验是先把数据架构的基础工作做扎实主数据、指标口径、数据血缘再谈反向牵引顺序不能乱。3. 业务架构的落地颗粒度从价值链到L3流程的拆解手感业务架构最容易失控的地方是颗粒度。拆得太粗后面应用架构没法承接拆得太细做完就过时维护成本高到没人愿意维护。我一般的建议是主路径拆到L3特殊情况才下探到L4L5基本不做那是作业指导书的范畴不属于架构层。3.1 能力、流程、组织三套语言怎么对齐业务侧同事说话用的是组织语言我们部门负责……架构师说话用的是能力语言这项能力叫……一线员工说话用的是流程语言我这个单子要过几道审批。三套语言不对齐业务架构做出来业务方看不懂看完也不认。我的做法是建一张对照表左边是能力项中间是承载它的端到端流程右边是流程各环节的责任部门。这张表不用很精细但必须每个能力项都能填满填不满的地方就是职责真空区往往也是问题最多的地方。有一次做某企业的售后服务架构对照表填到备件调拨这一项时发现流程上写的是服务部门负责但实际执行中仓储部门有否决权两边都没在架构文档里体现这就是典型的职责真空。3.2 L1到L5分层做到哪一层就该停手我的分层习惯是这样的L1是价值域比如研发、供应、营销、服务L2是能力组比如供应下面分采购、库存、物流L3是具体能力或流程比如采购下面分寻源、下单、对账L4是子流程L5是操作步骤。L3是架构层的最后一站因为L3还能对应到一个应用大致能承接的范围到了L4就开始涉及具体功能和界面那属于需求阶段的事。判断该不该继续往下拆有个实用标准如果这一层的每个节点都能对应到一个明确的责任主体和一个可识别的系统边界就停手。对应不上的说明还得往下拆一层对应得太细碎一个节点对应三四个系统说明拆过头了要往上收。3.3 业务架构变成墙上挂图的三个原因第一个原因是没有和考核挂钩。业务架构梳理出来的能力短板、流程断点如果不进入部门的年度重点工作就永远只是文档。第二个原因是没有版本机制。业务架构做完就封存第二年组织调整、业务变化文档还是老样子慢慢就没人信了。第三个原因是缺少业务侧的主人。很多企业的业务架构由IT部门主导业务部门只是配合提供信息做完之后IT部门自己维护业务侧不认自然用不起来。这三个原因里第三个最致命。我的经验是业务架构必须有一个业务侧的高管做OwnerIT部门做技术支撑否则做多少遍都是白做。4. 应用架构的拆分边界服务化怎么切才不返工应用架构的核心难题只有一个边界画在哪。画得太粗一个系统包打天下改一处动全身画得太细系统数量爆炸集成复杂度飙升。这个平衡点没有通用公式但有可以参考的判断维度。4.1 按业务能力切还是按组织切第一个分岔口按组织切的好处是落地快每个部门认领自己的系统责任清晰坏处是组织一调整系统边界就得跟着动而且跨部门的端到端流程会被切得七零八落。按业务能力切的好处是稳定能力相对组织更持久坏处是初期推行阻力大因为一个能力往往横跨多个部门谁也不愿意当主责方。我的实践倾向是以业务能力为主、组织映射为辅。具体操作上先用能力地图划出应用边界再标注每个应用当前由哪个部门主管如果发现某个应用横跨三个部门且没有主责方就在架构文档里明确标红作为治理项推进。这个方法比纯粹按组织切要慢但两年之后回头看返工率低得多。4.2 集成方式的选择点对点、总线还是事件驱动集成方式是应用架构里最容易拍脑袋决策的部分。点对点集成简单直接但接口数量随系统数量呈平方级增长五个系统还好二十个系统就是灾难。集成总线能收敛接口数量但总线本身容易变成瓶颈和单点。事件驱动解耦程度最高但对数据一致性和运维能力要求也最高。集成方式适用场景主要代价我的使用建议点对点系统数少于五个、交互简单稳定接口数量膨胀快只在不打算长期演进的边缘系统间使用集成总线系统数中等、需要统一协议和监控总线运维成本、单点风险中台化初期的过渡方案要有退出机制事件驱动高频、异步、需要削峰和解耦最终一致性处理复杂核心交易链路优先配套要做好幂等和补偿实际项目里很少只用一种通常是核心链路事件驱动、管理系统走总线、边缘系统点对点。关键是在架构文档里写清楚每类交互为什么选这种方式而不是开发时谁顺手用哪个。4.3 应用架构清单该记录哪些字段应用架构清单不是系统名录是个结构化资产。我一般要求至少包含这些字段应用名称、主责业务能力、承载的L3流程、对外提供的关键服务、依赖的上游应用、数据主责范围、技术栈、生命周期状态新建/在用/待退役、责任部门。字段看着多但每个都有用——尤其是数据主责范围它直接决定了数据架构层谁是权威源生命周期状态决定了后续投资往哪投。5. 数据架构的三件套主数据、模型与流转路径数据架构在4A里最容易被低估因为它的产出不像流程图和应用清单那么直观。但数据架构没做好的后果是最滞后的——往往上线一两年后才在报表口径不一致、跨域分析做不了这类问题上集中爆发。这一层我通常抓三件事主数据识别、数据模型分层、数据流转路径。5.1 主数据识别的判定标准与常见误判主数据的判定不是看数据量大不大而是看三个特征跨多个业务域被引用、变更频率相对低、一旦出错影响面广。客户、供应商、物料、组织、科目这几类是最典型的。反过来说订单、工单这类高频产生的业务数据不是主数据它们是交易数据。常见的误判有两种。一种是把所有基础数据都当主数据结果主数据范围膨胀到几十个实体治理成本高到推不下去。另一种是把主数据和参考数据混为一谈参考数据比如国家地区代码、计量单位变更极少治理方式和主数据完全不同。我的建议是主数据范围控制在十个实体以内先做最痛的两三个做出效果再扩。5.2 概念模型、逻辑模型、物理模型的分工三层模型的边界经常被模糊。概念模型是业务语言用来说清楚有哪些核心实体、它们之间是什么关系不涉及字段和类型逻辑模型是架构语言落到实体属性、主键、外键、规范化程度物理模型是工程语言落到表结构、索引、分区策略。三层之间是逐级细化的关系不能跳级。我见过最典型的问题是从业务需求直接跳到物理建模中间的概念和逻辑模型被省略。后果是同一个业务概念在不同系统里被建成不同的表结构语义漂移。数据架构师的职责就是把概念模型和逻辑模型管住物理模型交给开发团队按具体数据库特性实现但要在架构评审时校验一致性。5.3 数据流转图为什么比ER图更有说服力ER图回答的是数据长什么样数据流转图回答的是数据从哪来、经过谁、到哪去、谁是权威源。跟业务方沟通时流转图的说服力远超ER图因为它能直接暴露问题同一个数据项出现两个源头或者某个关键数据流转到下游后没人维护更新。我画流转图有个习惯每个数据实体必须标注唯一的权威源系统如果标注不出来或者标了两个这就是治理项。这个要求听起来简单实际执行时能挖出大量历史遗留问题比如客户信息在三个系统里都能改改完之后谁覆盖谁全凭运气。6. 技术架构的收敛尺度平台化不等于大集中技术架构层最容易被两种极端带偏。一种是放任自流各项目组自己选技术栈几年下来企业里跑着七八种数据库、四五套消息中间件运维成本高企。另一种是矫枉过正搞一个大而全的统一平台什么都要往上塞结果平台成了瓶颈业务等排期等到失去耐心。收敛是必要的但要有尺度。6.1 技术栈收敛到什么程度算合适我的经验是分三层收敛。基础设施层要求强统一计算、存储、网络这些底座必须收敛否则运维和安全都没法管。中间件层要求有限统一每个品类消息、缓存、任务调度、API网关允许一到两个标准选型特殊场景走例外审批。应用框架层允许适度多样不同业务场景对性能、开发效率、生态的要求差异大强求统一反而拖累交付。收敛的推进节奏也很关键。一刀切地要求存量系统全部改造成本高到不可能更现实的做法是新增项目必须遵循标准存量系统按生命周期自然淘汰。我参与过的一个项目用三年时间把数据库从七种收敛到三种靠的就是这条规则加一个明确的技术雷达发布机制。6.2 非功能需求在技术架构层怎么落地性能、可用性、安全性、可维护性这些非功能要求在业务架构和应用架构层只能提出目标落到技术架构层才变成可执行的设计。比如订单查询响应时间不超过两秒这个目标技术架构层要拆成查询走读库还是缓存、数据量级预估多少、索引怎么设计、降级策略是什么。这里有个常见误区非功能指标只写目标不写验证方式。我要求在技术架构文档里每个非功能指标旁边必须写明如何测量、在什么场景下测量、不达标时的处置方案。缺了这三项指标就是空话上线后没人能说清楚到底达没达标。6.3 云化与自主化替换对TA层的实际冲击近些年很多企业都在做基础设施的云化迁移和关键组件的自主化替换这两件事对技术架构层的冲击远比想象中大。云化不只是把虚机搬上去涉及应用的无状态化改造、弹性伸缩策略、分布式事务处理方式的变化组件替换涉及兼容性验证、性能基线重建、运维工具链适配。我见过一个项目中间件替换方案在测试环境跑得很好上线后才发现新中间件在长时间高并发下的内存回收策略和原产品差异很大导致每天凌晨出现周期性抖动。这类问题的根因是技术架构层缺少替换影响面分析这一环只做了功能兼容性验证没做非功能特性对比。建议的做法是建一张对照表把原产品和新产品在吞吐、延迟、一致性、运维接口这几个维度逐项对比差异项必须有应对方案。7. 4A之间最容易断裂的接缝与修补手法四层架构各自做得好不等于整体有效真正决定成败的是接缝处。我在评审过几十套架构文档之后发现断裂点高度集中在三个位置。7.1 BA到AA的断点能力项没有应用承载这是最常见的断点。业务架构梳理出一项能力应用架构清单里找不到对应的系统或者找到了但那个系统的主责能力写的是别的。造成这种情况的原因通常是业务架构做完之后直接交给应用架构团队中间没有做承接性校验。修补手法很直接做一张能力-应用映射表逐行填空。填不上的行分两类处理——如果这项能力确实需要系统支撑就列为新建应用需求如果这项能力靠人工或线下流程就能满足就在表里明确标注非系统承载避免后续误判。这张表做完应用架构的投资优先级也就自然出来了。7.2 AA到DA的断点应用产生的数据没人认领应用架构定义了系统边界但没定义数据归属结果是每个系统都在产生数据却没有一个系统对数据的质量负责。典型表现是同一个客户在不同系统里的名称、编码、联系方式不一致做跨系统分析时先要花两周做数据清洗。修补的关键动作是在应用架构清单里增加数据主责范围字段并且在数据架构层逐一确认。这里有个实操技巧优先认领那些被下游引用的数据比如客户、物料、组织这类被广泛引用的实体必须明确唯一权威源那些只在本系统内部使用的数据可以暂缓治理。7.3 DA到TA的断点数据量级和技术选型脱节数据架构给出了数据模型和流转路径但没给出量级预估技术架构选型就成了盲选。我见过一个项目日志数据按每天百万级设计存储方案实际跑起来是每天上亿条三个月后存储就告急了。修补办法是在数据架构文档里增加数据量级与增长预估这一列哪怕只是粗估当前量级、年增长率、峰值倍数也比没有强。技术架构选型时把这一列作为必读输入容量规划就有了依据。这个动作成本很低但能避免很多后期返工。8. 从文档到资产推进节奏、组织保障与翻车复盘4A项目最讽刺的地方在于它本身也是一场需要被架构的变革。我见过太多企业把4A做成了一次性交付物交付完就束之高阁。要让这套东西真正起作用推进节奏和组织保障的设计比方法论本身更重要。8.1 分阶段推进先做哪一块最不容易翻车如果企业是第一次做4A我建议的顺序是先做业务架构的局部选一个痛点最明显的域再做应用架构的现状映射然后做数据架构的主数据识别最后做技术架构的收敛规划。不要一上来就全域铺开全域铺开的典型结局是做了半年还在对齐术语业务方失去耐心。局部试点选哪个域也有讲究。选那种业务痛点明确、涉及部门不多、有明确业务负责人的域容易出成果。比如售后服务、采购寻源这类。选那种横跨全公司的域比如财务很容易陷入无休止的协调。8.2 架构治理委员会的实质作用与虚设风险几乎每个做4A的企业都会成立一个架构治理委员会但大部分流于形式。虚设的标志很明显委员会只评审文档格式不评审技术决策只在项目立项时开一次会执行过程中不再介入成员是各部门派的代表但没有决策权。真正起作用的委员会通常有三个特征有明确的否决权不符合架构规范的项目可以不予立项、有固定的评审节奏比如每月一次架构评审会、有跨部门的裁决机制应用边界争议由委员会拍板。这三条缺一条委员会就容易退化成橡皮图章。8.3 架构资产的版本管理与变更联动架构文档如果不同步更新半年后就没人信了。我的做法是把架构资产纳入配置管理和需求变更、项目立项做联动任何新项目立项前必须先在架构资产里做影响分析说明这个项目会影响哪些能力项、哪些应用、哪些数据实体分析结果作为立项材料的一部分。这个机制能倒逼架构资产保持更新因为它变成了流程上的必经环节。9. 几个翻车场景的复盘方法论讲完说几个实际踩过的坑比什么都有参考价值。一次性全域铺开导致业务方集体抵触。某企业启动4A项目时要求所有业务部门在三个月内提交本部门的业务架构材料结果各部门为了交差把现有的流程文件改个名字就交上来了质量惨不忍睹后面的应用架构和数据架构全部建立在沙子上。后来重新做改成选两个域深耕用了五个月做出可用的成果再向其他部门推广阻力小了很多。架构师脱离项目产出无法验收。有些企业把架构师放在一个独立的架构部门只做规划不参与项目交付。结果架构文档写得头头是道项目组照着做发现根本落不了地因为架构师不了解具体项目的约束条件。我倾向于让架构师至少深度参与一到两个项目边做边校验架构设计。只做现状不做目标架构沦为文档归档。现状梳理是必要的但如果架构文档只描述现在是什么样没有描述两年后应该是什么样以及从现状到目标怎么走那它对决策就没有价值。目标架构不需要很精确但必须有明确的方向和阶段划分。忽略数据架构后期返工代价高昂。前面提过的供应链项目就是典型主数据编码不统一的问题拖了四个月才收拾干净。这件事让我在后来的项目里坚持一个原则数据架构的主数据识别必须在应用开发启动前完成哪怕只识别出最核心的两三个实体。技术架构的例外审批形同虚设。技术栈收敛的规则定得再好如果例外审批是走过场收敛就失败了。我见过一个企业技术标准文档写得很规范但一年内批了四十多个例外最后技术栈比收敛前还乱。例外审批必须有人真正把关而且要定期统计例外原因如果是标准本身不合理就改标准如果是项目组图省事就该驳回。最后分享一个我在实际操作中的体会4A架构的价值不在于四份文档有多完整而在于它能不能在关键决策时刻提供依据。当一个新需求来了能不能快速判断它该落在哪个应用、动到哪些数据、需不需要技术架构支持当一次组织调整来了能不能快速评估哪些系统边界要跟着动。能回答这两个问题这套架构就是活的回答不了文档写得再厚也只是摆设。所以我现在的做法是每季度拿两三个真实需求去考一遍架构资产考不过的地方就是下一轮要补的地方。
