技术步伐的力量

Hivemind Technologies的首席执行官解释了加快软件开发以实现转换的重要步骤。 作者：Thomas Delaet 你经常有这些大型的公共部门项目需要几年才能完成，当软件最终发布给用户时，问题就开始出现了。这种方法的问题是你浪费了很多时间来预测问题和规划你从未验证过的功能。 尽管古老的格言在乌龟和野兔中，当涉及到数字化转型时，缓慢而稳定并不能赢得比赛，据柏林软件工程业务Hivemind Technologies的首席执行官ErikSchmiegelow称。Hivemind的方法侧重于通过小型增量版本来快速交付软件，以验证假设和过程。在期间 Schmiegelow与麦肯锡合伙人Thomas Delaet进行了讨论，解释了Hivemind将速度作为降低风险的转型的关键标准的方法， 把安全放在一开始 托马斯·德拉特：我想，由于对风险增加的担忧，有些公司并不相信这种速度论点。第二个反对意见涉及在一个更广泛的生态系统中整合连续软件流的许多方面固有的问题。因此，从风险和整合的角度来看，您如何提出速度论点？ 和公共云的缺点，以及生成AI (gen AI)对开发人员的影响生产力。接下来是该对话中编辑的亮点。 通过速度交付价值 Erik Schmiegelow:让我从安全论点开始，因为这是一个重要的论点，尤其是在受监管的行业中。传统的安全方法本质上是 托马斯·德拉特：为什么你认为速度是转换的主要价值驱动因素？ 通过渗透测试、安全评估、代码审查等对系统进行大规模的一次性审计。这通常在版本很少的单片遗留系统中效果很好。 Erik Schmiegelow:速度至关重要，尤其是当您在非常复杂的环境中运行时。另一方面，如果您正在查看一个绿地项目，则非常简单。您有一个干净的石板，基本上可以设计您的系统，而不会受到其他部门或系统的风险或干扰。 然而，这已经不是我们生活的世界了。通常— —尤其是在受管制的环境中— —系统景观是不同组件的组合，这些组件协同工作，这意味着传统的单点链的末端审计流程并不能涵盖所有潜在的问题。 这不是现代IT的样子。你很少有绿地项目，在大多数情况下，需要收集尽可能多的反馈。你需要尽快暴露集成断点和问题，因为这本身就可以让你计划和适应变化，这反过来也是速度至关重要的原因。 您需要将安全考虑因素和安全方面集成到我们称为SecDevOps（安全，开发，运营）的快速交付过程中。我们特别将“Sec ”放在“ DevOps ”的前面，因为这通过设计加强了安全性的重要性。这是快速交付过程中不可或缺的一部分，其中交付的每个步骤都有自己的安全检查、安全审计和设计考虑因素。 通过向用户建立一个连续的小的增量发布流，您可以验证每个假设。您可以暴露问题并立即处理它们，而不是尝试为无法验证的事情尽可能提前计划。这就是为什么速度是 derisk软件交付项目的一个非常关键的工具。 我们在很大程度上依赖于持续的测试和自动化，以确保安全性与DevOps紧密耦合，因为可能的漏洞数量大大超过了单个传统审计可能涵盖的范围。 除了组织矩阵之外，没有人为任何人服务的方法。 当决策与它们的影响脱节时，会出现另一个典型的问题。假设一个单元决定一个堆栈或一个特定的过程，但它们最终不是必须实现它的那个。 即使公司选择在交付结束时进行最终审核，这种方法也可以大大提高应用程序的安全性，并降低攻击角度和延迟或交付停止的风险。作为安全专业人员，通过采用SecDevOps模型，您还可以更好地了解应用程序及其工作原理。 没有人可以质疑这个决定的有效性，因为它是完全分离的，每个人都是一台大机器上的齿轮，没有人看到大局。 SecDevOps具有竞争优势。借助自动化和测试，团队不仅可以更快地识别漏洞，而且还可以更快地交付修复程序。 快速交付团队是自组织的，可以控制从产品规格和所有权到交付的整个价值链，可以提供帮助。他们可以决定如何运行和部署事物，同时从用户那里获得最大的反馈和市场。减少干扰也有效地防止与组织内的其他单位，因为组织倾向于将事情强加给团队，而不必验证工作流的影响。 克服组织问题以实现更好的软件交付 托马斯·德拉特：如果你看看棕地的情况，什么样的问题通常会使软件交付效率低下？ 根据我们的经验，所有这些问题的根源通常是一个具有不适合目的的特定结构的组织，通常是因为它背后有历史性的发展-特别是对于已经存在了相当长的现有公司它们是在数字时代之前设计的。 Erik Schmiegelow:团队与产品开发之间以及团队与环境之间通常存在脱节孤立的开发过程提出了一个重大问题。 这导致了这样的情况，即产品所有者将某些东西扔到篱笆上给开发人员，他们做了他们的事情，然后将其交给质量保证，他们试图理解它，可能会或可能不会抓住某些东西，然后将其交给操作员，将其投入生产。除了将东西扔在篱笆上之外，没有任何交流没有反馈。所以没有人知道发生了什么，直到它真正进入市场，客户开始使用它，这是一个真正的问题。没有必要将这些孤立 基于纸张的过程是一个完美的例子。为什么数字化转型计划如此艰难？因为，本质上，业务流程仍然被设计得好像一切都还在纸上一样。尤其是当您与政府机构互动时，数字化方法基本上是将纸质表格转换为可以通过电子邮件发送的PDF，这绝对是荒谬的，因为它既不考虑操作环境，也不考虑影响。在用户上。 公共云的利弊 不断发展的AI用例 托马斯·德拉特：围绕开发人员生产力开发的新一代AI用例如何帮助我们讨论过的一切？你在哪里看到了最大的收益？ 托马斯·德拉特：如果你考虑改变软件交付的方式，公有云会扮演什么角色？ Erik Schmiegelow:评估是在本地还是在公共云上运行的组织需要全面了解运行基础架构的成本方面。即使您使用OpeShift和Kberetes之类的东西来简化资源利用率以降低成本，您也可以在系统操作员上花费基础设施和硬件。使用纯本地方案，您可以节省公共云操作时间，但最终可能会在硬件上花费更多。 Erik Schmiegelow:General AI当前最好的应用是辅助编码，因为它通过减少所有无聊的东西来提高生产率。如果你看看开发人员的原型日，30%是真正的编码，70%是调试，前30%的一半是做烦人、重复和样板的事情。生成型AI通过大量减少该位，显着提高了开发人员的生产力并通过减少研究时间来提供更多的确定性。很快，通用LLM [大型语言模型]将能够支持用于生产性使用的对话式编码会话，开发人员描述他们的需求，并让模型为应用程序创建大部分结构代码，以及测试自动化。目前，它还没有完全实现。即便如此，这还是相对较低的收获，但它仍然显著改善了团队的经验和生产力。 通过应用程序迁移实现的节省也并不总是显而易见的。例如，在“升降切换”方法中，使用公共云的好处微乎其微。您可以在数据库等事情上节省资金，因为您基本上可以迁移到托管数据库，从而减少操作开销并内置备份，但除此之外，成本优势有限。 这就是为什么云迁移项目应该始终是关于补救遗留应用程序以从云原生服务中受益，或者将遗留应用程序与新实现集成，从而利用公有云的弹性和自动扩展功能。这需要对 General AI更有趣的用例在于，您可以将企业数据存储库与查询用例结合使用一种称为检索增强生成（RAG）的技术。通过将用于自然语言理解的LLM与用于检索的矢量化数据存储库相结合，可以解决模型中的幻觉问题以及数据集训练问题。在此这样，模型可以更准确，因为它专注于正确的数据并解决隐私问题。RAG的用例很丰富。以保险业为例。它有大量的非结构化文档，尤其是保单文档。其中很多都是数字化的，但起源于纸面。进行反向分析或 负责云原生应用程序开发的团队也需要快速交付方法和应用程序设计的转变。 否则，即使您迁移和重写新应用程序，您也将使用习惯了传统环境方法的团队，他们最终将使用与以前相同的体系结构构建新应用程序。这将否定执行速度方面的任何好处以及您将使用云原生环境获得的灵活性。 重新处理政策，而不需要让很多人看着PDF或纸片，重新输入纸上的内容。 传统上，机器在评估和总结文本方面非常糟糕，这完全随着LLM而改变。 生成AI可以通过从非结构化文档中提取必要的属性并渲染它们来大规模改进该过程 在这种情况下，您可以通过保留工作流，但使用模型增加吞吐量来利用LLM的功能 以所需的形式。这可以将非常有价值的信息从旧的，非结构化的政策文档转换为结构化文档，并使其与新文档一样可访问。否则，这是一个过程，需要大量的人工交互，成本很高。 在企业数据集上进行预培训以提出建议,而不是依靠数据录入员来处理这些建议,从而减少了审查模型提出建议的范围。当模型经过充分训练和监督以进行全自动数据处理时，您最终可以完全绕过手动步骤。这两者都是生成AI企业应用的真正甜蜜点。潜在用例的列表非常广泛，最重要的是数据提取、汇总和匹配是业务流程的重要部分。 生成AI可以产生巨大影响的第二个领域是涉及“模糊”匹配的所有内容。如果我们查看当前的业务流程，则有很多工作流 通过需要的人工交互来中断机器到机器的流程，以验证、检查或执行其他数据输入 Erik Schmiegelow是Hivemind Technologies的首席执行官.托马斯·德拉特是麦肯锡布鲁塞尔办事处的合伙人. 受访者表达的评论和意见是他们自己的，不代表或反映麦肯锡公司的意见、政策或立场，也不得到麦肯锡公司的认可。