首先我觉得大数据部门，是一个过渡产物，我之前在主推DataMesh的时候，就意识到，大数据部门这个组织结构，仔细看企业的架构，它其实是个奇葩。

举个例子，从企业的职责能力来说，需要两种能力：

  • IT运维：负责提供基础设施架构，例如K8S，甚至是机器硬件这类业务无关的通用基础设施。
  • 业务服务：这就是各个业务单元自己基于业务开发的服务，可能写成Dockerfile或者就是个war去部署。

这个划分非常正交，各司其职，直到，大数据和AI这些乱七八糟的东西出现。

当大数据出现的时候，一个企业在搞大数据的时候，会发现他会碰到这样的问题：

  • 业务微服务了，各个数据在不同的服务下，可能是不同的业务子团队负责，某一个服务很难拿到所有的数据。
  • 大数据的部署，运维，还是很复杂的，并不是简单的安装一个软件就结束，不能单纯的站在软件安装部署运维的视角去管理，因为大数据平台还不是那么标准化。

再结合前面那个企业的职责，就会发现如果把大数据的事情，交给IT，意味着IT团队从人员能力要进行改头换面的改造，短期搞不定，甚至硬件都要涵盖GPU的管理。

如果把大数据的事交给业务服务团队，会发现他们又会打破以前的分布式服务的理念，把不同的业务放到一起，来进行挖掘和分析，这对业务团队的管理和组织是一个非常大的挑战。

考虑到这样的情况，于是很多企业选择了成立一个独立的数据部门，把这一摊子夹缝中的业务做起来。

这样的话这个数据部门就奇葩了，向上需要支持业务，向下又要和IT商量预算，有的企业可能独立的很彻底，数据的预算是完全独立的。

这种情况导致了数据部门看起来风风光光实际上苦不堪言，本质上我觉得都是因为基建和业务在技术更替上掉队了。

从长远来说，数据必然会演化成能力，而不是一个组织部门，会融合到其他部门，最终企业存在的依旧是IT和业务。

当然有人会说，我把数据部门划分到it下，作为一个子团队不就好了吗，这种情况属于硬揉，会翻车。

扫码手机观看或分享：