您的管道如何反映您的组织结构

与 DevOps 相关的“定律”之一属于一位名叫梅尔文康威 (Melvin Conway) 的程序员。 他的定律是在 1967 年提出的，简单地说就是“设计系统的组织……被限制产生与这些组织的通信结构相符的设计”。

我强调“系统”这个词是因为康威定律往往只适用于应用程序。 对于软件系统来说。 但事实是，“系统”涵盖了从应用程序到交付和部署它们的集成管道的一切。 你的管道。

当我们谈论在部署方面（即生产）采用 DevOps 方法时，我们还需要了解康威定律等相关原则。 因为该定律适用于部署管道的设计，就像它适用于推向市场的应用程序一样。

您可能还记得我们 2019 年application服务状况中的两个问题。 第一个问题询问的是 IT 的组织结构——联合运营、单一职能还是跨职能团队。 我们发现，在 2000 多名受访者中，近一半（46％）的人都是以单一职能团队的形式组织的。 联合行动以 37% 的成绩位居第二。 跨职能团队不太常见，只有 15% 的受访者采用这种结构。

现在，当我们转而检查部署管道自动化的状态时，这一点很重要。 因为结果肯定是单一功能团队主导地位的体现。

这里的数据显示，不一致的自动化努力不会帮助实现近一半（48％）受访者在数字化转型方面的目标，即更快、更频繁地部署应用程序。 IT 内部这些既定领域之间的差异是康威定律适用于任何地方的任何系统的存在证明。

深入挖掘后我们发现，只有十分之一（11%）的企业仅实现了其中一个领域的自动化。 四分之一（25%）的企业已成功实现两个或三个领域的自动化。 超过五分之一（21%）的受访者已经实现了完成全自动自动化部署流程所需的所有四个主要领域的自动化。

其中相当大比例（42%）的域自动化程度为零。

部署管道中自动化的不平等是价值实现时间难题的一个重要部分，因为每次在管道中遇到手动过程时都会产生延迟。 这种延迟会减慢实现价值的时间（或者如果你愿意的话，减慢上市时间）。 费率的差异表明了组织保留“单一功能团队结构”的影响，因为我们看到单个“孤岛”实现自动化，而很少或根本不关心它如何与管道的其余部分交互。

这就是为什么联合行动或跨职能团队结构更受青睐的原因。 因为IT领域之间的沟通渠道成为一个对等过程，更好地促进了跨多个关注点的系统的设计。 当一个团队设计管道（系统）时，他们能够将管道作为一个整体而不是其复合部分来考虑。

自动化工作本身可能（也可能应该）由领域专家处理。 但总体设计和集成方法（API）需要在一个开放、协作的团队中进行设计，否则我们最终会得到自动化孤岛，这些孤岛可能会或可能不会实现更快、更频繁地进入市场的业务目标。

因此，如果您在尝试实现生产流程自动化时遇到延迟或弯路，请退一步考虑现有的组织结构以及它们如何影响该流程的设计。 你可能会发现，在有效地实现任何自动化之前，你需要推动更有效的组织结构来支持这项工作。