es_ES Españolja 日本語pt_PT Portuguesezh_CN 简体中文zh_TW 繁體中文

TOGAFアーキテクチャ開発方法（ADM）の概要

Table of Contents hide
1 TOGAFはどこから来たのですか？
2 なぜTOGAF？
3 ADMとは何ですか？
4 ADM入力および出力
5 成果物
6 初期：
7 フェーズA：アーキテクチャのビジョン：
8 フェーズB：ビジネスアーキテクチャ：
9 フェーズC：情報システムアーキテクチャ：
10 フェーズD：技術アーキテクチャ：
11 フェーズE：機会と解決策：
12 フェーズF：移行計画：
13 ステージG：ガバナンスの実装：
14 フェーズH：構造変更管理：
15 アーキテクチャ要件管理：
16 ADM予備段階
16.1 出力成果物：
17 ADMフェーズA：アーキテクチャビジョン
17.1 出力成果物：
18 ADMフェーズB：ビジネスアーキテクチャ
18.1 出力成果物：
19 ADMフェーズC：情報システムアーキテクチャ
20 ADMフェーズD：テクノロジーアーキテクチャ
20.1 出力成果物：
21 ADMフェーズE：機会とソリューション
21.1 出力成果物：
22 ADMフェーズF：移行計画
23 ADMフェーズG：実装ガバナンス
23.1 出力成果物：
24 ADMフェーズH：アーキテクチャ変更管理
25 概要
25.1 TOGAF入門リファレンス
25.2 ArchiMate 3

TOGAF（Open Group Architecture Framework）は、オープンな組織フレームワークです。フレームワーク自体は、詳細なメソッドやエンタープライズアーキテクチャを開発するための一連のサポートツールなど、十分に文書化された知識体系です。TOGAF 9.2は、フレームワークの最新バージョンです。

  • TOGAFは、The Open Groupのメンバーによって開発および保守されており、ArchitectureForumと呼ばれるチームで働いています。TOGAFバージョン1の最初の開発は、1995年に作成され、その後のバージョンのTOGAFは、この知識システムを拡張および改善しました。
  • TOGAFは、世界をリードする企業や組織の一部を代表する300人を超えるアーキテクチャフォーラムメンバーの共同の取り組みによって開発されたため、一般的なエンタープライズアーキテクチャの実践の概要を示しています。
  • エンタープライズアーキテクチャの開発と維持は、多くの利害関係者と意思決定プロセスを含む複雑なプロセスです。TOGAFは、企業のアーキテクチャ仕様、プロセス、および作業成果物を文書化するのに役立ちます。
  • TOGAFを使用することにより、組織は、利害関係者のニーズを反映し、ベストプラクティスを採用し、現在のニーズと将来認識されるビジネスニーズを適切に考慮する一貫したエンタープライズアーキテクチャを開発できます。

TOGAFはどこから来たのですか？

TOGAFは、米国国防総省の情報管理テクノロジアーキテクチャフレームワーク（TAFIM）から生まれました。TOGAF 1.0は、米国国防総省の許可と米国政府からの多額の投資の助けを借りて、長年の調査の末、1995年にようやくリリースされました。TOGAFはこれまでに9番目のリリースであるTOGAF9をリリースしました（最新のリリースはTOGAF 9.2です）

なぜTOGAF？

ITアーキテクチャは、組織のビジネス目標を厳密に反映する必要があります。実際、特定の手法（ビジネスシナリオ）を使用して、ビジネス目標がITアーキテクトによって適切に理解され、TOGAFを使用して開発されたITアーキテクチャに反映されるようにする必要があります。

アーキテクチャ開発にTOGAFADMを採用する必要がある理由は次のとおりです。

  • 包括的な一般的な方法
  • 他のフレームワークを補完するものであり、競合するものではありません
  • 市場で広く採用されています
  • 組織および業界のニーズに合わせて調整可能
  • 無料の永久ライセンスの下で利用可能
  • ベンダー、ツール、テクノロジーに中立なオープンスタンダード
  • 車輪の再発明を回避します
  • ビジネスITの連携
  • ベストプラクティスに基づく
  • フレームワークの進化に参加することが可能

ADMとは何ですか？

アーキテクチャ開発方法（ADM）は、組織のビジネスおよび情報技術のニーズを満たすエンタープライズアーキテクチャを開発するために適用されます。TOGAF ADMは、次の目的を果たすための多数のアーキテクチャ実践者からの継続的な貢献の結果です。

  • エンタープライズアーキテクチャのライフサイクルを開発および管理する方法を説明し、TOGAFのコアを形成します。
  • 組織のニーズに合わせて調整し、アーキテクチャ計画アクティビティの実行を管理するために使用できます。

