DYAフレームワーク

ダイナミックエンタープライズアーキテクチャ（DYA）は、コンサルティング会社Sogetiによって開発されたエンタープライズアーキテクチャフレームワークです。^[1]ソフトウェア設計全般とアーキテクチャ設計機能の改善に重点を置いています。^[2]

DYAフレームワークは以下のモジュールで構成されています: ^[3]

• DYA|インフラストラクチャ、インフラストラクチャアーキテクチャに関する
• DYA|ソフトウェア、ソフトウェアアーキテクチャに関するもの
• DYA|ビジネス、ビジネスアーキテクチャに関する
• DYA|ガバナンス、ITガバナンスに関するもの、および
• DYA|Principles、建築原則の発展について

DYAフレームワークの概念は、2001年にSogetiのRoel Wagter、Marlies van Steenbergen、Martin van den Berg、Joost Luijpersによってオランダ語の書籍「DYA: snelheid en samenhang in business- en ICT-architectuur」で初めて紹介されました。 ^[4]は改訂され、英語に翻訳され、2005年に「Dynamic Enterprise Architecture: How to Make It Work」として出版されました。^[5]

DYA|インフラストラクチャは、2005年にMicrosoft MSDNで公開されたホワイトペーパーで初めて示唆されました（2007年に新しい投稿に置き換えられました）。 ^[6]短い開発期間の後、「DYA|インフラストラクチャ - ITの資金調達のためのアーキテクチャ」というタイトルの（オランダ語の）書籍で説明されました。^[7]

2009年には、語彙と汎用パターンがオンラインリポジトリで公開されました。当初は独立したURLで公開されていましたが、後にSogeti Netherlandsのウェブサイトのサブドメインで公開されました。^[8] LinkedInグループ^[9]も作成されました。

この手法の開発は2012年半ばまでソジェティで続けられ、その後はBiZZdesignの支援を受けて開発が続けられ、その時点で手法の名前がオープン・インフラストラクチャ・アーキテクチャ手法（OIAm）に変更されました。^{[10]リポジトリは}オープン・インフラストラクチャ・アーキテクチャ手法（OIAr）という名前で継続されています。

DYA|インフラストラクチャは、インフラストラクチャ アーキテクトのサポートを目的とした方法です。ビジネスの俊敏性、アーキテクチャの有効性、管理と拡張が可能なインフラストラクチャ ランドスケープをあらゆる組織に提供します。DYA インフラストラクチャは、相互にサポートし合う 3 つの要素を提供します。

1. インフラストラクチャアーキテクチャを建築プロセスの不可欠な部分として明確に説明し、それが建築原則の実施にどのように役立つかを説明しています。2つの焦点は、インフラストラクチャ施設への機能的なアプローチの定義と、適切な品質属性を選択して操作する方法です。
2. ビルディング ブロック モデル (インフラストラクチャのアーキテクチャ メタモデル)...
   1. 論理的かつモジュール化されたインフラストラクチャ施設を作成し、記述する
   2. 既存のインフラストラクチャ「ランドスケープ」のカテゴリ別および機能別のインベントリを維持します
   3. リファレンスアーキテクチャ、影響分析、プロジェクト開始アーキテクチャなどの建築製品を構造化および構築します。
3. インフラストラクチャ アーキテクチャをスムーズに開始するためのベスト プラクティスと、インフラストラクチャ アーキテクチャを機能させる重要なアーキテクチャ成果物を作成するためのガイドライン

さまざまな実装戦略の概要、プロジェクト開始アーキテクチャの拡張方法の説明、リファレンス アーキテクチャ、製品カタログ、サービス カタログなどのさまざまな製品の重要性についても説明します。

これら 3 つの主な要素の他に、DYA|Infrastructure は、インフラストラクチャ アーキテクチャによってセキュリティ、プロジェクト管理、テスト管理、および生産をどのように改善できるかについてのガイダンスも提供します。

