documentation - IT資産の「ディペンデンシーグラフ」を作成する方法

Question

私の顧客の 1 人は、会社 (約 2500 人の従業員を抱える旅行とレジャーの会社) で使用されるさまざまなアプリケーションの相互依存関係のインタラクティブな「マトリックス」を作成しようとしています。

アイデア (まだプロトタイプ段階) は、Visio または同様のツールに基づいて一種のマップを作成することです。このマップは、会社内のすべての IT 資産間のコミュニケーションと相互依存性を追跡し、誰かが変更を要求したときに取得できるようにします。影響の概要。

これはカジュアルな設定で言及されたものであり、これに直接取り組むことは私の責任ではありませんが、漠然と関連する方法論 ( Zachman Framework ) に関して、私がすでに知っていることを少し貢献しました。

この種の取り組みに役立つ可能性のある方法論やツールを知っているか、貢献できる具体的な経験があるかどうか、ここにいる人々から聞きたいです。回答を要約して、結果を顧客に送り返します。これが彼らの仕事に役立つことを願っています (これは少し先見の明があり、ドキュメントプロジェクトのすべての落とし穴に陥りやすいと考えていますが、それでも追求する価値は十分にあります)。

注:問題は、「IT 資産について収集したこのすべてのデータがあり、Graphviz 用に Visio や Google を購入したり、それを MindMapping ツールに変換したり、Jgraph などを使用してカスタムナビゲーターを作成したりする余裕がない」ということではありません。問題は、「インターフェイス、バージョン、およびパッケージの変更により、定期的にデータを更新する必要がある場合があることを考慮して、関連/有用な情報をどのように収集し、これらをどのように整理するか?」です。

これはビジュアライゼーションの問題ではないか、まだそうではありません。まず、データの収集と整理から始めなければなりません。ツールを提案する場合は、データの収集と管理の部分も含める必要があります (例: Rational System Architect)。しかし、その場合は、実際の経験がある場合、または非常にニッチでよく知られていないと確信している場合は、それを提案してください (Google で検索できます、ありがとうございます)。いくつかの本/方法論を提案したい場合は、これも役に立ちます (私は Zachman Framework しか知らないので、それが本当に適切かどうかはわかりません)。

「Excelファイルを作成するだけです」または「SmartDrawを使用できます!!!」あまり役に立ちません、恐れています。

とても相性が良さそうなイテラプランを発見！

score 7 · Accepted Answer

私が間違っている場合は訂正してください...システムの依存関係を追跡するためのツールとして図を使用しようとしています。

その場合、レイアウトをグラフィカルにマップするために使用するのは、おそらくUMLの配置図です。

システム/サーバー/物理資産をボックスオブジェクトとしてマップし、それらの内部で、さまざまなアプリケーション、データベース、コンポーネント、およびそれらの相互関係をマップします。

UMLを使用する際の問題は、プログラマーが主にクラス図に焦点を合わせているため（ソフトウェア内のデータモデリングと直接関係しているため）、非クラスUML図で「適切な」リソースと例を見つけるのが難しいことです。

私は過去にこれを使用して、比較的複雑なシステム間クロスアプリケーション実装をマッピングし、システムの設計中に他の開発者と共有できる方法でアイデアをまとめました。要するに、それは単純で、その仕事をうまくやりました。

ダイアグラムを作成するために、diaを使用しました。もう一度やり直す必要がある場合は、Visioを使用します。これは、オンラインで図を作成するための事前に作成されたステンシル/テンプレートパッケージを見つけるのがはるかに簡単であり、必要なものがない場合は、自分で作成するのが非常に簡単だからです。 Visioのステンシル。

注：私はVisioで電気設計を行った経験が豊富（数百時間）なので、客観的な比較を行うためのツールに精通していると思います。

明確に指定されたフォーマットを採用することの欠点は次のとおりです。

彼らは通常過度に複雑です
それらは通常、厳密な形式または一連のルールを持っています
システムを図に合わせて成形しようとしていることに気付くのは簡単ですが、その逆のはずです。
ダイアグラムは簡単に複雑になりすぎて、ダイアグラムを作成した人以外の人が理解/理解できない場合があります。

