部品Aを動かすには部品Bが必要で、部品Bを動かすには部品CとDが必要だが、部品Eは単独で動く・・・ モノを作る場合、こうした各部品間の依存度は重要な意味を持つ。製造の現場では、部品間の依存性を検証するため、1970年代より「ディペンデンシーストラクチャマトリックス」（DSM：依存構造マトリックス）と呼ばれる方法論が使われてきた。この手法をソフトウェアシステムに適用し、アーキテクチャを管理できないかと考えたのが、米マサチューセッツ州で2004年に創業したベンチャー企業のLattixだ。
Lattixの開発したツールは、設計および開発の両段階において、ソフトウェアの各モジュール間の依存度を判断する。現状のソフトウェアの問題点について、Lattixの創設者でバイスプレジデントのFrank Waldman氏は「ソフトウェア設計者はUMLなどを使って設計図を描くが、その図の意図するところが開発者にうまく伝わらないこともある。その結果、設計者はモジュールAを動かすためにモジュールBが必要で、モジュールBを動かすためにCが必要だという階層的な設計図を作ったにも関わらず、開発段階ではモジュールBを動かすためにAとCの両方が必要だという逆構造的なコードを書いてしまう恐れがある。逆に、設計の段階ですでに逆構造的な設計図が作られてしまうこともある。特に大規模な開発の場合、設計もコーディングも複雑なため、モジュール同士の依存性が把握しきれずこうした問題が起こりやすい」と話す。
Lattix設立者のひとり、Frank Waldman氏Lattixのツールでは、設計段階のUMLやコード化されたアプリケーションから、まず各モジュールの依存度を可視化するための初期DSMを作成する。この段階で示されたモジュールの依存関係を基に、モジュールの階層を作る。アーキテクチャのあるべき姿は、上の階層にあるモジュールが下の階層のモジュールから依存されていない状態（つまり、モジュールAがモジュールBより上の階層にある場合、AがBを使うことはあっても、BがAを使うことはない）となるはずだが、大規模なソフトウェアの場合このモジュールが何百、何千にも上るため、依存性の違反が起こりやすい。違反件数が多ければ多いほどシステムの安定度は下がってしまうが、Lattixのツールはこうした依存性の違反を見つけ出し、警告を与えると共に、改善策の提案もする。
また、同ツールではモジュールを階層化する際に依存度によってモジュールをグルーピングするが、グルーピングしたモジュールが他のどのモジュールにも依存していない場合、そのモジュールは独立した部品として他のソフトウェアコンポーネントとしても利用できるため、コンポーネントの再利用も促進できる。
Waldman氏は、これまでのコード分析ツールとLattixのツールとの違いについて、「他社のコード分析ツールは、モジュール同士の依存性は見えても、Lattixのツールのようにモジュールを階層化して表示する機能はないため、どの依存性に問題があるのか開発者が判断しなくてはならなかった」と話す。また、設計者と開発者が独自で使うツールはあったものの、両者が共に利用できるということもLattixのツールの特徴だ。
「変更を加えるごとに複雑さを増し、品質が下がってしまいがちなソフトウェアの開発だが、変更があるごとにLattixのツールを利用すれば、ソフトウェアのライフサイクル全体でアーキテクチャの管理が可能となる。この分野でトップ企業となるのがLattixのミッションだ」（Waldman氏）