1972年、ゲリット・ブラウ^{[11]は、コンピュータ設計を}アーキテクチャ、実装、実現という分離可能な領域として考える方法を説明しました。しかし、ブラウが導入した概念は、メインフレームアーキテクチャだけでなく、 ITアーキテクチャ（そしておそらくすべての形式のアーキテクチャ）にも当てはまります。DYA|インフラストラクチャを使用すると、ブラウが提唱した3つの領域を簡単に認識できます。

• アーキテクチャ : Blaauw は、「システムのアーキテクチャは、ユーザーに対するシステムの機能的な外観、つまりその現象として定義できる」と主張しました。^[11]インフラストラクチャ施設のアーキテクチャについて議論する場合、私たちは本質的なこと、つまりそれが何をするのかということに限定します。この目的のために、私たちは施設を、基本的なアトミック インフラストラクチャ機能の集合であるインフラストラクチャ サービスと見なします。この点でアトミック インフラストラクチャ機能とは、少なくともアーキテクチャの目的のためには意味のある形でサブ機能に細分化できない論理的なインフラストラクチャ機能を意味します。

インフラストラクチャ機能が一般的な用語で説明されている場合、技術的な実装は別として、ほとんどの組織で同じに見えます。同様に、インフラストラクチャ サービスが基本的なインフラストラクチャ機能から構成されている場合、組織間でも同じに見えます。そして、これはまさに Blaauw の定義によると、アーキテクチャ レベルで期待されるものです。

• 実装 : Blaauw は、「実装はアーキテクチャを実行する論理構造です。アーキテクチャが何が起こるかを説明するのに対し、実装はそれがどのように起こるかを説明します。」と主張しました。^[11]どのような組織でも、インフラストラクチャ サービスは 1 つの組織固有のコンテキスト、または複数のコンテキスト内で提供する必要があります。これらのコンテキストは、インフラストラクチャ サービスの提供方法に影響します。たとえば、首都のオフィスにある国防省の PC は、戦場の装甲兵員輸送車の後部にある PC とは見た目が異なります。これは、戦場というコンテキストがインフラストラクチャ施設に課す要件とオフィスというコンテキストが異なるためです。

したがって、インフラストラクチャ サービスを実装するということは、次のことを意味します。

• • サービスが動作する必要があるコンテキストとその要件を特定する
  • これらのコンテキストでサービスの一部であるインフラストラクチャ機能を見つける
  • 特定された要件を考慮できる詳細レベルで指定する

実装レベルでは、インフラストラクチャ サービスと機能は汎用性を維持できます。特定の製品や技術標準を提案する必要はありません (ただし、これは可能です)。ただし、コンテキストの影響により、サービスと機能は組織固有になることがよくあります。前述のインフラストラクチャ アーキテクチャの定義では、Blaauw の「アーキテクチャ」と「実装」の両方がインフラストラクチャ アーキテクトの対象になることに注意してください。

• 実現 : Blaauw は、「論理設計を具体化する物理構造は実現と呼ばれます。ここでは、コンポーネントの選択、割り当て、配置、接続の「どれ」と「どこ」は、論理構造の「方法」とは別に考えられます。」と主張しました。^[11]インフラストラクチャ サービスの実現は、インフラストラクチャ設計者とエンジニアの分野です。実装から実現可能で保守可能な施設 (両方のコスト面を含む) を作成するのは彼らの責任です。このフェーズでは、インフラストラクチャ設計が作成され、施設が実際に構築されます。

ビジネス、情報、インフラストラクチャ アーキテクチャには共通の目標があります。それは、組織の業務を最適にサポートすることです。これは、3 つのアーキテクチャ分野からの入力とフィードバックがなければ不可能です。アーキテクチャ プロセス内で効果的に機能し、同時に十分な応答性を持つためには、各分野がそれぞれの専門分野を強調するダイナミクスと構造に従う必要があります。これはインフラストラクチャ アーキテクチャにも当てはまります。インフラストラクチャ アーキテクチャは、インフラストラクチャ ドメイン内で使用する用語を明確にすることで、その役割を簡単に認識できるようにする必要があります。これを行う最も簡単な方法は、インフラストラクチャ ソリューションを論理的かつ機能的な用語で説明することです。DYA|Infrastructure は、ソリューションの「機能」を一連の品質属性で定義します。品質属性は、3 つのアーキテクチャ分野間でアーキテクチャ プロセスを調和させる上でも重要な役割を果たします。なぜなら、基盤となる (技術的な) 構造に関係なく、品質属性はドメイン間で調整でき、ソリューション全体で使用できるからです。同時に、品質属性は、それぞれの専門分野内でソリューションのエンジニアリング、作成、テストにも入力を提供します。そのため、品質属性はインフラストラクチャ アーキテクチャのさまざまなフェーズとアクティビティで繰り返し登場するテーマであり、品質属性を慎重に選択して定義することが非常に重要です。少なくとも、品質属性はインフラストラクチャ ソリューションの独自の固有の品質を示すものでなければなりません。