私の提案は次のとおりです。

ダイアグラムをできるだけ単純にします
ルールを破ることを恐れないでください
ダイアグラムをできるだけ単純にします
ダイアグラムをできるだけ単純でシンプルに保つために、できる限りのことをしてください
...あなたはポイントを取得します。

ダイアグラムを見たことがない開発者が、ダイアグラムを見てから最初の数分以内にレイアウトと意味を解読し始めることができない場合、それはおそらく良いことよりも害を及ぼすでしょう。

Zachman Frameworkは、次の理由で悪いオプションだと思います。

ダイアグラムが伝えようとしている「ポイント」を理解するのは難しい
ダイアグラムの形式が複雑すぎます
ルールは、システムの設計を補完するものではなく、制限する柔軟性のない形式になっています

あなたがオプションを研究している間、これを自問してください。ダイアグラムのポイントを理解していますか？

設計を図式化する際の問題は、間違って実行すると、その価値よりも多くの頭痛の種が発生し、誰もそれを使用しないことです。通常、悪い設計文書よりも優れた設計文書はありません。

それがお役に立てば幸いです。

score 3 · Accepted Answer

顧客が影響を理解したい場合は、アーティファクトとは何か、アーティファクト間でどのような情報が流れるか、会社の各部門がアーティファクトとどのように相互作用するかをモデル化する必要があります。

SADTモデルの構築を検討することもできます。SADT モデルのボックスはプロセスを表します。ラベル付けされたデータ入力アークは、どの [おそらく複合的な] 情報/リソースがプロセスに供給されるかを示します。ラベル付けされた出力アークは、それによって生成されたデータ/リソースを示しています。制御アークは、処理を制御する「大きな」信号を示します。リソース/メカニズムアークは、プロセスを実行するために必要なリソース (ハードウェアシステム、ネットワークなど) を示します。

あなたのタスクでは、アプリケーションと会社の活動を SADT プロセス (ボックス) として扱います。データの入出力および制御アークは、アプリケーション (SADT ボックス) を他の SADT ボックス、または外部データソースおよびシンク (社内部門、スタッフ、販売、出荷、たとえば企業の利害関係者) に接続します。したがって、さまざまなアプリケーションを介して企業内を流れる情報フローと、アプリケーションが消費/処理/生成/使用する情報、およびデータを生成/使用するエージェントをモデル化できます。(これをすべて行うことを「構造化分析」と呼びます)。

[洗練された SADT モデルの場合、各プロセスボックスをサブ SADT ダイアグラムに再帰的に分解すると便利です。アプリケーションの依存関係だけをモデル化するためにこれが必要だとは思いません。アプリケーションが本当に複雑で、データフローの分離が重要でない限り、アプリケーションが内部でどのように機能するかを知る必要はありません。]

情報の入力/出力の変更、アプリケーションの削除は、SADT ダイアグラムで明確に対応するため、結果がどうなるかをよりよく理解することができます。

これは大きな仕事であり、最新の状態に保つために作業する必要があります。これは、長期的には誰もがサインアップしない限り失敗する可能性が高い場所です.

SADT を使用したことがない人にとっては、理解するのが非常に簡単なシステムであり (これは、他の回答の口述をシンプルに保つことと一致します)、複雑な処理タスクを、見ることができる (そして実際に通信する) チャンクに分割するのに非常に効果的です。本質的にすべて、マネージャーにさえ！SADT を機能させるための鍵は、ずさんにならないようにすることです。アークとノードを慎重に定義し、情報のソースまたはシンクをスキップしないでください。そうすれば、SADT はかなりの額を支払います。[ほとんどのホワイトボードのボックスダイアグラムとアローダイアグラムはひどいものです。実際に何がアクションで、何がデータであるか、またはすべての情報が実際に表示され、誰がそれを使用しているかを判断できません]。

IMHO SADT モデルが、有限状態オートマトンの一般化であるペトリネットの一般化である、任意に複雑な非同期計算をモデル化する色付きのペトリネットの背後にある直感を捉えていることに注目するのは興味深いことです。

