在做了几个央国企数字化转型规划项目之后，几乎每个信息化负责人都会来找我聊同一个问题：

"我们花了大价钱请了顾问、做了TOGAF架构规划，搞了两年，什么都没变。"

两年、几百万咨询费、厚厚一摞架构文档——最终结论是"什么都没变"。

这不是个别现象，这是系统性问题。

不是TOGAF不好，也不是这些企业不努力。

问题在于：工具没有错，错的是把工具用在了不适合的土壤上。

今天，我们用底层逻辑把这个话题讲透——TOGAF为什么在央国企行不通、业务架构为什么是核心症结，以及DoDAF能不能带来答案。

一、先搞懂TOGAF：它是为谁设计的？

在说"为什么不适用"之前，先要搞清楚TOGAF到底是什么。

TOGAF（The Open Group Architecture Framework），是由Open Group发布的企业架构框架，诞生于1995年，最新版本TOGAF 10发布于2022年。它的核心是ADM（架构开发方法），用一个循环的九阶段过程来指导企业架构的规划、设计和治理。

TOGAF把企业架构分为四个层次：

业务架构（Business Architecture）

↓

数据架构（Data Architecture）

↓

应用架构（Application Architecture）

↓

技术架构（Technology Architecture）

从上往下，业务架构决定数据架构，数据架构决定应用架构，应用架构决定技术架构。这个逻辑是对的，本身没有问题。

但TOGAF是为谁设计的？

它诞生于西方成熟市场经济体系下的大型企业——典型的使用者是金融机构、跨国公司、科技公司。这类企业有几个共同特征：

业务逻辑由市场竞争驱动，可以根据战略自主调整组织架构相对灵活，可以为架构优化而重组IT治理由内部决策，架构师有实质性影响力目标是商业效率最大化

关键认知：TOGAF的底层假设是"业务可以被重新设计"。它的ADM第一步就是业务架构——因为在市场化企业里，重新定义业务逻辑是可行的，甚至是必要的。

但央国企的情况，完全不同。

二、第一道墙：央国企的业务架构，很难改变

TOGAF的逻辑是：先做业务架构，再推导出数据、应用、技术架构。

这个逻辑正确。

但问题在于：央国企的业务架构，根本不是一个可以被"设计"的变量。

为什么？

央国企的业务架构，是由以下几个强约束共同决定的：

1 政策与监管约束：国资委、行业监管部门对央国企的业务边界、经营范围、运营模式有严格规定。你不能说"我觉得这个业务线效率低，重新设计一下"——监管不允许，政策不允许。

2 历史遗产约束：大多数央国企有几十年的运营历史，业务流程、组织架构、人员配置已经深度耦合。改一个业务流程，可能涉及跨部门利益调整、历史数据迁移、工作职责重定义——牵一发动全身。

3 政治生态约束：央国企的决策逻辑不完全是商业逻辑，还有行政逻辑。架构师提出"重组业务架构"，面对的不仅是技术挑战，还是政治挑战——谁的权力被削减了？谁的利益被调整了？

4 使命导向约束：央国企的核心使命不仅仅是商业效率，还包括保障供应、稳定就业、服务国家战略等政策性目标。这些目标有时候与效率最优是矛盾的，但它们不能被"架构设计"所优化掉。

这四重约束叠加在一起，决定了一个基本事实：

央国企的业务架构，不是"可以被重新设计"的变量，而是"必须被接受"的约束条件。

TOGAF的第一步——业务架构——在央国企语境下，根本无法真正执行。你能做的，充其量是"把现有业务架构描述清楚"，而不是"重新设计业务架构"。

这就是TOGAF在央国企遭遇的第一道墙。

很多咨询顾问绕过这道墙的方式，是写一份"理想的业务架构"，然后说"未来目标态"。结果就是：目标态和现实态之间有一条无法逾越的鸿沟，规划成了摆设。

三、第二道墙：业务架构不变，其他架构只能小修小补

假设第一道墙已经被接受了——我们承认业务架构改不了，那往下做数据架构、应用架构、技术架构，能不能有实质性突破？

答案也是令人沮丧的：很难。

原因在于架构设计的根本逻辑：

架构的本质 = 对业务需求的技术化表达

业务需求不变 → 架构需求不变 → 架构只能优化，无法重构

举个具体的例子：

某央企的核心业务是"工程项目管理"。它的业务逻辑是：项目立项→预算申报→招投标→施工管理→竣工验收→结算审计。这个业务流程已经固化了30年，由多个部门、多层审批共同完成。

现在，你想做数字化转型，重新设计数据架构。

但数据架构必须服务于业务架构。业务流程没变，数据的产生方式没变，数据的使用方式没变，你能做的，只是把原来散落在Excel和纸质文档里的数据"搬"到系统里——这是信息化，不是数字化。

真正的数字化，是用数据反过来重塑业务决策方式——比如用实时数据来动态优化施工排期、用历史数据来预测风险节点。但这需要业务架构的配合，需要决策权的重新分配，需要业务流程的重新设计。

而这，又回到了第一道墙——业务架构改不了。

一个残酷的判断：在业务架构不变的前提下，所有的数字化工作，本质上都是"信息化升级"，而不是"数字化转型"。

两者的区别不是技术程度的高低，而是是否用数字改变了业务运作的底层逻辑。

这不是批评央国企不努力，而是指出一个系统性的结构困境。

在这个困境里，TOGAF给出的方法论——从业务架构开始，向下推导——是正确的，但无法真正落地，因为第一步就卡住了。

四、DoDAF：它能解决问题吗？