建築分野は、建築プロセス中、必要に応じて妥協することなく互いに調整できなければなりません。各分野は、貢献できることを明確にし、自らの限界を示す必要があります。要望と要件の全範囲が常に満たされるとは限りません。特に、それらが (たとえわずかでも) 互いに矛盾する場合はなおさらです。いずれかの分野が最終的な結果を指示したい、または指示する必要がある場合は、その分野は建築プロセスから適切な指示を受ける必要があります。その指示は特定の専門分野に関連したものでなければならないことに留意してください。建築プロセスは、望ましいソリューションの方向性に最も現実的で適切な品質属性を選択します。この一連の品質属性は、各分野がトータル ソリューションのそれぞれの部分で個別に作業するための命令と見なすことができます。品質属性により、結果として得られるソリューションが孤立して開発されるのではなく、完全なアーキテクチャ フレームワーク内で一貫性が保たれることが保証されます。品質属性は、提供された結果をチェックして報告する方法も提供します。

各分野が目的を異にする議論をしないようにするには、各分野がアーキテクチャ プロセスにもたらす品質属性について明確な合意が必要です。これらは、アーキテクチャ プロセス内での定義のさらなる調整と調和の基盤として機能する必要があります。インフラストラクチャ アーキテクチャは、ビジネス アーキテクチャと情報アーキテクチャの特定の品質属性に加えて、独自の品質属性のセットを提供します。

品質特性とは別に、ソリューションの潜在的な方向性に影響を与える 2 つの大きな制約があります。それはコストと時間です。これらの制約は外部 (通常は組織) によって課され、あらゆる形式のアーキテクチャに影響します。時間とお金は一般に、ソリューションの規模と品質、ひいては実現可能性を決定する最も重要な要素です。多くの場合、時間とお金の制約が厳しすぎるため、現実的なソリューションを生み出すには、いくつかの品質特性に異なる重み付けをする必要があります。その結果、アーキテクチャ プロセスは時折、当然ながら利害関係者間の議論に変わり、時間とお金の制限内で組織のすべての利益を最適に満たすソリューションが生まれます。

品質属性は、その性質上抽象的です。品質属性は、どのようにかは示しますが、何を示すものではありません。アーキテクチャ プロセスでは、ある分野の品質属性と別の分野の同等の品質属性との関係が識別されます。これにより、ある領域での選択が他の領域のソリューションにどのように影響するかを簡単に識別できます。これが積極的に行われ、より多くの品質属性を調整できるほど、プロセスはより建設的になります。この調和プロセスでは、「類似の」品質属性は互いに簡単に追跡できますが、他の品質属性は特定の分野の独自性を強調する可能性がはるかに高くなります。ただし、適切に定義および説明されている限り、ある分野は通常、他の分野の品質属性の中にその特性を認識できます。

インフラストラクチャ機能をユーティリティとして構築するという目的を念頭に置いて、インフラストラクチャ ソリューションの固有の品質を表す 3 つのカテゴリ (それぞれ 2 つの品質属性を持つ) があります。

• 柔軟性（適応性と拡張性）
• 信頼性（可用性と整合性）
• 保守性（管理性と説明責任）。

ここで定義される 6 つの品質属性は、インフラストラクチャ アプリケーションにのみ適用されるわけではありませんが、ユーティリティとしてのインフラストラクチャを構築するためのガイドラインとなります。