score 2 · Accepted Answer

同じ目標（影響分析を行うための依存関係を見つける）を達成できるカスタムWebアプリを実装した少なくとも2つの顧客、2つの大手金融機関を知っています。そして、物事を「視覚化」するためのマップは必要ないと謙虚に思います。

基本的に、マシン、サービス（アプリサーバー、データベースなど）、アプリケーション（言語、機能ドメインなど）、およびアプリケーション間の依存関係を保存し、特定のアプリの（オプションで一時的な）依存関係を見つけることができるクエリモジュールを実装します（からに依存し、レポートを印刷します。

これは、RoRやGrailsなどの迅速なCRUDアプリケーション開発フレームワークを使用して実装します。これは、彼ら（上記の金融機関）が行ったことです。

score 2 · Accepted Answer

最初の問題は、このすべての情報を保持するための概念的なフレームワークを構築する方法です (注意: データの形式について話しているのではなく、データに意味を付ける方法について話しているのではありません)。これは見た目よりも難しい作業ですが、幸運なことに、すでにかなりの作業が行われているため(図 1 を参照)、白紙の状態から始める必要はありません。

次に、情報を収集する必要があります。ありがたいことに、クライアントはそれほど大きくないので、それで成功する可能性がありますが、大規模な組織の場合、IT インフラストラクチャのさまざまな部分間の実際の依存関係が実際に何であるかを知らないことがよくあります. （彼らは自分が知っていると思っているかもしれませんし、何かを変えて予期せぬ結果の法則が噛み付くまで、その幻想を持ち続けるでしょう.）これを助けることができるいくつかの製品（無料または商用）をお勧めできればいいのですが、私が本当に持っているのは、戦争の話と満足の欠如の混合です. 特に、この種の従来型のツールの多くは、仮想化されたサーバーにうまく対応していないようです。この種のオープンソースがあれば、それについて聞きたいです!

最後に、情報を提示する必要があります。これは、ここでの他のほとんどの回答が対処する最も簡単なビットです。ここでの私の唯一のコメントは、情報の全体的な (概念的な) グラフはおそらく複雑すぎて、全体を表示して理解できる状態に保つことができないということです。部分的なビューのみが表示されます。

score 1 · Accepted Answer

@ p.marino EAI / ESB製品の図表部分は、通常、適度に複雑なシステムには価値がありません。最大の問題は、手動で過度に調整することなく、システムの全体像と意味のあるスライスを表示できるものをまだ見たことがないということです。

Mule Galaxy、WSO2 Registyry、JBossの同様の製品などのOSレジストリ/リポジトリを確認することをお勧めします。

私はミュールギャラクシーでこれらの線に沿って何かをした経験があります。異なるタイプの属性と依存関係を持つエンティティを定義できます。各変更は監査追跡され、ライフサイクルに従ってプロモートできます。エンティティは、抽象またはファイル（アプリケーションのメイン構成ファイルなど）にすることができます。また、各エンティティまたはドメインはアクセス許可を持つことができます。

これにより、システムの論理構造を保守可能な方法で記述することができます。視覚化するには、自分でロールする必要があります。単純なRESTスタイルのAPIを介してデータを吸い上げることができます。

score 1 · Accepted Answer

Graphvizを使ってみましたか?

テキストファイルの依存関係に基づいてグラフを描画できます。単純！

基本的な例と結果の図については、 Graphviz ギャラリーから始めることをお勧めします。

score 0 · Accepted Answer

データを保存するための良い解決策は、単純なカスタムWebアプリケーションを作成することかもしれません。要件が明確に示されている場合は、それは簡単なことです。カスタマイズ可能な巨大なツールを購入するよりも安いはずですが、開発には時間がかかる場合があります。私の経験から、すべてを何もしないように設計された新しい汎用ツールについて学ぶよりも、ニーズにぴったり合った何かをしたほうがよい場合があります。

視覚化について：UMLと関連する図のさまざまなツールを確認したところ、ほとんどのタスクに非常に適した2つが見つかりました（非常に直感的で、使いやすく、時間の節約になります）。

