我们公司去年被收购了，到现在刚好一年。虽然我们公司跟集团比规模很小，差不多是集团的1/20吧，但是我们公司也是有自己一套完整的业务系统的。在收购初期做了一些融合的业务需求，两边产研经过很长时间探讨做了一套方案，从结果上看还是不错的。

经过近一年的融合，业务和技术都比较稳定了。因为考虑到这块业务整体的迭代效率，公司决定把集团里融合的这部分业务也统一交给我来负责。

我这才有机会看到融合方案的全貌。

真正理解“组织架构决定技术架构”

很多年前第一次看到“组织架构决定技术架构”这句话的时候，很不能理解。我当时的认识是：技术架构就应该是清晰、抽象、结构合理的，绝不能因为组织架构原因就做出不合理的设计。

这么多年的工作经历下来，虽然慢慢地比较认可了这句话。但是因为以往经历的公司规模都不是特别大，所以做方案的时候还是可以从全局考虑去做的，也有能力推动“自上而下”的执行，所以技术架构基本还是“技术决定的”。

但这次完全不一样。

简单介绍下融合逻辑

我们公司和集团是同一个业务类型的公司，但是经营的品类不太一样。所以融合初期目标是：我们的所有业务系统全部融合到集团的各业务系统和平台系统里去。

和我们直接对接的是部门A，A部门拿到我们的结构化数据后，再转换成其他业务系统和平台系统的数据结构做对接和存储。然后B部门再从这些存储里拿到这些数据去做展示，但是因为集团原来没有这块业务，所以主要以我们的产品逻辑为主，所以B部门又得把数据再转成我们的结构化数据去做展示。

如果集团的这块业务不交给我负责，这块架构感觉上也是合理的，但是现在要把A、B这两个部门涉及到的这部分业务统一交给我来负责，感觉就很傻了。为了做集团的业务，我需要把结构化的数据转成非结构化数据，自己再把非结构化的数据转成结构化数据去做展示。

有种累二傻子的感觉。

思考

小团队的时候，技术架构就是技术人“拍脑袋”就可以决定的。

但当你开始跨部门协作，跨 BU 融合，尤其是站在大组织视角去理解系统的时候，你会越来越明白组织架构决定技术架构，很多时候不是说你技术能力行不行，而是要先考虑组织架构关系再去考虑技术架构的设计。

后面一段时间就得快速去调整这块架构了，得快速把研发成本降下来，但是又不能影响过程中正常业务需求迭代，也是一个不小的挑战。

继续加油吧💪🏻