アーキテクチャ開発方法（ADMの略語と呼ばれることもあります）は、企業のアーキテクチャを開発または変更するために使用される詳細なステップバイステップのプロセスです。

ADMは、アーキテクチャ開発サイクルをカバーする10のフェーズについて説明しています。

これらのフェーズは次のとおりです。

  • 予備段階
  • フェーズA：アーキテクチャのビジョン
  • フェーズB：ビジネスアーキテクチャ
  • フェーズC：情報システムアーキテクチャ
  • フェーズD：技術アーキテクチャ
  • フェーズE：機会と解決策
  • フェーズF：移行計画
  • ステージG：ガバナンスの実装
  • フェーズH：アーキテクチャ変更管理
  • 要件管理

ADM入力および出力

TOGAFは、各フェーズからの多くの入力および出力の成果物を提供します。

  • これらは提案であり、正確に従う必要はありません
  • 作成された各成果物は、変更がいつ発生したかを示すためにバージョン管理する必要があります
  • 示されているバージョン番号も提案であり、従う必要はありません

成果物

契約上指定され、次に利害関係者によって正式にレビュー、合意、および承認された作業成果物。通常、プロジェクトの完了時にアーカイブされるか、参照モデルとしてアーキテクチャリポジトリに移行されます

初期：

初期段階の主な目標は、組織に必要なアーキテクチャ機能を決定して確立することです。

重要な部分の1つは、何を行う必要があるか、そしてそれをどのように実装するかを決定することです。たとえば、主な出力は、  要件の概要を示し、この作業をサポートするために必要なスコープ、構造、ツール、またはアーキテクチャフレームワークを決定するアーキテクチャ作業要求です。

この段階で、TOGAFは、今後のADM反復のニーズを満たすように特別に調整されています。基本原則を定義し、企業構造とビジネスが必要な変更を加える能力を評価し、TOGAFを他の管理フレームワークと統合します。この段階では、提案された変更の影響を受ける企業組織を制限し、正しいガバナンスとサポートフレームワークを確認し、EAチームと組織を定義および確立し、アーキテクチャの原則を特定および確立し、TOGAFおよびその他のフレームワークをカスタマイズし、ツールを実装するための手順があります。 。このフェーズの終わりに、EAチームはADMサイクルの反復を追跡する準備ができている必要があります。これは、予備段階がADMダイアグラムの上部に示され、段階AからHのメインループの外側にあるためです。

フェーズA：アーキテクチャのビジョン：

フェーズAは、ADMの反復で提供される明確なアーキテクチャ作業明細書を提供します。また、提案されたエンタープライズアーキテクチャのビジョンも提供します。この方向性は、反復プロセス全体でADMの作業をガイドするために不可欠です。建築作業の 声明 アーキテクチャビジョンで概説されているアーキテクチャを開発および展開するための手順を定義します。提案されたエンタープライズアーキテクチャが提供する機能とビジネス価値に対する高レベルの要望を提供するのはビジョンです。フェーズAは、建設ジョブアプリケーションから始めて、提案された機能の利点を企業の利害関係者および意思決定者に販売するためのツール（このビジョン）を提供します。ビジネスシナリオは、ビジネス要件を理解し、必要な機能によって示されるアーキテクチャ要件を明確にするために使用されます。これは、アーキテクチャ作業明細書に文書化されており、最終的なアーキテクチャをサポートするためのコンセンサスを構築するために使用されます。スポンサー組織が文書に署名すると、コンセンサスが生まれます。

フェーズAの手順は、建設作業要求を明確な建築作業明細書に変換し、会社が必要な建築変更を行うことができ、準備ができ、進んで、コミットできるようにすることです。これには、スコープの定義を含むアーキテクチャプロジェクトの確立、およびアーキテクチャとビジネス原則の確認と詳細化が含まれます。フェーズAは、利害関係者とその懸念事項および要件を特定し、予備フェーズのビジネス目標、推進要因、および制約を確認します。成功を確実にするために、ビジネス能力を評価し、ビジネス変革の準備を評価し、変革のリスクを解決します。

フェーズB：ビジネスアーキテクチャ：

TOGAFは、エンタープライズアーキテクチャをビジネス機能を向上させる方法と見なしています。これが、最初のアーキテクチャ開発フェーズでビジネスアーキテクチャを扱う理由  です。

ビジネスの観点からのADM— インフラストラクチャ作業の準備段階で、強力なビジネス需要を判断し、インフラストラクチャ作業 と アーキテクチャビジョンステートメント のフェーズAに向けてさらに洗練され  ます。

