アーキテクチャの劣化現象？ データ分析基盤のアーキテクチャの場合は？
分析屋の下滝です。
とある論文を読んだのでざっくり紹介します。データ分析基盤のアーキテクチャの場合にどうなるのかが気になっています。
Understanding Architecture Erosion: The Practitioners’ Perceptive
アーキテクチャの劣化を理解する： 実務家の視点
概要は以下です。
ソフトウェアシステムの進化に伴い、そのアーキテクチャは、要件、環境、実装の変化に追従して適応することが意図されている。しかし、実際には、進化するシステムがアーキテクチャから逸脱することが多く、システムの保守や進化に深刻な影響を与える。このようなアーキテクチャの劣化現象は、研究において広く研究されているが、開発者の視点からの検討はまだ行われていない。この探索的研究では、開発者がアーキテクチャーの劣化という概念をどのように認識しているか、その原因と結果、また、アーキテクチャーの劣化を特定し制御するためのツールやプラクティスを調査するものである。この目的のために、我々は、アーキテクチャ劣化に関連する議論のデータを収集するために、いくつかの人気のあるオンライン開発者コミュニティを探した。さらに、これらの議論に参加している開発者を特定し、10人の参加者にアンケートを実施し、4人の参加者にインタビューを行った。その結果、以下のことが明らかになった： (1)開発者は、アーキテクチャーの劣化が構造的に現れるか、ランタイム品質、メンテナンス、進化に及ぼす影響に注目している。(2)技術的要因に加え、非技術的要因によってもアーキテクチャーの劣化は大きく引き起こされる。(3)アーキテクチャ劣化を検知するための専用ツールがないにもかかわらず、開発者は通常いくつかの症状によって劣化を識別する。（4）アーキテクチャーの劣化の影響を軽減するために有効な対策が存在する。
長いですね。短く見ていきましょう。
ソフトウェアシステムの進化に伴い、そのアーキテクチャは、要件、環境、実装の変化に追従して適応することが意図されている。しかし、実際には、進化するシステムがアーキテクチャから逸脱することが多く、システムの保守や進化に深刻な影響を与える。
これは、実務やソフトウェア工学ではよく知られていることの一つです。
このようなアーキテクチャの劣化現象は、研究において広く研究されているが、開発者の視点からの検討はまだ行われていない。この探索的研究では、開発者がアーキテクチャーの劣化という概念をどのように認識しているか、その原因と結果、また、アーキテクチャーの劣化を特定し制御するためのツールやプラクティスを調査するものである。
「アーキテクチャの劣化現象」というテーマです。アーキテクチャは、徐々に劣化（悪くなっていって）しまうよという話です。この論文は、開発者がそのような劣化現象をどう考えているのか、その調査です。
・開発者は、その概念をどのように認識しているか
・開発者は、その原因と結果は何だとしているか
・開発者は、アーキテクチャーの劣化を特定し制御するためのツールは何を使っているか
・開発者は、劣化現状に対抗するためのプラクティスには何があると考えているか
この目的のために、我々は、アーキテクチャ劣化に関連する議論のデータを収集するために、いくつかの人気のあるオンライン開発者コミュニティを探した。さらに、これらの議論に参加している開発者を特定し、10人の参加者にアンケートを実施し、4人の参加者にインタビューを行った。その結果、以下のことが明らかになった：
10人の開発者には、アンケートし、4人の開発者にはインタビューを行って調べたと。その結果は以下のことが明らかになったと。
(1)開発者は、アーキテクチャーの劣化が構造的に現れるか、ランタイム品質、メンテナンス、進化に及ぼす影響に注目している。(2)技術的要因に加え、非技術的要因によってもアーキテクチャーの劣化は大きく引き起こされる。(3)アーキテクチャ劣化を検知するための専用ツールがないにもかかわらず、開発者は通常いくつかの症状によって劣化を識別する。（4）アーキテクチャーの侵食の影響を軽減するために有効な対策が存在する。
分かりやすく一覧化するとこう。
(1) 開発者は、アーキテクチャーの劣化が構造的に現れるか、ランタイム品質、メンテナンス、進化に及ぼす影響に注目している。
(2) 技術的要因に加え、非技術的要因によってもアーキテクチャーの劣化は大きく引き起こされる。
(3) アーキテクチャ劣化を検知するための専用ツールがないにもかかわらず、開発者は通常いくつかの症状によって劣化を識別する。
(4) アーキテクチャーの劣化の影響を軽減するために有効な対策が存在する。
概要は以上です。
この研究では、業務アプリケーションアーキテクチャでの話ですが、データ分析基盤でのアーキテクチャではどうなるのかが気になってます。今回は、データ分析基盤でのアーキテクチャの話は議論しませんが、まずは、論文の中身をざっくりと結果の節の気になるところだけ確認してみましょう。
アーキテクチャの劣化
この研究では、開発者がアーキテクチャの劣化と呼ばれる概念をどのように認識しており、その原因と結果をどのように捉えているか、そして、アーキテクチャの劣化を特定し制御するためのツールやプラクティスを紹介したものになります。
開発者は、アーキテクチャの劣化を次の観点から捉えているようです。
・構造的な観点：劣化したアーキテクチャの構造は、意図したアーキテクチャから逸脱している。
・品質の観点：劣化したアーキテクチャは、当初または現在の非機能要件を満たさない可能性があるため、システムの品質属性が劣化する。
・保守の観点：劣化したアーキテクチャ は、理解、バグの修正、リファクタリングが難しくなる可能性がある。
・進化の観点：アーキテクチャが劣化していると、次にどの機能を実装するか、どの技術を採用するかなど、次の進化のステップを計画することが困難、あるいは不可能になる。
データ分析基盤のアーキテクチャでも同じような観点で見ることができるかもしれません。あるいは、特有の観点があるでしょうか？ また、データ分析基盤のアーキテクチャをどのような粒度や抽象度で捉えるのかを明確にする必要があるかも知れません。
次に、アーキテクチャの劣化は、次のような原因で発生すると開発者は捉えているようです。
【技術要因】
・不適切なアーキテクチャの変更
・アーキテクチャ設計の不具合
・技術的負債
・増加する複雑性
・アジャイル開発
【非技術要因】
・マネジメント能力の欠如
・アーキテクトとデベロッパーの断絶
・知識の蒸発
・コミュニケーション不足
・その他（環境変化、ビジネスプロセス変化、ビジネスプレッシャー、品質の考慮は第１優先ではないなど）
【両方の要因】
・要求の変更
・メンテナンス不足
データ分析基盤のアーキテクチャでも同じような原因がありそうです。あるいは特有の原因があるでしょうか？
アーキテクチャの劣化は、次のような結果を引き起こします。
・理解しにくく、維持しにくくなる
・ランタイム品質が低下する
・リファクタリングに膨大なコストがかかる
・大きな泥の玉（理解可能なアーキテクチャが欠けているソフトウェアシステム）になる
・開発スピードが低下する
・高い離職率
・全体的な複雑さ
データ分析基盤のアーキテクチャでも同じような結果になるでしょうか？ あるいは特有の結果があるでしょうか
続いて、アーキテクチャの劣化を特定するために開発者が使っているツールとプラクティスです。なお、これらのツールは劣化特定のために作られたツールというわけではありません。
まずはツール
・Lattix https://www.lattix.com
・NDepend https://www.ndepend.com
・Sonargraph http://www.hello2morrow.com/
products/sonargraph
・Structure101 https://structure101.com/products/workspace
・Architecture-Quality-Evolution https://github.com/tushartushar/ArchitectureQualityEvolution
・JDepend https://github.com/clarkware/jdepend
・Designite https://www.designite-tools.com/
・SonarQube https://www.sonarqube.org
・SonarLint https://www.sonarlint.org/
・Archie https://github.com/ArchieProject/Archie-Smart-IDE
・Glasnostic https://glasnostic.com/
・CodeScene https://codescene.io/
・CAST https://www.castsoftware.com/
続いてプラクティス。
・Dependency Structure Matrix (DSM) ：システムを正方形の行列の形で視覚的に表現するために使用することができる。DSMはパッケージ間の依存関係を可視化することができ、そのような依存関係を理解することで、メンテナンスフェーズでアーキテクチャの劣化を検出することができる。
・Software Composition Analysis (SCA)：システム内のオープンソースコンポーネントを可視化するプロセスを指す。オープンソースコンポーネントは、あらゆる業界のソフトウェア製品に使用されており、SCAは、一般的にアーキテクチャの劣化の原因となる潜在的な古くなったコンポーネントを特定するのに特に役立つ。
・アーキテクチャ適合性検査（ACC）：実装されたアーキテクチャと意図されたアーキテクチャの間の適合性の種類を指す。検出は、実装におけるアーキテクチャの違反を特定することで行われる。
・アーキテクチャモニタリング：アーキテクチャの問題を検出することによって、アーキテクチャの健全性を監視するためのツールを使用することを指す。
・コートレビュー：開発者やアーキテクトが、デザインパターン違反などのコードの誤りを特定するために行う、継続的かつ体系的なプロセスのこと。
・アーキテクチャの不吉な匂い密度の変化の確認：様々なバージョンのアーキテクチャーの不吉な匂いを静的に比較し、リリースタイムラインに沿ってアーキテクチャの劣化を検出する手法。
・アーキテクチャの可視化：アーキテクチャモデルやアーキテクチャデザインの決定を、様々な視覚的表記を用いて表現することを目的とする。プロジェクトにおけるアーキテクチャ要素（例：コンポーネント）間の構造、メトリクス、依存関係を可視化することで、アーキテクチャとその進化をより理解するのに役立ちます。可視化によってシステムのアーキテクチャ依存関係を理解することは、違反の拡散やさらなる劣化を検知するために重要となる。
開発者は、アーキテクチャの劣化に対して、次のようなアプローチで対応します。
１．アーキテクチャの評価：アーキテクチャ設計時、実装時、進化時のライフサイクルを通しての評価プロセスのことを指します。
２．定期的なメンテナンス：システムを綺麗に保ち、円滑に動作させることを目的とした定期的な活動（コードのリファクタリング、バグフィックス、テストなど）のことです。
３．アーキテクチャの簡素化：アーキテクチャの複雑さが制御不能なまでに増大した場合、アーキテクチャを簡素化し、システムのサイズと複雑さを意図的に制御すること。
４．アーキテクチャの再構築：単に複雑さを軽減しようとするアーキテクチャの簡略化とは異なり、アーキテクチャの大部分に関わるより広範な変更です。アーキテクチャの劣化を制御するための抜本的かつ効果的な手段となる。
５．組織の最適化：より優秀な人材を採用する。
大きくは、以下の3つと言えそうです。
１．アーキテクチャを評価する
２．コードを変更する
・定期的なメンテナンスにより変更する
・アーキテクチャの簡素化として変更する
・アーキテクチャの再構築として変更する
３．組織を最適化する
データ分析基盤のアーキテクチャでも同じようなアプローチとなりそうです。あるいは、特有のアプローチがあるでしょうか？
論文の紹介は以上です。次回は、今回のものをベースにしてデータ分析基盤でのアーキテクチャの観点で考えてみたいと思います。
株式会社分析屋について
ホームページはこちら。
noteでの会社紹介記事はこちら。
【データ分析で日本を豊かに】
分析屋はシステム分野・ライフサイエンス分野・マーケティング分野の知見を生かし、多種多様な分野の企業様のデータ分析のご支援をさせていただいております。 「あなたの問題解決をする」をモットーに、お客様の抱える課題にあわせた解析・分析手法を用いて、問題解決へのお手伝いをいたします！
【マーケティング】
マーケティング戦略上の目的に向けて、各種のデータ統合及び加工ならびにPDCAサイクル運用全般を支援や高度なデータ分析技術により複雑な課題解決に向けての分析サービスを提供いたします。
【システム】
アプリケーション開発やデータベース構築、WEBサイト構築、運用保守業務などお客様の問題やご要望に沿ってご支援いたします。
【ライフサイエンス】
機械学習や各種アルゴリズムなどの解析アルゴリズム開発サービスを提供いたします。過去には医療系のバイタルデータを扱った解析が主でしたが、今後はそれらで培った経験・技術を工業など他の分野の企業様の問題解決にも役立てていく方針です。
【SES】
SESサービスも行っております。