技術的負債について考えるとき、不適切なアーキテクチャがもたらす結果を思い知らされた最初のアプリケーションを今でも思い出します。それは、私がコンサルタントとして初めて仕事を始めた 1990 年代後半のことでした。 クライアントは、顧客向けの調達システムを構築するために、  プラットフォームの使用を要求していました。Lotus Notes クライアントとカスタム アプリケーションを使用すると、エンド ユーザーは、アプリケーションによって追跡され、製品所有者のチームによって実行されるリクエストを行うことができます。理論的には、これは非常に優れたアイデアでした。特に、Web で開発されたアプリケーションが普及しておらず、誰もが日常的に Lotus Notes を使用していたためです。 Lotus Notes 根本的な問題は、データの設計が非常にリレーショナルであったことです。Lotus Notes はリレーショナル データベースではありませんでした。ソリューションの設計では、すべての Lotus Notes ドキュメント内でスキーマ管理が必要であり、データ属性間の関係をシミュレートするために一連の複数値フィールドに依存していました。これは混乱を招きました。 より優れたプラットフォームが推奨されていたら、Lotus Notes アプリケーションに大量のロジックは必要なかったでしょう。ソース コードのサポートは複雑でした。データ構造の強化により、基盤となるコードが大幅にリファクタリングされました。既存のデータを変換するためにサーバー ベースのジョブを実行する必要があったことは言うまでもありません。レポート作成の背後にある努力については、ここで触れるつもりはありません。 私はキャリアの初期の頃から、より良いソリューションを提供するよりも、クライアントが望むソリューションを提供することに重点を置いてきました。これは確かにキャリアの早い段階で学んだ教訓ですが、そのプロジェクトから数年経って、アーキテクチャ上の技術的負債の結果は私たち全員が直面する残念な現実であることに気づきました。 アーキテクチャ技術負債の概念をマクロレベルでもう少し詳しく見てみましょう。 アーキテクチャ技術負債 (ATD) カーネギーメロン大学の Architectural Technical Debt (ATD) ライブラリでは、ATD について次のような を提供しています。 定義 アーキテクチャ上の技術的負債とは、短期的には適切な設計または構築アプローチですが、同じ作業にアーキテクチャ上のやり直しが必要となり、後で実行すると現在実行するよりもコストがかかる (時間の経過に伴うコストの増加を含む) という技術的な状況を生み出します。 ガートナー グループは、「クイック アンサー: アーキテクチャの技術的負債を管理する方法」(2023 年 9 月 22 日発行) で、ATD を次のように定義しています。 アーキテクチャの技術的負債とは、アーキテクチャの逸脱、最適ではないアーキテクチャの決定、定義されたターゲット製品アーキテクチャおよび確立された業界のアーキテクチャのベスト プラクティスの違反、およびソフトウェア配信を高速化するためのアーキテクチャのトレードオフによって発生するタイプの技術的負債です。 どちらの場合も、短期的には喜ばしい結果をもたらすことが多いメリットが、長期的には課題に直面する可能性があります。これは、冒頭で述べた Lotus Notes の例に似ています。 さらに問題を複雑にしているのは、ソフトウェア開発の他の側面と比較して、ソフトウェア アーキテクチャの技術的負債を特定して管理するのに役立つツールが欠けていることです。 コード品質、可観測性、SCA に関しては、Sonarqube、Datadog、New Relic、GitHub、Snyk などの製品で実証済みのツールが存在します。ただし、ソフトウェア アーキテクチャ セグメントは実証済みのソリューションがなく、遅れをとっています。 カーネギーメロン大学が 2015 年に発表した調査「  」で明らかになったように、ATD は常に最大かつ最も損害が大きいタイプの技術的負債であることを考えると、これは残念なことです。 計測しますか? 管理しますか? 無視しますか? ソフトウェア実務者と技術的負債 次の図は、そのレポートの図 4 を要約したもので、不適切なアーキテクチャの選択が技術的負債の原因として明らかに最大であったと結論付けています。  管理されない場合、ATD は時間の経過とともに増加率で成長し続ける可能性があります。これは次の簡単な図で示されています。  軽減策を講じなければ、アーキテクチャ負債は最終的に、測定対象となる基礎ソリューションの限界点に達します。  ATDの管理 ATD を管理する前に、まず問題を理解しなければなりません。 かつて賢明にもこう言いました。「象を食べる方法は 1 つだけ。一度に一口ずつ食べることだ。」 デズモンド・ツツは シフト レフト アプローチは、特定の側面をライフサイクルの終わりではなく、開始近くに移動するという概念を取り入れています。この概念は、テストのシフト レフトで人気を博しました。テスト フェーズは、開発が完了した後に完了する別のイベントではなく、開発プロセスの一部に移動されました。 シフトレフトは、ATD の管理において 2 つの異なる方法で実装できます。 回復力のためにシフトレフト — 回復力に影響を与える原因を特定し、パフォーマンスに現れる前に修正します。 セキュリティのシフトレフト - 開発ライフサイクル中にセキュリティの問題を検出し、軽減します。 テストのシフトレフトと同様に、開発フェーズで回復力とセキュリティに優先的に重点を置くことで、予期しないインシデントが発生する可能性が軽減されます。 アーキテクチャの可観測性 アーキテクチャの可観測性により、エンジニアリング チームはサービス内のアーキテクチャの変動をマクロ レベルで段階的に解決できるようになります。実際、ウォール ストリート ジャーナルは今年初め、「目に見えない 1.52 兆ドルの問題: 使いにくい古いソフトウェア」  で、技術的負債の修正コストが 1.52 兆ドルに上ると報じました。 という記事 成功するには、エンジニアリング リーダーシップが次の組織目標と完全に一致している必要があります。 回復力 — 予期しないインシデントから迅速に回復すること。 スケーラビリティ - 顧客の需要に応じて適切に拡張します。 速度 - 製品の期待に沿った機能と拡張機能を提供します。 クラウド適合性 - 従来のソリューションを効率的なクラウドネイティブ サービス オファリングに変換します。 私は最近、  の AI 駆動型アーキテクチャ可観測性プラットフォームを発見しました。このプラットフォームは、次の成果物に重点を置いています。 vFunction 静的および動的分析を通じてソリューションの実際のアーキテクチャ 。 を発見します サービスの進化をリアルタイムで確認することで、アーキテクチャのドリフトを 。 防止します 不要な依存関係を排除し、アプリケーション ドメインと関連リソース間の改善を行うことで、アプリケーションの を高めます。 回復力  AI 主導の可観測性により技術的負債を管理および 。 修正します さらに、vFunction プラットフォームには、モノリスからクラウドネイティブ ソリューションへの変換パスを提供するという副次的なメリットもあります。チームがプラットフォームを最新化したら、継続的なドリフトを継続的に監視できます。企業がすでにマイクロサービスを導入している場合は、vFunction を使用して分散アプリケーションの複雑さを検出し、回復力とスケーラビリティに影響を与える依存関係に対処できます。いずれの場合も、実装後は、エンジニアリング チームは限界点に達する前に ATD を軽減できます。 上の図では、vFunction プラットフォームの実装と基盤となるシフトレフト アプローチにより、エンジニアリング チームは各リリースの一部として技術的負債を軽減できます。 結論 読者の皆様は、私が次のようなミッション ステートメントに重点を置いてきたことを覚えていらっしゃるかもしれません。これは、あらゆる IT プロフェッショナルに当てはまると思います。  「知的財産の価値を高める機能や特性を提供することに時間を集中してください。他のすべてにはフレームワーク、製品、サービスを活用してください。」 - J. ベスター vFunction プラットフォームは、エンジニアリング チームがマクロ レベルでサービスの回復力とセキュリティにシフト レフト アプローチを採用できるようにすることで、私のミッション ステートメントに準拠しています。これは重要な違いです。なぜなら、このようなツールがなければ、チームはミクロ レベルで軽減し、組織の観点からはそれほど重要ではない技術的負債を解決する可能性が高いからです。 技術的負債の課題に気づかせてくれたあのアプリケーションを振り返ると、そのソリューションが、導入された各機能でメリットよりも多くの問題を生み出したことを考えずにはいられません。確かに、回復力のためだけにシフトレフトを使用した場合、代替案を検討するコストが実現可能な時点で、基礎となるアーキテクチャの問題を表面化させるのに役立ったでしょう。  vFunction ソリューションについて詳しく知りたい場合は、 詳細をお読みください。 こちらで 本当に素晴らしい一日をお過ごしください！