ビジネスアーキテクチャフェーズの主要な目標は、ターゲットビジネスアーキテクチャを開発することです。これは、企業がアーキテクチャビジョンを実現し、アーキテクチャ作業要求を解決する方法を示します。その2番目の目標は、ベースラインとターゲットのビジネスアーキテクチャ間のギャップを埋めるために、候補となるアーキテクチャロードマップコンポーネントを最初に特定することです。TOGAFは、ビジネスアーキテクチャの知識を、他の分野（データ、アプリケーション、テクノロジーなど）でのアーキテクチャ作業の前提条件と見なしています。ビジネスアーキテクチャはまた、主要な利害関係者に、アーキテクチャ作業の商業的価値と投資収益率を示します。アクティビティモデルやプロセスモデル、ユースケースやクラスモデル、ノード接続図などのビジネスモデル、

3つのアーキテクチャ開発フェーズ（B、C、およびD）はすべて、同様の手順に従います。利用可能な参照モデルを再利用し、すべての出力をカスタマイズして、利害関係者の視点に対応することが重要です。次に、アーキテクトはビジネスアーキテクチャのベースラインと目標の説明を作成し、ギャップ分析を実行して、あるアーキテクチャから別のアーキテクチャに変換する方法を決定します。

フェーズC：情報システムアーキテクチャ：

TOGAFは、フェーズC（情報システムアーキテクチャ）を2つの部分に分割し、 データ と アプリケーション アーキテクチャの開発をカバーします。TOGAFドキュメントには、2つのドメインをカバーする短い紹介の章があり、その後にデータとアプリケーションに関する別々の章が続きます。他のアーキテクチャ開発段階（B＆D）と同様に、目標は、データとアプリケーションのターゲット情報システムアーキテクチャを開発し、ベースラインとターゲットアーキテクチャ間のギャップに基づいて候補アーキテクチャロードマップコンポーネントを決定することです。

フェーズCには、常にデータとアプリケーションアーキテクチャの組み合わせが含まれます。両方を提供することが含まれており、順序は関係ありません。両方の方法の支持者がいます。データとアプリケーションの手順は非常に似ています。参照モデル、視点、ツールを選択してください。ベースラインを作成してから、アーキテクチャの説明を見つけ、ギャップ分析を実行し、候補となるロードマップコンポーネントを定義します。アーキテクチャ環境全体への影響を解決します。正式な利害関係者のレビューの後、アーキテクチャが最終的に決定され、アーキテクチャ定義ドキュメントが作成されました。

データとアプリケーションの主な違いはテーマにあり、これはさまざまな参照モデル、テクノロジー、およびアーキテクチャ表現の使用に反映されています。たとえば、データアーキテクチャではエンティティの関係やクラス図を使用できますが、アプリケーションアーキテクチャではアプリケーションの通信図やソフトウェアエンジニアリング図を使用できます。

フェーズD：技術アーキテクチャ：

フェーズDは、アーキテクチャプロジェクトの技術アーキテクチャを開発するTOGAFのフェーズです。テクノロジーアーキテクチャは、プラットフォームサービスと論理的および物理的なテクノロジーコンポーネントの構造と相互作用を記述します。フェーズDは、ビジネスコンポーネントを実現するために、データおよびアプリケーションコンポーネント（フェーズCで開発）をサポートするターゲットテクノロジアーキテクチャを開発します。

フェーズB、C、およびDで開発されたアーキテクチャを組み合わせて、アーキテクチャのビジョンを実現します。利害関係者の懸念と建設作業の要求を解決します。他のアーキテクチャ開発フェーズと同様に、フェーズDは、ベースラインからターゲットへの移行を実現するための候補アーキテクチャロードマップコンポーネントを特定します。フェーズDの手順は、フェーズBおよびフェーズCの手順とほぼ同じです。主な違いは、現在はテクノロジーに重点が置かれていることです。したがって、これには、パフォーマンス、保守性、場所、遅延、または可用性などの技術参照モデルと技術標準または測定値が含まれます。

情報システムとビジネスアーキテクチャを真にサポートする技術アーキテクチャを構築するには、成果物と成果物を決定することが非常に重要です。正しいスコープを取得すると返品がスピードアップしますが、スコープが大きすぎると実装の成功が妨げられます。これは、展開テクノロジ自体ではなく、アーキテクチャのビジョンと作業要求に真に対応する技術アーキテクチャの開発に関するものです。

フェーズE：機会と解決策：