アーキテクチャ設計プロセスの参加者は、自分の専門分野における品質特性の重要性や、明示的な要件が他の分野に与える影響について、必ずしも十分に認識しているわけではありません。その場合、他の参加者は自分の領域に対する暗黙的または明示的な影響を説明する必要があります。たとえば、あるビジネス アーキテクチャ ソリューションでは、99.99% の可用性が必要です。インフラストラクチャは、可用性の点ではこの要件を満たすことができると回答しますが、スケーラビリティとコストの点では重大な影響が生じます。ビジネス アーキテクチャは、その観点から、指定された可用性の要件が依然として正当化されるかどうかを示すことが期待されます。分野が他の分野を無視して、純粋に独自の目標を達成するために、互いに品質特性と条件を押し付ける状況は避けなければなりません。これは完全に逆効果であり、アーキテクチャ プロセス自体を妨げるからです。1 つの分野内の品質関連の用語は、その分野のドメイン外では別の意味を持つことがよくあるか、まったく意味をなさないこともあります。

このインフラストラクチャ アーキテクチャ リポジトリには、さまざまなレベルとさまざまな角度からの構築モデルの形式で、アーキテクチャと設計のガイドラインが含まれています。これは、DYA|Infrastructure の最も重要なツールの 1 つであるビルディング ブロック モデルを使用して構築されています。ビルディング ブロック モデルについて最初に知っておくべきことは、これが主に分解ツールであるということです。つまり、インフラストラクチャ ランドスケープを論理的なディメンションとパーツに分解して、構造化された方法論的モデリング (構成) を可能にするために使用されます。これは、最初に周期表を定義し、その後、化学を秩序正しく実践するようなものです。

ビルディング ブロック モデルは、インフラストラクチャ ランドスケープを 5 つの方向から分析します。

• 作業エリア
• 環境
• ビルディングブロック
• 要素
• 品質特性

モデルによって課される分解順序は次のように記述できます。

• インフラストラクチャ ランドスケープは、複数の作業領域 (ストレージ、ネットワーク、サーバー、ミドルウェア、クライアント領域) で構成されます。
• 各作業領域内には、次のようないくつかの種類のインフラストラクチャ機能が存在します (ビルディング ブロック)。
  • ワーキングエリアストレージは集中保管施設を提供します。
  • ネットワークワーキングエリアでは、アクセスとデータ配信設備が提供され、
  • クライアント領域作業領域は、エンドユーザーへのインターフェースとして機能する PC、モバイル PC、プリンター、スキャナーなどの機能を提供します。

これらの機能 (ビルディング ブロック) は環境内に「存在」します。つまり、特定のビジネス コンテキストで使用され、このコンテキストによって決定される使用方法には特定の品質要件が要求されます。

クライアント領域作業領域内の環境の例としては、オフィス、キオスク、リモートなどがあります。各環境内では、品質要求はその環境に適した値を持つ品質属性によって示されます。また、これらの値は、その品質属性に関連するクラス、規定、および/または順列に対応します。

アーキテクチャ プロセスは、特定の環境のビルディング ブロックに適用され、その環境のビルディング ブロックに普遍的な標準を指定します。これらの標準 (技術コンポーネント) は、ビルディング ブロック モデルの要素です。

• 
  DYA インフラストラクチャ モデリング (理想的なフロー).png
• 
  DYA インフラストラクチャ モデリングの前提条件.png
• 
  DYA インフラストラクチャ オントロジー.png
• 
  DYA インフラストラクチャ問題解決サポート.jpg
• 
  DYA インフラストラクチャ プロジェクト ガイダンス.jpg

• ダイナミックな企業
• 動的エンタープライズモデリング (DEM)
• オープンインフラストラクチャアーキテクチャ方式

この編集時点で、この記事は「dya-knowledge.sogeti.nl」のコンテンツを使用しています。このコンテンツはCreative Commons Attribution-ShareAlike 3.0 Unported Licenseの下で再利用を許可する形でライセンスされていますが、 GFDLの下では許可されていません。関連するすべての条件に従う必要があります。

Wikimedia Commons には、DYA フレームワークに関連するメディアがあります。

• dya.infoの DYA
• DYA インフラストラクチャ リポジトリ