This story contains new, firsthand information uncovered by the writer.

2022 - HackerNoon Contributor of the Year - Cloud Computing

2022 - HackerNoon Contributor of the Year - Design

2022 - HackerNoon Contributor of the Year - Heroku

2022 - HackerNoon Contributor of the Year - Javascript

2022 - HackerNoon Contributor of the Year - Salesforce

2022 - Hackernoons Tech Storyteller of the Year

I ♥ writing code. Find me on GitLab.

Nominated for 2022 - HackerNoon Contributor of the Year - Javascript

Nominated for 2022 - Hackernoons Tech Storyteller of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Cloud Computing

Nominated for 2022 - HackerNoon Contributor of the Year - Heroku

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - HackerNoon Contributor of the Year - Salesforce

このオーディオは、ストーリーの元の言語で制作されています。

長すぎる; 読むには

アーキテクチャ技術負債の管理

アーキテクチャ技術負債の管理

About Author

コメント

ラベル

この記事は

Related Stories

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

暗号通貨の成長: 効果的なユーザーペルソナの作成

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

ワークフローを10倍に向上させる方法: 必須アプリ17選

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

暗号通貨の成長: 効果的なユーザーペルソナの作成

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

ワークフローを10倍に向上させる方法: 必須アプリ17選

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps