単一の信頼できる情報源：一度定義してどこでも使える組織レベルシステム

一定の規模を超えたすべての組織で見られるパターンがあります。チーム A がアーキテクチャをドキュメント化します。認証サービスのボックスを追加します——名前、説明、テクノロジースタック。チーム B も自分のプロジェクトで同じことをします。チーム C も同様です。3つのプロジェクト、同じシステムの3つの別々の定義、それぞれ微妙に異なります。一つは「Auth Service」、別の一つは「Authentication Platform」、3つ目は「Identity Provider」。同じシステム。3つの名前。異なる点を強調する3つの説明。それらの間に接続はありません。

6ヶ月後、認証チームがサービスの名前を変更しテクノロジースタックを更新します。その変更は3つのダイアグラムのゼロに伝播します。各プロジェクトの現実のバージョンは、実際のシステムからも、お互いからも静かに乖離していきます。

これが一貫性の問題です。怠慢から来るのではありません。すべてのプロジェクトを孤島として扱うアーキテクチャツールから来ます。システムを表現する唯一の方法がプロジェクト内で作成することであれば、そのシステムに触れるすべてのプロジェクトが独自のコピーを持ちます。コピーは乖離します。それがコピーの性質です。

組織レベルシステムはこの問題を解決するために構築しました。

プロジェクトではなく組織に属するシステム

Archyl は C4 システムの2つのスコープをサポートするようになりました。プロジェクトスコープシステムは以前と全く同じように動作します——単一のプロジェクトに属し、そのプロジェクトのダイアグラム上に表示されます。組織スコープシステムは組織に属します。どのプロジェクトからも独立して存在し、どのプロジェクトからでもリンクできます。

この区別が重要なのは、実際のアーキテクチャの動作を反映しているからです。プロジェクト内部のシステムもあります——その境界づけられたコンテキスト内にのみ存在するマイクロサービス、単一のアプリケーションにサービスを提供するデータベース。これらはプロジェクトに属します。しかし多くのシステムはプロジェクトの境界を越えます——共有インフラ、プラットフォームサービス、サードパーティ統合、複数チームが依存するコアビジネス機能。これらは組織に属します。

組織レベルシステムを作成するとき、あなたは宣言しています：このシステムは共有された現実です。その名前、説明、テクノロジー、タグは一度だけ定義されます。それを参照するすべてのプロジェクトが同じ定義を見ます。

仕組み

組織システムの作成

組織システムはプラットフォームの専用セクションから作成します。プロジェクト内と同じ方法でシステムを定義します——名前、説明、タイプ（ソフトウェアシステム、外部システム、またはパーソン）、テクノロジー、タグ。違いは、どのプロジェクトにも紐づかないことです。組織レベルに存在し、すべてのチームに表示されます。

プロジェクトへのシステムのリンク

プロジェクトダイアグラムで作業していて組織システムを参照したいとき、リンクします。モーダルが検索機能付きで利用可能なすべての組織システムを表示します。必要なものをトグルすると、ダイアグラムにすぐに表示されます。

リンクされたシステムはダイアグラム上でネイティブシステムと同じように動作します。そのプロジェクトのレイアウトに合う場所に自由に配置できます。リレーションシップを作成できます。コンテナやコンポーネントにドリルダウンできます。唯一の違いは、システムのコアアイデンティティ——名前、説明、テクノロジー——がプロジェクトからではなく組織の定義から来ることです。

各プロジェクトはリンクされたシステムの独自の位置を保存するため、同じシステムが異なるダイアグラムで異なる場所に配置できます。レイアウトはプロジェクトごと。定義は共有。

リンク解除

プロジェクトが共有システムに依存しなくなったら、リンクを解除します。システムはそのプロジェクトのダイアグラムから消えますが、組織レベルと参照している他のすべてのプロジェクトでは引き続き存在します。データの損失はありません。他のチームへの影響もありません。

なぜこれが重要か

調整なしの一貫性

アーキテクチャドキュメントの一貫性を保つ従来のアプローチはプロセスです。命名規則を書きます。レビュー会議を開きます。他のチームが同じシステムを何と呼んでいるか確認するよう求めます。プロセスは機能しなくなるまで機能します——通常、誰かが急いでいるとき、つまりほとんどの場合です。

組織レベルシステムは一貫性を構造的にします。定義は1つ。プロジェクトはそれを参照します。誰かがシステムの説明やテクノロジースタックを更新すると、リンクしているすべてのプロジェクトが自動的に変更を反映します。Slack メッセージ不要。「ダイアグラムを更新してください」不要。アーキテクチャモデルがそれを強制するため、アーキテクチャは一貫性を保ちます。

正確なクロスプロジェクト依存関係

複数のプロジェクトが同じ組織システムにリンクしているとき、プラットフォームはそれらの接続を把握しています。これは視覚的な慣習ではなく、データのリレーションシップです。Impact Radar は組織システムを通じてプロジェクト境界を越えて依存関係を追跡できます。共有プラットフォームサービスの変更の影響を分析すると、独立したコピーではなく同じシステムにリンクしているため、依存するすべてのプロジェクトが表示されます。

オンボーディングとディスカバリー

プロジェクトに参加する新しいチームメンバーは、他のすべてのプロジェクトが使っているのと同じシステム名、説明、テクノロジーラベルを目にします。「これはどの認証サービス？」という混乱はありません。組織システムは独自のアイデンティティを持ち、そのアイデンティティはどこでも同じです。

重複の削減

一貫性のメリット以外にも、組織システムは単純に作業量を減らします。すべてのプロジェクトが独立して同じインフラをドキュメント化する代わりに——メッセージブローカー、API ゲートウェイ、アイデンティティプロバイダー、モニタリングスタック——それぞれを一度定義します。プロジェクトは数秒でリンクします。微妙に異なるラベルで同じボックスを再作成する時間はゼロになります。

データモデルの変更

内部的には、C4 システムエンティティは2つの相互排他的なスコープをサポートするようになりました。システムはプロジェクトまたは組織のいずれかに属します——両方でも、どちらでもないこともありません。これはデータベースレベルの制約で強制されています。

別のリンクテーブルが、どのプロジェクトがどの組織システムを参照しているかを、ダイアグラム上のプロジェクトごとの位置とともに追跡します。つまり、同じシステムが10の異なるプロジェクトダイアグラムに表示でき、それぞれ異なる位置で、プロジェクトローカルな要素への独自のリレーションシップセットを持てます。

プロジェクトの C4 モデルを読み込むと、プラットフォームはプロジェクト自身のシステムとリンクされた組織システムの両方を取得します。ダイアグラム上でシームレスにマージされます。違いは UI で表示されます——組織システムは共有されていることを示す控えめなインジケーターが付きます——しかし機能的には、プロジェクトシステムと同じ方法でアーキテクチャモデルに参加します。

大きなビジョン

この機能は、より大きな方向性の一部です：Archyl を組織が実際に機能する方法で動作させること。アーキテクチャは独立したプロジェクトの集合ではありません。共有システム、プラットフォーム機能、横断的関心事のネットワークです。ツールはそれを反映すべきです。

組織レベルシステムは、共有インフラが一度ドキュメント化されどこでも参照されるモデルへの第一歩です。クロスプロジェクトビジュアライゼーションのためのグローバルアーキテクチャビューとクロスプロジェクト依存関係分析のための Impact Radar を組み合わせれば、アーキテクチャを接続された全体として理解するプラットフォームが手に入ります——切り離されたダイアグラムのセットではなく。

はじめに

組織レベルシステムは今すぐ利用可能です。組織セクションに移動し、共有システムを作成し、ダイアグラムビューから任意のプロジェクトにリンクしてください。複数のプロジェクトで同じシステムをドキュメント化済みなら、これは統合のチャンスです——一度定義し、どこでもリンクし、コピーを引退させましょう。

アーキテクチャには単一の信頼できる情報源があります。ドキュメントもそうあるべきです。

クロスプロジェクトアーキテクチャについてもっと知るには、グローバルアーキテクチャとリアルタイムコラボレーションをご覧ください。共有システムへの変更がどう伝播するか理解するには、Impact Radar をお試しください。共有システムのガバナンスのある変更については、アーキテクチャ変更リクエストを探索してください。