フェーズEはその名前が付けられています。特定のソリューションを実装することにより、ターゲットアーキテクチャを提供する機会を見つけることです。フェーズEは、分析と建物開発フェーズ（B、C、およびD）の推奨事項を組み合わせることにより、アーキテクチャロードマップの最初の完全なバージョンを生成します。

この段階では、主な焦点はアーキテクチャを提供する方法にあります。したがって、アーキテクチャロードマップの作成に焦点を当て、ターゲットアーキテクチャを達成するためのタイムラインに作業パッケージを一覧表示します。変更が非常に大きく、ベースラインからターゲットアーキテクチャに直接移行できない場合、ステージEは、中間アーキテクチャまたは移行アーキテクチャで構成されるインクリメンタルアプローチを生成します。フェーズEは、必要なアーキテクチャの変更を、作業パッケージを実行するための資金とリソースを備えた投資手順とプロジェクトにマッピングし、移行アーキテクチャとターゲットアーキテクチャを提供します。この段階での入力は、初期段階から出力されたほとんどすべてのものです。これらの手順は、これらの出力を取得します。それらを統合し、依存関係を分析し、違いを調整します。組織が変更を加えることができることを再確認します。フェーズEは、要件、アーキテクチャドキュメント、およびアーキテクチャロードマップを改善および更新します。重要な出力は、実装および移行計画の最初のステップです。

フェーズF：移行計画：

ADMの初期段階では、アーキテクチャの変更の必要性を特定し、このニーズをサポートするためのビジネス、データ、アプリケーション、および技術アーキテクチャを開発しました。次に、第2フェーズでは、投資機会を活用して特定のソリューションを特定するために、高レベルの実装および移行計画が作成されます。ターゲットアーキテクチャ：フェーズFは、詳細な実装と移行の計画、および最終的なアーキテクチャのロードマップを完成させます。

また、計画が、社内で使用されている変更管理方法や、変更ポートフォリオ全体の他の計画と調整されていることを確認します。最後に、フェーズFは、主要な利害関係者がビジネス価値、作業パッケージのコスト、および移行と将来のアーキテクチャを完全に理解することを保証します。ADMの初期段階は、エンタープライズアーキテクチャチームによって非常に導かれますが、EからHまでの段階では、他の変更エージェントとのコラボレーションが必要です。

フェーズFでは、実施と第三国定住計画を成功させるために、特に4つの管理フレームワーク間の緊密な協力が必要です。

4つの領域は次のとおりです。

  1. 事業計画
  2. エンタープライズアーキテクチャ
  3. ポートフォリオ管理
  4. プロジェクト管理

協力を通じて、これら4つの領域は、業績評価、投資収益率、ビジネス価値、主要な成功要因、有効性の測定、戦略的適合性などの基準を使用して、作業に優先順位を付ける必要があります。

ステージG：ガバナンスの実装：

実際の開発と実装はフェーズGと並行して行われます。フェーズGは、実装プロジェクトとその他の進行中のプロジェクトが定義されたアーキテクチャに準拠していることを確認します。

通常、ターゲットアーキテクチャは、ビジネスの価値とメリットを可能な限り迅速に達成し、変革計画のリスクを軽減するための一連の変革として開発されます。それぞれの変革は、ターゲット企業が独自のビジネス上の利益を実現するための一歩です。

フェーズGに到達するまでに、アーキテクチャが開発され（フェーズAからD）、アーキテクチャを提供する機会とソリューションが特定され（フェーズE）、詳細な実装と移行の計画が完了しました（フェーズF）。 ）。したがって、フェーズGアーキテクチャチームの役割は、アーキテクチャの実装を監視することです。これは、展開の範囲と優先順位を検証し、開発とソリューションの展開をガイドし、コンプライアンスレビューを実行することによって行われます。

アーキテクチャ契約書は、アーキテクチャの変更を推進するために使用されます。フェーズGの開始時に生成され、アーキテクチャ機能と実装の責任者によって承認されます。これは、アーキテクチャのガバナンスコンプライアンスを評価するためのメカニズムです。

フェーズH：構造変更管理：

計画どおりに進んだものはありません。常に新しい要件とアーキテクチャの変更があります。フェーズHでは、アーキテクチャへの変更をまとまりのある構造化された方法で管理するための変更管理プロセスについて説明します。通常、これには、ガバナンス要求、新しいテクノロジー、またはビジネス環境の変化を継続的に監視する必要があります。

このプロセスは、これらの変化に柔軟に対応し、迅速に開発できる動的な環境として、実現されたエンタープライズアーキテクチャをサポートする必要があります。フェーズHでは、ガバナンス機関が標準を設定して、変更要求に単純なアーキテクチャの更新が必要かどうか、またはアーキテクチャ開発方法（ADM）の新しいサイクルを開始する必要があるかどうかを判断することが重要です。変更は、ビジネス価値に直接関連している必要があります。エンタープライズアーキテクチャの使用方法は、アーキテクチャ開発サイクルの最も重要な部分であるため、フェーズHでのビジネスの成長と衰退を監視することが重要です。

