ACM的通信
设计方向和优化
多年来，关于垂直和水平优化的软件工程中已经写了很多文章，其中垂直方向通常代表域用例中的功能深度，水平态度代表公共域功能或基础技术功能。这种优化位于技术架构，开发方法论和组织设计的交集。通常用诸如“服务”，“数据”，“网格”，“体系结构”和“ Micro”等术语组合来描述优化技术轴的方法。“部落”，“公会”，“小队”，“章节”，“团队”，“自主”和“精益”。轴。答案是首先，这是一个难题。其次，不要让任何人告诉您与众不同。
自主是新的筒仓
让团队成为“自主”是一个受欢迎的组织概念，并且经常与“自我指导”一词配对。拥有一个自主团队的目的是最大程度地减少外部依赖性和潜在的进步阻滞剂，这是一个令人钦佩的目标。“自治团队”的定义意味着，在团队的优先事项之外花费的每一分钟都浪费了一分钟。否则，这将不是一个自主团队。因此，具有严格定义的利益相关者和用例，一个自治团队倾向于垂直定向。该结构还有另一个术语：筒仓。自主团队的爱好者可能不喜欢这种比较，但这是事实 - 这并不是本质上的坏事，因为每个团队都在指导一个已确定和有记录的目标。
但是，单个组织内多个完全自治团队的逻辑极端并不漂亮，但由于让每个团队选择自己的云提供商，开发语言，源代码框架，构建框架，存储框架，处理调度框架，监视的后果框架，安全方法和治理等，最重要的是去除任何内部依赖项（阅读：可能重新解决另一个团队已经解决的问题），可能导致一个高度分散的环境，不一致地处理核心问题。每个团队都会在一个感觉中被“启用” - 因此，这是一种福利 - 但是具有高潜在的投资组合凝聚力。更务实的效率和理智方法将争论水平组件的一些共性和技术一致性。但是足够平常是足够的吗？筒仓多少钱？
回顾矩阵和康威
这些问题都应该听起来都很熟悉，因为作为一个行业，我们以前曾经来过这里。实际上，很多次。矩阵管理始于1950年代，并在1970年代真正起飞（数字设备公司显然是支持者）。Matrix Management应该通过创建一个有多个报告的组织形式来分解孤岛，并改善团队间的沟通和协作。再次，令人钦佩的目标。管理层本质上是一个人对另一个人说：“我需要您完成此任务。”问题在于，矩阵管理是另一个要求您做其他事情的人。希望其他任务与主要责任保持一致，但这不能保证。最坏的情况不仅是资源和时机错位，而且在被分配的次要任务中与主要任务相抵触。谁解决了这一冲突？很容易将“另一个经理”作为答案，但是在矩阵管理中，这可能不是那么简单，因为复杂的主题可能需要几层讨论和升级来解决一个棘手的主题。
组织结构和治理对于确定集体优先级显然很重要，但是其对产生的软件可交付成果的影响可能会进一步发展。康威的法律是1960年代的格言，该序言指出，组织设计系统的组织系统反映了自己的沟通结构。最初，这似乎是一种警告或警告，但是这种镜像发生的实际原因有很多。一般而言，同一团队中的人会汇聚在上述主题的相同答案中，例如开发语言，源代码框架，存储框架等，因为它是必要的和与同事进行项目的项目。康威定律正在描述一种优化策略，并且在该术语变得时尚前数十年，全部或半自主团队的影响。对于任何给定的团队的观点，自然的重点必然是优先考虑垂直（团队内部）以胜于水平（团队间的）相互作用。
垂直第一，然后水平
因此，两极是垂直优化（团队和功能用例导向）和水平优化（全球和瞄准团队间一致性）。前者可以为组织的凝聚力提供任何单一团队的益处。后者旨在为一个组织的100％一致性，以可能的灵活性和响应性的可能性。与生活中的许多事情一样，甜点可能在中间的某个地方，逐个易权衡，这需要功能和技术领导。即使魔法词，即使是“小队”，“部落”和“网格”，也不容易。
至少来自我的个人经验，首先优先考虑垂直，然后寻找横向机会，为制定组织组合中的解决方案的最务实的方法。虽然这是一篇关于软件开发的文章，但物理产品往往会使这一点更加平原：了解垂直是了解“车辆”的普遍需要与“车辆”的差异之间的差异。需要对轿车，卡车的特定需要的需要坦克。每个都有一个目的，但它们不是相同的，并且支持一个特征通常意味着不能支持别的东西，或者至少不是很好。它很难为其中一个案例设计，较小的效率低下的组合或不恰当的变体，例如18轮轿车或轿车箱杂种。
警示现实生活物理物体用于水平优化的用例是F-35联合罢工战斗机。旨在更换至少四个不同的平面（F-16，A-10，F-18和Harrier）其要求包括垂直起飞和着陆，以及超音速飞行，也没有其他要求的不足。大多数估计，这花了几十年的发展，至少花费了万亿美元。虽然F-35无疑是先进的，但大多数软件项目都没有这种跑道在横幅的内部技术一致性下的产品开发的时间和金钱方面。有一些小讽刺意味着F-35用三种变体提供了三种变体（其中只有一个使用的垂直起飞），我会猜测大多数软件工程师在最初描述的特征的情况下经历了概念上类似的情况。每个人都需要“伤口起来是一个昂贵的特殊情况。
最后，水平函数确实重要，但应由多个垂直用例验证。在没有用户的情况下构建横向服务没有任何意义。虽然大多数横向服务可能会出现“内部”，但它们仍然有效地拥有自己的权利，并应该相应地人员，并需要自己的发展路线图，发布和支持功能。
Doug Meil.是Ontada的投资组合建筑师。他也创立了克利夫兰大数据举杯2010年。多格的ACM文章可以找到https://www.linkedin.com/pulse/publications-doug-meil
找不到条目