雷达技术

我们在这个版本的雷达中讨论了几个主题(其中一些最终未能通过最终剪辑)，团队正在使用工具来适应/从卡夫卡. 其中一些工具允许对卡夫卡进行更传统的接口(如 ksqlDB, 融合卡夫卡 REST代理, 和Nakadi), 而其他的则被设计用来提供额外的服务，比如GUI前端和编排插件. 我们怀疑，这些工具的部分潜在原因是卡夫卡的一些部分的潜在的锋利的复杂性，以及组织中需要将其弯曲到现有的架构和流程的增加的存在. 一些团队最终进行了治疗 卡夫卡作为下一代企业服务总线 -其中一个例子 便利的滑坡 主题——但是其他团队使用卡夫卡来提供业务事件发生时的通用访问. 这些组织认识到，有时更容易拥有边缘具有适应性的集中式基础设施，并通过仔细的设计和管理来避免蔓延. 在任何情况下, 这表明卡夫卡继续成为异步发布/订阅消息的事实上的标准.

与雷达一样古老的一个反模式是，团队倾向于将行为置于其生态系统中方便但不恰当的连接点，从而导致长期的技术债务，甚至更糟. 示例有很多，包括使用数据库作为集成点、使用 卡夫卡 作为一个全局协调器，将业务逻辑与基础设施代码等混合在一起. 现代软件开发为开发人员提供了许多地方来隐藏行为, 缺乏经验或考虑不周的团队经常因为没有仔细考虑不适当耦合的长期后果而使问题纠缠不清. 不适当的团队结构和其他偏离 康威定律 也不帮助. 随着软件系统变得越来越复杂, 开发团队必须勤奋地创建和维护周到的架构和设计, 不要为了权宜之计而草率决定. 经常, 考虑特定方法的可测试性可以使团队远离这些潜在的问题决策. 如果让软件自己操作，它会变得越来越复杂. 精心设计和, 或许更重要的是, 持续的治理工作确保进度压力或其他众多破坏性力量之一不会导致团队做出方便但不恰当的决定.

许多建筑师引用 康威定律, 20世纪60年代，人们观察到团队的沟通结构会影响设计, 对团队组织进行变更, 我们发现，如果处理得好，一个组织的团队结构仍然是一个关键的推动者，如果处理得不好，则是一个严重的障碍. 我们讨论的例子包括，需要围绕平台团队来思考产品，而不是将他们视为订单接受者; 团队拓扑 并且越来越多的人认识到 团队的认知负荷 in relation to effectiveness; and the new framework developed around programmer productivity called 空间. 组织在工具上花费了大量资金, 然而，许多人发现，通过关注构建软件的人员，以及在特定组织中是什么使他们有效，可以获得更好的生产力.

软件界的许多人都喜欢用聪明的方法来解决复杂的问题, 然而，这些聪明的解决方案往往来自于自我施加的偶然复杂性. 这一现象在今天仍然存在着大量的例子, 包括将编排或协调代码隐藏在不合适的位置这一不幸但常见的做法. 例如，我们看到聪明的工作流管理工具，如 气流 or 完善 它们被过度地用于通过编排来管理复杂的数据管道. 我们发现有很多工具可以解决由单一产品引起的问题，比如 Nx 和许多更多. 团队通常没有意识到，他们在不必要的复杂性上增加了一倍或三倍，而没有回过头来看看大局，并质疑当前的解决方案是否比问题本身更糟糕. 而不是跳到更多的技术来解决问题, 团队应该进行根本原因分析, 解决潜在的本质复杂性和正确的路线. 数据网格 这是解决导致过于复杂的数据管道和工具的底层组织和技术假设的方法的一个例子吗.

在这个版本的雷达中，我们发现与平台相关的信号出现了严重的下降, 我们将其归因于一些行业标准的整合:大多数公司已经选择了他们的云供应商, 他们基本上标准化了 Kubernetes 用于容器业务流程和 卡夫卡 为高性能的消息传递. 这是否意味着平台不再重要? 或者我们正在经历一个类似于扩张和收缩交替周期的商业周期——在数据库技术中，我们已经看到了类似的快速创新和停滞(Stephen Jay Gould称之为“间断均衡”)的时期, 例如. 也许这个行业已经进入了一个相对平静的时期，因为组织吸收了向云的构造转移，并等待下一波颠覆性创新.