所以当谈到数字化转型，关注房间里面的大象的时候，我们不得不重新提起康威定律。在数字化转型的企业中，仍然采用传统的组织结构，一定会成为数字化转型道路上的障碍。康威定律是美国人Melvin Conway在1967年发表的论文《How Do Committees Invent?》提出的。这条定律指出“organizations which design systems are constrained to produce designs which are copies of the communication structures of those organizations。”翻译过来就是：设计系统的组织其产生的设计等同于组织间的沟通结构。这个定律通俗来讲，就是我们生产的产品和我们的组织要匹配。甚至在某种程度上，组织的架构决定了产品的架构。虽然康威定律只是Conway本人基于软件开发的经验，但是康威定律最后发展成为对架构以及团队管理普遍现象的总结。康威定律描述的是组织中人的思维模式，这种模式的影响自然是多方面的。为什么组织架构会决定产品架构，我们来看另一种情况：如果你将一个软件模块交给二个人合作完成，很可能得到一个由二个子模块构成的软件模块。同理，把一本书交给十个人合作完成，最终这本书的很有可能分为十章。组织架构的模式决定了分工，而分工决定了我们的产品交付。这当然不是我们需要的结果。客户只会为最终的产品付费，但是如果我们的企业的组织分工和职责定义是混乱的，它所产生的产品有非常大的可能也是混乱的。由产品或者价值来决定组织，还是根据组织来开发产品，这个结论非常明确，但是真正执行起来就远没有那么容易了。就像我们都知道要先了解房间里的大象，但是真正能把企业里面的大象摸清楚的又有多少呢，有的企业很多信息系统处于“僵尸状态”，但是这些系统存储了大量的数据，记录着大量信息，成为一个随时都可能爆炸的炸弹。回到数字化转型这个话题。我们通过康威定律可以知道：第一，人与人之间的交流是复杂的，每个人的精力是有限的，因此当问题很复杂，需要协调地去解决时，需要将组织划分进而提高沟通效率；第二，团队成员工作的系统设计依赖于成员之间的沟通，管理人员可以调整划分模式，实现团队之间的不同沟通方式，这也会影响系统的设计：第三，不要一次性试图构建一个完美的复杂系统，要通过容错性和故障恢复率进行优化。所有近似于完美的系统都是通过开发迭代的方式产生的。所以在数字化转型的企业中，当我们聚焦企业内部沟通时，应利用一切手段提高沟通效率，每个人和每个系统必须有明确的职责，在遇到问题时，知道该找谁去解决；其次，要尽可能的采用与系统设计相一致的团队，以扁平化和以业务为基准的方式去简化团队，每个小团队之间必须有对应负责的模块，避免模糊的界限，以免在发生问题时互相推卸责任；第三，要做小而美的团队，人员数量的增加会降低效率以及加大成本，亚马逊CEO Jeff Bezos有个一个经验法则：如果两张披萨对于一个团队来说不够，那么这个团队就太大了（想想两张披萨够几个人吃）。此外，DevOps是另外一个关键。DevOps可以拉动所有相关方——产品管理、开发人员，甚至文档——整合到一个更有凝聚力的团队中。这个想法是通过专注于表达为用户目标的特定任务，通过快速短周期的迭代来阐明目标（称为故事），打破了传统的软件开发瀑布式方法。DevOps 实质上是一种文化转变，打破了开发人员、运营和利益相关者之间的固有壁垒。当然，文化变革比 DevOps 或敏捷或其他方法难度更大。但这是一种必然的结果，我们把将每个人都放在同一个团队中，改变沟通方式，才能最终改变结果。速度是 DevOps 的另外一个优势。纵观整个发布过程，所有这些不同团队需要共同参与，将软件推向用户。当软件的发布相对不频繁时，这种长期的、反复的高强度更新迭代是可以控制的。但是，如果软件在每年的发布变成多达上百次（其实在像亚马逊这样的公司，发布过程每天可能发生数百次），那么我们必须用DevOps的方法，将紧急的、全员参与、运动式的开发过程，转变为更顺畅、更多团队规划、开发、测试和部署之间的可持续迭代的过程。这就是为什么DevOps 团队能够让生产力快速增长——因为整个生命周期都是可重复的。无论您的最终应用架构是更精细的单体还是分布式微服务。