ACM通信
设计导向与优化
多年来，在软件工程中已经写了很多关于垂直和水平优化的文章，其中垂直通常代表领域用例中的功能深度，而水平代表常见的领域功能或基本的技术特性。这种优化位于技术架构、开发方法和组织设计的交叉点。优化技术轴的方法通常使用诸如“服务”、“数据”、“网格”、“架构”和“微观”等术语的组合来描述。关于开发方法和组织轴的对话可以包括“部落”、“公会”、“小组”、“章节”、“团队”、“自主”和“精益”。不管应用了什么标签，提出的基本问题是如何同时最大化两个轴上的输出。答案是，首先，这是一个很难的问题。第二，不要让任何人告诉你不同的说法。
自动驾驶是新的筒仓
让团队“自主”是一个流行的组织概念，并且在需求和目标设置方面经常与短语“自主”配对。拥有一个自主团队的意图是最小化外部依赖和潜在的进度阻碍，这是一个令人钦佩的目标。“自主团队”的定义意味着，在团队优先级之外思考的每一分钟都是浪费的一分钟;否则，它就不是一个自主的团队。因此，一个自主的团队倾向于垂直导向，拥有严格定义的涉众和用例。这种结构还有另一个术语:竖井。自治团队的热衷者可能不喜欢这种比较，但这是真的——而且这并不是一件固有的坏事，因为每个团队都在朝着一个确定的和文档化的目标前进。
然而，在单个组织中拥有多个完全自主团队的逻辑极端并不是很好，因为让每个团队选择自己的云提供商、开发语言、源代码框架、构建框架、存储框架、进程调度框架、监控框架、安全方法和治理等，在消除任何内部依赖关系的基础上(阅读:可能重新解决另一个团队已经解决的问题)，可能导致高度分散的环境，核心问题的处理不一致。每个团队在某种意义上都是“启用”的——这是一种好处——但以投资组合内聚的高潜在成本为代价。一种更实用的高效和明智的方法是水平组件和技术一致性的一些共性。但有多少共性才足够呢?筒仓要多少钱?
回顾黑客帝国和康威
这些问题听起来应该很熟悉，因为作为一个行业，我们以前就遇到过这种情况。事实上，有好几次了。矩阵管理始于20世纪50年代，并在70年代真正开始流行(数字设备公司显然是支持者)。矩阵管理被认为是通过创建一个有多行报告的组织图来打破竖井，目标是改善团队间的沟通和协作。再次,令人钦佩的目标。管理本质上就是一个人对另一个人说:“我需要你完成这项任务。”问题是，矩阵管理是另一个人要求你在此基础上做别的事情。希望附加任务与主要职责保持一致，但这并不能保证。最糟糕的情况不仅是资源和时间不匹配，而且分配给次要任务，从根本上与主要任务冲突。谁来解决这个冲突?人们很容易提出“另一位经理”作为答案，但在矩阵管理中，可能没有那么简单，因为复杂的话题可能需要几层讨论和升级来解决一个棘手的话题。
组织结构和治理对于确定集体优先级显然很重要，但是它对最终的软件交付物的影响甚至可以更进一步。康威定律是一个可以追溯到20世纪60年代的格言，它说组织设计的系统反映了他们自己的沟通结构。这可能一开始看起来像是一个警告或警告，但这种镜像发生是有实际原因的。一般来说，在同一个团队中，对于前面提到的诸如开发语言、源代码框架、存储框架等问题，人们会有相同的答案，这是必要的，因为从一个发布版本到另一个发布版本，从一个项目到另一个项目，与同事们重新讨论这些问题是很累人的。Conway定律描述的是一种优化策略，以及完全自主或半自主团队在这个术语流行几十年前的影响。对于任何给定的团队来说，自然强调必须优先考虑垂直(团队内部)而不是水平(团队内部)交互。
先垂直，再水平
因此，这两个极点是垂直优化(面向团队和功能用例)和水平优化(全局优化，以团队内部一致性为目标)。前者可以为任何单个团队提供好处，但代价是组织的凝聚力。后者的目标是组织100%的一致性，但可能以灵活性和响应能力为代价。就像生活中的许多事情一样，最佳点可能是在具体问题具体分析的中间位置，这需要功能和技术领导力。这并不容易，即使使用像“小队”、“部落”和“网格”这样的神奇词汇。
至少从我个人的经验来看，优先考虑纵向的，然后寻找横向的机会，是在组织的投资组合中开发解决方案的最实用的方法。虽然这是一篇关于软件开发的文章，但物理产品倾向于让这一点变得更简单:理解垂直是理解“车辆”的一般需求与理解轿车、卡车或坦克的特定需求之间的区别。每一个都有一个目的，但它们不是同一件事，支持一个功能通常意味着不能支持其他功能，或者至少不能很好地支持其他功能。要设计出符合上述情况的车型已经很困难了，更不用说效率极低的组合或不合适的车型，比如18轮轿车-卡车或轿车-坦克混合动力车。
一个现实生活中的警示物用于水平优化的用例是F-35联合攻击战斗机。设计用来取代至少四种不同的飞机(F-16, A-10, F-18和鹞式战斗机)，它的要求包括垂直起飞和降落，以及超音速飞行，以及不缺乏其他要求。这项技术花了几十年的时间来开发，据大多数人估计，它至少花费了1万亿美元。尽管F-35无疑是先进的，但大多数软件项目在“内部技术一致性”的旗号下，在产品开发的时间和资金方面都没有这样的跑道。有点讽刺的是，F-35交付时有三种型号(只有一种采用了垂直起飞)，我大胆猜测，大多数软件工程师都经历过概念上类似的情况，最初描述为“每个人都需要”的功能最终变成了昂贵的特例。
最后，水平功能确实很重要，但应该通过多个垂直用例进行验证。在没有用户的情况下构建水平服务是没有意义的。尽管大多数横向服务最终可能是“内部的”，但它们本身仍然是有效的产品，应该相应地配备人员，并且需要它们自己的开发路线图、发布版本和支持功能。
道格·梅尔是安大略省的一名投资组合架构师。他还创立了克利夫兰大数据Meetup在2010年。更多Doug的ACM文章可以在下面找到https://www.linkedin.com/pulse/publications-doug-meil
没有发现记录