管理建筑技术债务

当我想到技术债务时，我仍然记得我创建的第一个应用程序，它让我意识到架构不合适所带来的后果。它发生在 20 世纪 90 年代末，当时我刚刚开始从事顾问工作。

客户要求使用Lotus Notes平台为其客户构建采购系统。使用 Lotus Notes 客户端和自定义应用程序，最终用户可以发出请求，应用程序会跟踪这些请求，并由产品所有者团队执行。从理论上讲，这是一个很酷的想法——尤其是因为 Web 开发的应用程序并不流行，而且每个人都每天都在使用 Lotus Notes。

核心问题是数据在设计上非常具有关系性——而 Lotus Notes 不是关系数据库。该解决方案的设计要求在每个 Lotus Notes 文档中进行架构管理，并依靠一系列多值字段来模拟数据属性之间的关系。这真是一团糟。

如果推荐了更好的平台，Lotus Notes 应用程序中就不需要大量的逻辑了。源代码支持起来很复杂。数据结构的增强导致底层代码的重大重构——更不用说运行基于服务器的作业来转换现有数据了。不要让我开始谈论报告创建背后的努力。

从我职业生涯的早期开始，我就专注于提供客户想要的解决方案，而不是试图提供更好的解决方案。这当然是我职业生涯早期学到的一个教训，但在那个项目之后的几年里，我逐渐意识到架构技术债务的后果是我们所有人都面临的不幸现实。

让我们从宏观层面进一步探讨架构技术债务的概念。

建筑技术债务（ATD）

卡内基梅隆大学的建筑技术债务 (ATD) 图书馆对 ATD 给出了如下定义：

架构技术债务是一种短期内权宜的设计或构建方法，但它会创建一种技术环境，其中相同的工作需要架构返工，并且以后的成本比现在更高（包括随着时间的推移而增加的成本）。

在《快速解答：如何管理架构技术债务》（发布于 2023 年 9 月 22 日）中，Gartner Group 对 ATD 的定义如下：

架构技术债务是由于架构漂移、次优架构决策、违反定义的目标产品架构和既定的行业架构最佳实践以及为了更快地交付软件而做出的架构权衡而导致的技术债务。

在这两种情况下，往往带来短期欢庆的好处可能会带来长期挑战。这与我在介绍中提到的 Lotus Notes 示例类似。

进一步复杂化的是，与软件开发的其他方面相比，用于帮助识别和管理软件架构技术债务的工具一直缺失：

对于代码质量、可观察性和 SCA，Sonarqube、Datadog、New Relic、GitHub 和 Snyk 等产品都提供了经过验证的工具。然而，软件架构领域却落后了，没有任何经过验证的解决方案。

这是令人遗憾的，因为卡内基梅隆大学发布的 2015 年“ 衡量它？管理它？忽略它？软件从业者和技术债务”研究报告指出，ATD 一直是最大的（也是最具破坏性的）技术债务类型。

下图总结了该报告中的图 4，结论是错误的架构选择是技术债务来源的明显主导。

如果不加以管理，ATD 将会随着时间的推移继续以越来越快的速度增长，如下图所示：

如果不采取缓解措施，架构债务最终将达到所衡量的底层解决方案的临界点。

管理 ATD

在我们管理 ATD 之前，我们必须首先了解问题所在。德斯蒙德·图图曾经明智地说过：“吃大象只有一种方法：一次咬一口。”

左移方法包含将给定方面移至生命周期的开始而非结束处的概念。此概念因测试左移而广受欢迎，其中测试阶段被移至开发过程的一部分，而不是在开发完成后要完成的单独事件。

在管理 ATD 时，左移可以通过两种不同的方式实现：

• 左移以实现弹性——识别对弹性有影响的来源，然后在它们影响性能之前修复它们。
• 安全左移——在开发生命周期中检测并缓解安全问题。

就像测试左移一样，在开发阶段优先关注弹性和安全性将减少发生意外事件的可能性。

建筑可观察性

架构可观察性使工程团队能够在宏观层面逐步解决其服务中的架构漂移问题。事实上，《华尔街日报》今年早些时候在《看不见的 1.52 万亿美元问题：笨重的旧软件》 一文中报道，修复技术债务的成本高达 1.52 万亿美元。

为了取得成功，工程领导必须与以下组织目标完全一致：

• 弹性——从意外事件中迅速恢复。
• 可扩展性——根据客户需求适当扩展。
• 速度——根据产品预期提供功能和增强功能。
• 云适用性——将传统解决方案转变为高效的云原生服务产品。

我最近发现了vFunction的 AI 驱动的架构可观察性平台，该平台专注于以下交付成果：

• 通过静态和动态分析发现解决方案的真实架构。
• 通过实时查看服务的发展情况来防止架构漂移。
• 通过消除应用程序域及其相关资源之间不必要的依赖关系和改进来提高应用程序的弹性。
• 通过人工智能驱动的可观察性来管理和补救技术债务。

此外，vFunction 平台还提供了从单体应用到云原生解决方案的迁移路径。一旦团队实现了平台的现代化，他们就可以持续观察平台是否发生了持续的漂移。如果公司已经拥有微服务，他们可以使用 vFunction 来检测分布式应用程序中的复杂性，并解决影响弹性和可扩展性的依赖关系。无论哪种情况，一旦实施，工程团队都可以在达到临界点之前很好地缓解 ATD。

在上图中，由于实施了 vFunction 平台和底层左移方法，工程团队能够在每次发布时减轻技术债务。

结论

我的读者可能还记得，我一直专注于以下使命宣言，我觉得它适用于任何 IT 专业人士：

“将时间集中在提供能够扩展知识产权价值的功能上。其他一切都可以利用框架、产品和服务。” - J. Vester

vFunction 平台遵循我的使命宣言，帮助工程团队在宏观层面上采用左移方法来实现其服务的弹性和安全性。这是一个重要的区别，因为如果没有这样的工具，团队可能会在微观层面上缓解问题，解决从组织角度来看并不重要的技术债务。

当我回想起那个让我意识到技术债务挑战的应用程序时，我不禁想到，该解决方案带来的问题比它引入的每个功能带来的好处还要多。当然，仅仅使用左移来实现弹性就已经有助于在考虑替代方案的成本可行的情况下暴露出底层架构的问题。

如果您有兴趣了解有关 vFunction 解决方案的更多信息，可以在此处阅读更多相关信息。

祝您度过愉快的一天！