VisualParadigm-企業のもの、たくさんの図、あなたのケースに推奨される非常に簡単なインターフェースを備えた強力なものだと思います。扱うデータを維持するためのサポートもあるかもしれません。
UMLet-私のお気に入りの1つ:)非常にシンプルで、ビッグプレーヤーができることのほとんどを実行できます。

この場合、Visioにはアドバイスしません。小さな図には便利ですが、小さな図のようには聞こえません。

score 0 · Accepted Answer

質問が「クローズ」され、報奨金が支払われたとしても、実際の問題に取り組む人は非常に適したツールを見つけたので、関心のあるすべての人 (または探している人) のためにこれを含めます。将来の質問）：

https://www.iteraplan.de/en

score 0 · Accepted Answer

この問題の正確な範囲や、どれだけの労力を投資する価値があるかはわかりませんが、人とシステムがどのように相互作用するかを文書化する最も明白な方法の 1 つは、ワークフロー。実際に機能するものからよりドキュメントに基づいたものまで、さまざまなワークフロープログラムが数多くあります。ワークフロー内のすべてのプレーヤーが何であるかを把握することです。人/役職の場合もあれば、システムの場合もあります。

大まかなワークフローであっても、ワークフローを通じて、どのユーザーがどのシステムとどのようなアクションを介して対話するかを分析するのはかなり簡単です。もちろん、これは簡単な作業ではありません。各ジョブのタスクを説明することは間違いなく仕事です。ただし、ワークフローを実行することの良い点は、簡単に理解できることです。これは会社全体に配布することができ、より簡単に最新の状態に保つことができます。これは、すべてのマネージャーが自分自身とチームのために維持できるものであるためです。

ワークフローソフトウェアを検討するときは、ワークフローを十分に詳細に記述できること、および作成したプログラムを使用して結果のデータを簡単に分析し、依存関係グラフに変換できることを確認してください。

また、それ自体が優れたドキュメントとしても機能します。

score 0 · Accepted Answer

アプリケーション、テクノロジー、アセットなどに関する情報を整理してレポートするために、私は Iteraplan をとても気に入っています。これは、「IT ランドスケープ」に焦点を当てたオープンソースのエンタープライズアーキテクチャモデリングツールであり、技術資産に関するデータ (リストとリンク) をキャプチャし、レポートを作成することになります。そのため、「すべての事業部門で X を実行するためにどのアプリケーションが使用されているか」、「寿命を迎えたテクノロジーを実行しているシステムはどれか」、「このシステムでどのアプリケーションが実行されているか」などの質問にうまく答えることができます。サーバー」または「どのシステムがセキュリティ監査に失敗したか」。詳細はhttp://www.iteratec.deをご覧ください。

UML ダイアグラムについては、Sparx Enterprise Architect が優れており、かなり安価です。http://www.sparxsystems.com。ダイアグラムの内容を認識している Visio と考えてください。したがって、実際にはデータベース内にエンタープライズ/アプリケーションのモデルを構築しており、ダイアグラムはそれに関連付けられています。とてもパワフルな。Rational よりも使いやすく、大幅に安価です。

score 0 · Accepted Answer

Visual Studio 2010 には、さまざまな .net クラスの依存関係を示すグラフを生成できる "Architect Explorer" という気の利いた新機能があります。

使用しているテクノロジーを教えていただけると助かります。

score 0 · Accepted Answer

関係だけをキャプチャする必要があるのか、それとも役割をキャプチャする必要があるのかはわかりません（親子関係のように、依存関係があるかどうかに依存します）。以下は、必要なすべてを行うようです：

_{(出典: heeroz.com )}

score 0 · Accepted Answer

データの収集と管理には Iteraplan も使用しています。これは、エンタープライズアーキテクチャのデータ収集や、特定の種類の視覚化の生成に最適です。

UML ダイアグラムには、すばらしい Sparx を使用しています。この 2 つを統合するためのツールを開発中です。Sparx リポジトリに Iteraplan からのデータを取り込んでいるため、図を非常に簡単に作成できます。

documentation - IT資産の「ディペンデンシーグラフ」を作成する方法

13 に答える 13

Related

Reference