結局、昨日組織で機能していたエンタープライズアーキテクチャは、現在または将来の機能をサポートしなくなりました。フェーズHでの変更要求の出力は、単純化として分類できます。通常、投資を削減するための要件によって推進されます。増分変更-既存の投資からの追加の価値が必要です。または変更を再設計します。これは、投資を増やし、によって推進される新しい価値を生み出すための要件です。

アーキテクチャ要件管理：

ADMの各段階で、生成、分析、およびレビューの要件が必要です。要件管理フェーズでは、ADM全体でこれらのアーキテクチャ要件を管理するプロセスについて説明します。要件管理フェーズはADMの中核です。そのため、ADMミステリーサークルの中央に表示されます。この段階では、要件管理プロセスと、プロセスがADMの他の段階にどのようにリンクされているかについて説明します。要件は静的ではありません。要件は、ADMの完了の各段階とADMのサイクルの間で動的に変化します。

エンタープライズアーキテクチャの要件と、これらの要件に対するその後の変更は、ADMフェーズに関連して、およびADMサイクル間で識別、保存、入力および出力されます。需要の変化に対処することは非常に重要です。アーキテクチャは不確実性と変化、つまり利害関係者の期待と可能性の間の「灰色の領域」を扱います。したがって、アーキテクチャ要件は常に変化します。

さらに、アーキテクチャには、市場の状況の変化や新しい法律など、企業の制御が及ばない多くの推進要因と制約が含まれ、予期しない方法で要件に変化が生じます。

TOGAFは、要件管理プロセス自体が要件を処理、解決、または優先順位付けしないことを強調しています。これは、ADMの関連フェーズで行われるためです。需要管理段階は、ADM全体の需要を管理するプロセスにすぎません。

ADM予備段階

TOGAFのカスタマイズやアーキテクチャの定義など、アーキテクチャ機能を作成するために必要な準備および開始アクティビティ

出力成果物：

ADMフェーズA：アーキテクチャビジョン

アーキテクチャ開発サイクルの初期段階。これには、アーキテクチャ開発イニシアチブの範囲の定義、利害関係者の特定、アーキテクチャビジョンの作成、およびアーキテクチャ開発を進めるための承認の取得に関する情報が含まれています。

出力成果物：

ADMフェーズB：ビジネスアーキテクチャ

ビジネスアーキテクチャ：合意されたアーキテクチャビジョンをサポートするためのビジネスアーキテクチャの開発

出力成果物：

ADMフェーズC：情報システムアーキテクチャ

情報システムアーキテクチャ：合意されたアーキテクチャビジョンをサポートするための情報システムアーキテクチャの開発

ADMフェーズD：テクノロジーアーキテクチャ

テクノロジーアーキテクチャ：合意されたアーキテクチャビジョンをサポートするためのテクノロジーアーキテクチャの開発

出力成果物：

ADMフェーズE：機会とソリューション

Opportunities＆Solutionsは、初期の実装計画と、前のフェーズで定義されたアーキテクチャの配信手段の特定を行います

出力成果物：

ADMフェーズF：移行計画

移行計画では、詳細な実装および移行計画を完成させることにより、ベースラインからターゲットアーキテクチャに移行する方法について説明します。

ADMフェーズG：実装ガバナンス

実装ガバナンスは、実装のアーキテクチャ上の監視を提供します

出力成果物：

ADMフェーズH：アーキテクチャ変更管理

アーキテクチャ変更管理は、新しいアーキテクチャへの変更を管理するための手順を確立します。要件管理は、ADM全体でアーキテクチャ要件を管理するプロセスを調べます。

概要

ADMは包括的な一般的な方法です

  • アーキテクチャの開発に関連するさまざまなフェーズとステップのシーケンスを推奨します
  • これは反復法です
  • TOGAFの他の部分をアセットとプロセスに利用します
  • 他のフレームワークからの他の成果物と一緒に使用できます

次の図に示すように、各開発フェーズのTOGAFADMの概要は次のとおりです。

  1. TOGAFADMガイドスルーの詳細
  2. Just-in-TimeTOGAFテンプレートの詳細
  3. ArchiMateツールの詳細
  4. ビジュアルパラダイムを無料でお試しください

TOGAF入門リファレンス

ArchiMate 3

コメントを残す

メールアドレスが公開されることはありません。