说完了TOGAF的问题，我们来看一个经常被提起的替代方案——美国国防部架构框架（Department of Defense Architecture Framework，简称DoDAF）。

DoDAF是美国国防部为其复杂系统集成而开发的架构框架，2004年发布，2010年发布2.0版本。它用"视图"（Views）来描述体系，核心有八类视图：

DoDAF八大视图：

AV（全局视图）：架构总览与字典

OV（作战视图）：作战任务、活动、信息流

SV（系统视图）：系统功能与互联

DIV（数据与信息视图）：数据标准与关系

StdV（标准视图）：技术标准与规范

SvcV（服务视图）：服务与互操作

PV（项目视图）：项目时序与依赖

CV（能力视图）：能力目标与差距

DoDAF的核心优势是：它不要求改变"作战任务"，而是在既定任务框架下，描述如何实现任务目标的系统集成能力。

听起来，这和央国企的处境很像——任务使命是既定的（政策决定），需要在既定使命下做好系统集成。

那DoDAF适合央国企数字化规划吗？

我的判断是：DoDAF有参考价值，但不能直接套用，原因有三。

原因一：DoDAF的设计背景是"武器系统集成"，不是"企业运营管理"

DoDAF诞生于美国国防部对多种武器系统、情报系统、指挥控制系统进行互联互通的需求。它的核心问题是：如何让不同的系统协同完成作战任务？

这和央国企的核心问题（如何支撑业务运营、如何实现管理数字化）有本质不同。

DoDAF非常擅长描述"任务与系统的映射关系"，但不擅长描述"业务流程优化"、"数据驱动决策"、"用户体验改善"——而这些恰恰是央国企数字化的主战场。

原因二：DoDAF对"视图"的要求极高，落地成本巨大

DoDAF的完整实施，需要产出数十个视图、上百个模型。

在美国国防部，有专职的"架构师团队"常年维护这些模型，并且有成熟的工具链（如IBM Rational DOORS、SPARX Enterprise Architect）支撑。

对于大多数央国企，既没有这样的团队，也没有这样的工具体系——更没有这样的文化基因（做这么多文档，最后能不能落地？）。

原因三：DoDAF缺乏"人"的维度

央国企数字化最大的挑战，不是技术，而是人——人的能力、人的意愿、人的利益。

DoDAF和TOGAF一样，都是"以系统为中心"的框架，对组织变革管理、利益相关者分析、变革阻力处理，几乎没有涉及。

但在央国企，这恰恰是决定数字化成败的关键变量。

小结：DoDAF的"使命-能力-系统"三层映射思维，对央国企有一定借鉴价值——尤其是在描述"既定使命下的能力缺口"这个问题上，DoDAF的CV（能力视图）视角很有用。

但DoDAF不是一个可以整体移植到央国企的框架。它需要被"本土化改造"，取其精华，结合央国企的实际约束重新设计。

五、真正的出路：为央国企量身定制的数字化规划路径

说了这么多"不适用"，那央国企数字化规划，到底应该怎么做？

从底层逻辑出发，我认为央国企数字化规划需要一个新的框架假设：

不是"设计最优架构"

而是"在既定约束下，找到最高杠杆点"

具体来说，这个框架有三个核心支柱：

支柱一：接受约束，而不是试图打破约束

把业务架构的"不可变性"当作设计输入，而不是障碍。在现有业务架构的基础上，精确识别出哪些环节可以通过数字化手段产生最大价值。

用DoDAF的语言说，就是：先做能力视图，识别现有能力与目标能力之间的差距，再设计填补差距的数字化方案。

这不是退而求其次，而是在有限空间里找到最高杠杆。

支柱二：从"流程自动化"走向"决策智能化"

业务架构改不了，但决策方式可以改。

很多央国企的数字化停留在"把手工操作变成系统操作"——这是流程自动化，价值有限。

真正的价值在于：用数据改变管理层的决策方式。不是让领导"查数据"，而是让数据"推建议"——从被动查询到主动预警、从经验决策到数据辅助决策。

这一步不需要改变业务架构，但需要改变决策文化和管理习惯。这是央国企数字化最难、也最有价值的那一步。

支柱三：以"场景"为单元，替代以"架构"为单元

TOGAF和DoDAF都是以"架构"为核心单元来做规划的——先建宏大的架构图，再推导实施方案。

但对央国企来说，这种路径太重、太慢、容错率太低。

更适合的路径是：以"场景"为单元来做数字化规划——先找到最痛的业务场景，设计最小可行的数字化方案，快速验证，再扩展到其他场景。

这与TOGAF的宏观规划路线相反，但在央国企的约束条件下，这是成功率更高的路径。

三个支柱的底层逻辑：

接受约束，在约束内找杠杆 → 不从业务架构变革出发，而从决策效率提升出发 → 不从宏观架构推演，而从具体场景验证

这是一条更务实的路，也是一条更能落地的路。

六、结语：工具没有错，错的是土壤不对

TOGAF是优秀的框架，DoDAF是严谨的体系。

但优秀的工具，必须用在合适的场景里。

把为市场化企业设计的TOGAF直接套用到央国企，就像把一套在沙漠里高效运作的供水系统，原封不动地搬到热带雨林——不是系统有问题，是环境不对。

央国企的数字化，有它独特的约束条件：业务架构的刚性、政策环境的约束、组织文化的惰性。

在这些约束条件下，我们需要的不是一个"理想架构"，而是一个"最优解路径"——在现实约束下，找到数字化价值最大化的那条路。

这条路，可能没有TOGAF那么系统，也没有DoDAF那么严谨。

但它能走通。

而能走通的路，比完美的地图，更有价值。