甲骨文系统扛了17年，CTO发现架构债比房贷还重

87%的企业数据架构决策，是在现任数据负责人入职前完成的。这不是考古，是日常。

一位IT总监拉开白板，上面躺着2017年仓促上云的草图、按项目预算切割的数据仓库、以及那个"临时用用"却扛了17年的Oracle本地集群。数据策略师的第一反应是评估差距——这套东西离理想架构有多远？这个本能，错得离谱。

架构是遗产，不是选择题

你接手的不是系统，是一连串当时合理的妥协。

2019年建数据湖是因为那年流行数据湖，治理？以后再说。Oracle环境本应是过渡方案，却慢慢长成了组织的脊椎——每一根神经都绕在上面。预算按项目批，数据就按项目孤岛存；云迁移赶进度，架构一致性就成了奢侈品。

这些决策的当事人早已离职，但它们的复利还在。每新增一个数据管道，都在加固原有的路径依赖。所谓"数据战略"，往往是在给十几年前的选择题补交答卷。

评估 gap 是陷阱，理解 context 才是起点

新手数据负责人容易掉进一个坑：拿着行业最佳实践当尺子，量完发现处处不及格。但那张架构图真正的信息密度，在于"为什么长这样"——当时什么约束条件、谁拍板、妥协了什么、换来了什么。

Oracle集群能活17年，说明它解决过真问题，也绑架过真业务。数据湖没人治理，可能是因为建它的人当时汇报对象是CTO，而治理负责人向CFO汇报。组织切片决定了数据切片，技术债务本质是组织债务的硬化。

策略从承认约束开始

有用的数据战略，第一步不是画未来蓝图，是写清楚现有架构的"病历"：哪些决策还在付息，哪些已经破产，哪些意外成了资产。

那位IT总监的白板，其实是份组织记忆。数据策略师的工作，是从这些陈年老决策里，辨认出哪些约束已经消失（比如当年赶进度的云迁移已完成），哪些约束依然坚硬（比如预算仍按项目切）。

架构选择先于你存在，但解读它的权力在你手上。问题是：你会把它当遗产继承，还是当债务清算？