技术雷达

我们讨论了这一版本的雷达的几个主题（其中一些最终未能使最终削减）采用工具来适应Kafka的工具。其中一些工具允许更多传统的界面到Kafka（例如ksqldb.那Confluent Kafka Rest Proxy和Nakadi），而其他人则旨在提供额外的服务，如GUI前端和管弦乐流程加入。我们怀疑这部分归还工具的潜在原因是kafka部分的潜在尖锐的尖锐复杂性，与需要将其弯曲到现有架构和流程的组织的增加。有些团队最终会治疗Kafka作为下一代企业服务巴士- 一个例子便利的滑坡但是其他团队使用Kafka来提供对发生的业务事件的通用访问。这些组织认识到，拥有一个集中的基础设施，在边缘进行调整，并通过仔细的设计和治理避免蔓延，有时会更容易一些。无论如何，它表明Kafka继续作为异步发布/订阅消息量的事实上的标准。

作为雷达的反典是球队在方便但不正确的Nexus积分中将行为放置行为的趋势，这导致了长期的技术债务和更糟糕的问题。示例比比，包括使用数据库作为集成点，使用Kafka.作为一个全球调节器，杂交逻辑与基础架构代码相交，依此类推。现代软件开发为开发人员提供了许多地方，以填补行为，缺乏经验或不认识的团队通常不会仔细考虑不恰当的耦合的长期后果令人担忧。不适当的团队结构和其他偏差康威的法律也没有帮助。随着软件系统变得更加复杂，开发团队必须履行创造和维护周到的架构和设计，而不是单击划线的决策，以获得权宜之计。通常，考虑特定方法的可测试性引导团队远离这些潜在的问题决策。当留给其自己的设备时，软件趋于复杂性。仔细设计，也许更重要的是，持续的治理工作，以确保调度压力或其他许多破坏力的一部分不会导致团队做出方便但不当的决策。

许多建筑师引用了康威的法律在本版本中，我们通过几个被提名的亮点发现，一个组织的团队结构在处理好的时候仍然是一个关键的促成因素，在处理不好的时候仍然是一个严重的障碍。我们讨论的例子包括需要围绕平台团队进行产品思考，而不是将他们视为订单承接者;团队拓扑和越来越识别团队认知负荷关于有效性;并围绕程序员生产力开发的新框架空间．组织在工具上花费了大量的资金，但是许多组织通过关注构建软件的人员以及在特定组织中是什么使它们有效，发现了更好的生产力收益。

在软件领域，许多人推崇复杂问题的聪明解决方案，但这些聪明的解决方案往往是由自己造成的偶然的复杂性造成的。今天存在这种现象的许多例子，包括不幸的人分泌编排或协调代码的不幸但是常见的做法。例如，我们看到巧妙的工作流管理工具，如空气流动或长官通过编排，可以过度使用来管理复杂的数据管道。我们找到了一系列围绕Monorepos引起的问题的工具，例如Nx还有很多。团队往往没有意识到他们对不必要的复杂性倍增或三倍，而无需踩到看大局，并质疑当前的解决方案是否比问题更糟糕。而不是跳到更多的技术来解决问题，团队应该做根本原因分析，解决潜在的基本复杂性和课程正确。数据网格是一种解决方法的方法，解决了导致过度复杂的数据管道和工具的基础组织和技术假设。

我们发现这一版本的平台相关措施的数量严重下降，我们归因于一些行业标准的巩固增加：大多数公司已经选择了他们的云供应商，他们大多标准化了Kubernetes适用于容器编排和Kafka.用于高性能消息传递。这是否意味着平台不再重要？或者我们经历了相当于交替的扩张和收缩的商业周期 - 例如，我们看到了类似的快速创新时期，然后是数据库技术中的斯塔西斯（斯蒂芬杰伊叫“标点均衡”）。也许该行业已进入相对平静的时期随着组织吸收到云层的构造转变并等待下一波破坏性创新。