2026年再看数字化转型很多团队已经过了“上系统、接流程”的阶段卡在了更尴尬的位置该买的软件买了该建的平台建了业务部门却怨声载道——数据对不上、流程走不顺、新项目反复返工。我这两年做过的几个架构咨询项目几乎都是从这个困境开始的。大家不缺数字化投入缺的是把投入串起来的那条主线。这条主线就是企业架构。而TOGAF®框架恰恰是行业内应用最广、也最能落地的架构方法论之一。这篇文章我想结合2026年的技术环境聊聊TOGAF在数字化转型里到底扮演什么角色哪些环节真正决定了项目成败以及我在实际项目中踩过哪些坑、又用什么办法绕过去。内容会覆盖ADM方法论的拆解、一次完整架构落地实战的复盘、架构资产治理的痛点还有AI和敏捷浪潮下TOGAF怎么调整姿势。不管你是企业架构师、技术负责人还是刚接触EA的转型项目成员应该都能找到能直接拿去用的东西。1. 2026年的数字化转型为什么绕不开企业架构1.1 深水区困境系统越多业务越乱先说个典型场景。某制造集团以下简称A公司找我做架构梳理的时候光ERP周边就挂了七十多个系统客户主数据在CRM、订单系统、售后平台各存一份同一个客户编码规则都不一致。业务部门每次提需求IT都得先回答“这个数据到底信谁的”一答就是两三个月。这不是个别现象。数字化转型走到2026年大部分组织的IT资产已经极度“繁荣”但这种繁荣是碎片化的每个部门都有自己主导建设的系统每条业务线都有自己的数据口径中台建了又拆、拆了又建。问题不在单个系统的能力而在系统之间缺乏统一的架构约束。没有架构就没有全局决策的依据技术债会每年复利式增长。1.2 TOGAF凭什么成为“默认选项”市面上做架构的框架不止一个但TOGAF能成为多数组织的事实标准核心原因是它的中立性和完整性。它不绑定任何厂商、不偏向某类技术栈提供的是一个标准化的架构开发流程——ADM以及一套通用的架构内容模型。这意味着无论你底层是SAP、用友还是自研系统无论技术团队偏爱云原生还是微服务都能在这个框架里找到自己的位置。另一个关键点是TOGAF高度可裁剪。很多团队一听TOGAF就害怕觉得流程太重但2026年的TOGAF早已不是那个“必须全套流程走完”的框架。它支持按场景、按项目规模灵活取舍你可以只做业务架构和架构愿景也可以跳过某些阶段直接做迁移规划。框架是骨架填充多少血肉完全看组织当前需要什么。1.3 企业架构在2026年的新内涵过去理解企业架构多多少少偏“IT架构”服务器怎么摆、系统怎么连。但2026年讨论企业架构边界明显扩大了。业务架构和数据架构被提到了第一优先级因为数字化转型本质上是业务模式的转变技术只是承载手段。我接触的成熟企业架构团队里业务背景的人占比越来越高很多公司干脆把企业架构部归到战略规划线而不是IT运维线。更重要的是AI的兴起让“架构”的内涵又深了一层。数据资产如何被安全地用于模型训练智能应用怎么与既有系统协同算法模型的版本、权限、合规如何治理——这些都要在架构层面先行设计而不能等AI项目启动后再补。架构的角色从“连接IT与业务”变成了“连接人、流程、数据、系统与智能体”。这也是为什么我认为2026年做数字化转型启动任何一个大型项目前都应该先回答“它的架构位置在哪里”。2. ADM方法论TOGAF的核心引擎拆解2.1 ADM为什么是一个循环而不是一条直线TOGAF最核心的方法论叫ADMArchitecture Development Method它把架构工作分成从预备阶段到架构变更管理的一串阶段。很多人第一次看ADM图会困惑为什么箭头是一个环为什么不从现状一路做到目标就结束我的理解是ADM反映的是一种“演进式架构”的思维方式。企业架构不是交付一次就永久固定的蓝图它要随着业务环境、技术环境持续调整。A公司做完目标架构后第二年行业政策变了供应链策略调整原有架构就必须重新进入A阶段做愿景修正。把ADM设计成循环本质上是承认“架构永远没有终态只有当前态”。实际执行中我并不建议把所有阶段都做成标准动作。完整的ADM周期适合年度级的架构规划而季度级的架构迭代只需要走“愿景-业务架构-技术架构”的快车道。关键在于团队要理解每个阶段解决的问题而不是机械地套用模板。2.2 预备阶段和A阶段决定项目成败的20%工作量很多项目翻车不是因为后期架构设计做不好而是前置工作敷衍了事。预备阶段Preliminary要确定架构原则、治理机制和工具平台A阶段Architecture Vision要明确项目范围、识别干系人、定义核心业务目标。这两个阶段加起来往往只占20%的时间但决定了后面80%的方向。我见过最快的翻车模式是跳过预备阶段的架构原则直接进入现状调研。结果设计出来的目标架构每条线都觉得自己部门的系统“必须保留”最后目标架构跟现状几乎没有区别。正确的做法是先达成共识数据必须唯一来源、系统必须共享服务化、新需求必须先过架构评审——原则列清楚后续设计才有判断依据。干系人管理也是A阶段的重头戏。架构愿景不是架构师自嗨的产物而是CEO、CFO、业务VP、IT总监在同一个房间吵出来的共识。我在项目中通常会组织三轮愿景工作坊第一轮收集期望第二轮明确取舍第三轮签字确认。三轮下来项目范围基本就锁死了。2.3 B/C/D阶段从业务到技术的逐层落地ADM的B、C、D三个阶段分别对应业务架构、信息系统架构数据应用和技术架构这是整个方法论最“硬核”的部分。B阶段业务架构回答“业务应该怎么运转”梳理业务流程、组织能力、业务对象识别改进点。很多人把业务架构等同于画流程图其实它更核心的是识别“业务能力地图”——一个组织必须具备哪些能力才能达成战略目标哪些能力要自建、哪些可以外包、哪些要用AI增强。C阶段信息系统架构拆成数据架构和应用架构两个维度。数据架构关注数据实体、数据流、数据生命周期应用架构关注应用组合、系统间交互、接口设计。这两个维度是数字化转型中最容易暴露问题的区域比如“数据中台到底该放哪些数据”这种经典争论本质上就是数据和应用的边界没定清楚。D阶段技术架构则是把上面的设计落到基础设施层面云平台、网络、安全、中间件。2026年还要额外考虑AI基础设施包括算力调度、模型部署平台、数据血缘与模型资产管理。技术架构往往是最“性感”的部分但我想提醒一句不要在D阶段才想起来业务架构还没定清楚。我见过某项目直接跳到技术选型做容器化改造结果业务架构还是老一套审批流改造完的系统只是“跑得更快的老系统”。3. 从基线到目标一次制造业数字化转型的架构落地实录3.1 项目背景与范围界定2025年底我参与了一个模拟项目以下用X项目代称的架构设计工作。X项目是一家中型制造企业的数字化转型规划产品线有五条年产值数十亿核心痛点有三个一是销售、生产、采购三大板块的数据口径不一致二是订单交付周期被过多的线下协调拖累三是新产品导入流程涉及十几个系统数据传递靠人工录单。项目范围界定用了一个A阶段的标准工具架构愿景图。我们把战略目标拆成四条价值流——订单到交付、需求到产品、采购到付款、问题到解决每条价值流对应一个端到端的业务能力改进方向。这一步非常关键它让董事会看到的是“业务价值”而不是“IT系统重构”。3.2 现状架构分析真正花时间的环节现状架构分析基线架构基线是我认为最容易被低估工作量的环节。X项目仅业务架构梳理就花了三周访谈了生产、销售、采购、财务、质量五个部门的四十多位关键用户。这个环节不要指望通过阅读文档就能完成。文档记录的是“制度上的流程”实际跑的是“桌面下的流程”。我和团队采用了“跟单法”——跟着一张真实订单从创建到交付走一遍所有人工介入的点、Excel中转的点、电话确认的点全部标记出来。最终产出的现状业务架构图让管理层第一次直观看到订单要经过27个手工环节才能完成录入。数据架构现状更惨光物料主数据的来源就有四种渠道库存数据在ERP和WMS之间靠定时任务同步经常晚上对不上账。现状分析的意义不是为了批评过去而是为后面的目标架构设计提供“差距基线”。没有真实的现状目标架构就只是空中楼阁。3.3 目标架构设计与差距分析目标架构设计分三步走。第一步基于战略推导目标业务架构订单交付周期从45天压缩到21天那么组织考核、流程设计、系统交互都要围绕这个目标重新排布。第二步设计目标数据架构建立以物料主数据、客户主数据、供应商主数据为核心的单一数据源体系明确每个数据域的唯一系统归属。第三步才是目标应用架构和技术架构尽可能复用现有系统能力在薄弱环节引入新平台。差距分析是最考验架构师功力的环节。X项目的差距清单一共列了56项每一项都要落到“现状-目标-差距-举措-优先级”五列矩阵中。这里我又踩过一个坑一开始把差距写得过于技术化业务领导根本看不懂评审会上冷场。后来改成“业务痛点-影响金额-优化方向”的表达方式讨论立刻活跃了。3.4 迁移规划与实施治理目标架构设计完成后最常被跳过的就是迁移规划F阶段。实际上转型失败的项目很多不是死在设计上而是死在“如何从今天走到明天”的路径上。X项目的迁移规划我们采用了“四批次演进法”第一批只做主数据治理和数据接口标准化不动业务流程第二批上线订单交付优化替换掉线下Excel传递第三批做产销协同打通计划和库存第四批才是AI预测补货等增强能力。每一批都有明确的业务收益和退出条件而不是“大爆炸式”切换。实施治理G阶段同样关键。项目进入实施阶段后我们建立了每周架构评审会制度所有跨系统接口、数据模型变更、新增应用选型都必须过架构评审。这一条在贵司听起来像增加流程负担但实际效果是总共三轮评审中拦下了两次不该发生的技术方案偏移避免了两笔数百万的重复投资。4. 最容易翻车的环节架构资产治理与架构原则执行4.1 架构仓库建立先把台账做对企业架构做得好不好一个很直观的评判点就是架构资产是否有一个公认的“唯一视图”。很多团队做了架构项目交付物散落在个人电脑、共享网盘、项目管理软件里等过了半年想查询某个系统的接口关系根本找不齐。这就是没有架构仓库Architecture Repository的后果。我在多个项目中形成的经验是不要追求一步到位建一个大型架构管理平台先从“一表一图一库”做起。一张架构资产清单一张系统关系图一个架构原则库。用企业微信文档就能搭起来关键是命名规范、责任人明确、定期更新。X项目甚至前三个月只用Excel管理架构资产等到资产条目超过200条才迁移到专业工具。工具永远是服务于治理机制的治理机制没建起来再贵的工具也是摆设。4.2 架构原则从纸面到落地架构原则写起来很容易难在执行。我见过几乎所有企业都有“数据同源”这条原则但实际跑起来还是各存各的。问题出在哪里出在原则没有配套的“裁判机制”。架构原则的落地需要三件套一是原则的细化解释必须落到具体场景比如“数据同源”要解释成“物料主数据由MDM系统唯一维护其他系统通过接口引用禁止另建字段”二是原则的裁决流程当业务部门提出违背原则的需求时谁来裁、怎么裁、有没有替代方案三是原则的复核机制每季度检查一次实际系统建设与原则的偏离度偏离项要么整改、要么正式修订原则。举个例子X项目有一条原则“所有新增系统必须支持单点登录”。后来某个部门引入了一个小型统计工具因为技术老旧不支持标准协议差点就上线了。幸好评审会依据这条原则拦了下来换成支持标准的方案避免了后续账号体系的碎片化。原则有没有用就看敢不敢用。4.3 合规评估的常见误区架构治理中还有一个高频误区把合规评估做成了“文档审查”。我之前在某公司审查一个自研系统的架构设计对方提交了厚厚一叠架构描述但仔细比对后发现核心模块的部署方式根本不符合既定的容灾要求。这说明合规评估不能只看“有没有文档”要看“实际架构是否符合设计目标”。更早的时候××项目还发生过一次乌龙系统上线后我们才发现数据同步用的是直连数据库的方式把既定的消息总线方案绕过去了。问题不在于技术上直连不可用而在于绕过了架构管控后后续接口的演进失去了统一的治理入口数据血缘也失去了追溯依据。合规评估必须包含运行态的架构巡检而不只是设计态的评审。5. 2026年TOGAF与新技术共舞AI、云原生与敏捷5.1 敏捷开发与EA的冲突与和解EA和敏捷在不少团队里被视为对立面EA喜欢规划、要文档、讲流程敏捷讲究响应变化、轻文档、快速交付。但做久了你会发现二者冲突的前提是管理粒度失当。我的观点是敏捷交付的是产品EA治理的是能力。分层处理互不干扰。在能力层业务架构和数据架构必须有相对稳定的长期规划比如“客户主数据唯一化”“订单到交付的流程主线”这些不能频繁变动在交付层具体到某个接口的实现、某个页面的交互完全可以按敏捷节奏快速迭代。TOGAF在2026年的实践里很多团队只保留B/C阶段的架构底座D阶段技术架构按云原生的持续演进模式来管理既保住方向又释放速度。5.2 AI对架构治理的新要求2026年的架构治理躲不开AI这个主题。之前某金融客户F公司让我帮忙评估一个智能客服项目的架构边界他们原本只想引入一个大模型助手但梳理后发现这个助手要访问核心业务系统的数据要对接工单系统、知识库和用户画像系统涉及的数据权限和合规问题远超预期。从企业架构视角看AI引入带来的新架构对象至少有三个模型资产版本、训练数据、部署环境、提示词资产业务规则、合规约束、推理调用链模型与业务系统的交互路径。这些都需要纳入架构仓库进行版本管理和权限管控。更麻烦的是评估逻辑的治理——当AI的决策会改变业务操作时谁来定义边界、谁来兜底这同样是架构设计的问题不是模型调优的问题。TOGAF本身的框架框架在这个领域提供了很好的“容器”把AI当作新的应用组件和数据消费者来看待用既有的数据架构、应用架构、技术架构去承接它再用新增的AI治理对象去扩展它。不需要推倒重来但必须在架构层面预留AI的位置。5.3 我建议的落地姿势最后说说我在2026年给企业架构团队的几个落地建议。第一别急着全面铺开。挑一条业务价值最高的价值流作为试点用TOGAF的裁剪版完成一轮端到端架构梳理让管理层看到架构的实际产出。X项目就是从“订单到交付”这单条价值流切入的三个月就出了可视化的差距清单和项目路线图后续全公司推广才顺理成章。第二把架构能力建在业务侧。企业架构师如果全部挂在IT部门很容易被当成“技术统筹”。更有效的模式是建立“业务架构师数据架构师技术架构师”的铁三角团队业务架构师要从业务部门抽调数据架构师懂数据和模型技术架构师熟悉底层平台。三人共同对一条价值流的端到端架构负责。第三要舍得在架构资产上投入维护资源。很多组织做架构项目时全员投入项目一结束架构仓库三个月没人更新第二年就废了。至少投入一个人持续维护架构资产成本极小但能让架构的保质期从半年延长到三五年。我在实际项目中最大的体会是TOGAF不是用来装点流程门面的理论而是一套逼着组织想清楚“从哪里来、到哪里去、怎么走”的思考框架。2026年数字化转型的技术工具遍地都是缺的从来都是把工具组织成体系的整体观。只要能在业务目标与IT实现之间不断保持那条清晰的映射链企业架构的价值就会一直存在。哪怕AI再发展十年架构这个“翻译层”也不会消失只会变得越来越重要。
