ITABoK V2では、冒頭で下記のように、エンゲージメント・モデル捉え方を述べています。
ITABoKのエンゲージメント・モデルは、人材と結果に基づいており既存のあらゆるエンタープライズ・アーキテクチャのフレークワークと共に機能します。もし他のフレームワークが選択されていない場合には、プロジェクト、もしくは、エンタープライズレベルで使用できるタスク、ロール、アーティファクトの簡略化されたフレームワークも対象に含まれています。しかし、 ITABoKの目的は既存のフレームワークを置き換える事やそれらを超える事ではなく、より一貫性のある専門性重視の方法でそれらを関連付ける事です。(ITABoK p.386)上記のように少し回りくどい表現となっていますが、「ITABoKのエンゲージメント・モデルはフレームワークではなく、ITアーキテクトの振る舞いとフレームワークを関連付け、フレームワークと共に機能するものである」と要約できるかと思います。
さて、フレームワークでは無いということは、「エンゲージメント・モデル」とは何なのか、を考えていきたいと思います。ITABoK V2では、下記が述べられます。
エンゲージメントは以下について定義します。
⃝ 組織内のアーキテクトのロール
⃝ アーキテクトのプロセスとライフサイクル
⃝ 利用されるアーキテクチャのツール
⃝ アーキテクトのバリュー・プロポジション
⃝ アーキテクトチームの配置と、ステークホルダーとの相互作用
（ITABoK p.386）エンゲージメントの定義を確認することにより、ITアーキテクトのエンゲージメント活動における振る舞い方の理解が深まることが考えられます。
注記【「エンゲージ」という用語については、日本語訳しにくく、今一つ腹落ちしない言葉だと言う方もおられるかと思います。以下の記事を参照してみてください】
では、最初にある「アーキテクトのロール（役割）」の記述を見ていきましょう。
エンゲージメント・モデルに取り組む際、それが通常どのように行われるのかを把握するのは良い事です。大半の部分で、業界の一般的なロールは企業の外で定義されます。会計士、弁護士、金融やビジネスの人々のロールは十分に記述されており、それらを支える大規模なインフラストラクチャを持っています。しかし、アーキテクチャの場合はロールを定義するのは通常、企業内のHRやIT部門です。(ITABoK p.395)ここでは、一般的に専門職の役割については、企業の外で定義されているが、アーキテクトについての定義は企業内で定義され、専門職としての認知や位置づけが、明確ではないと言っているように思います。
そこでIasaでは、これを定義することで、ITアーキテクトの役割、責務を明確にしようと主張しています。
ロールの記述に関して、Iasaから職務記述書として発表されています。ITABoK Ｖ2では、ビジネス・アーキテクトからインフォメーション、インフラストラクチャ、ソフトウエア、ソリューション・アーキテクトとエンタープライズ・アーキテクトまでの６様の職務記述書が掲載されています（ITABoK p.398-p.409）
ここでは、責務や必要な教育や経験が具体的に記述されおり、ロールの定義が理解できるかと思います。
次に、プロセスとライフサイクルの定義です。
プロセスは、エンゲージメント・モデルを構築する際に考慮すべき重要な領域です。例として、アーキテクチャ活動はプロジェクトの正式な開始以前に良く発生します。プロジェクト・ポートフォリオのスケジュールの例で見たように、アーキテクトはプロジェクトの前と後の両方に関与し、全プロジェクトを通じてエンゲージメントを理解する必要があります。
(中略)
アーキテクトはプロジェクトに取り組みますが、プロジェクトを超えたテクノロジー戦略に対する責任を担っているといる事を覚えておいて下さい。これが意味する事は、アーキテクトの仕事がプロジェクト終了と同時に完了はしないという点です。(ITABoK p.388)ここで述べられている「プロジェクトを超えた」と言うキーワードがアーキテクトに求められている振る舞いのポイントかと考えます。
また、ライフサイクルについてのIasaのスタンスは、標準的なライフサイクルのフレームワークと共存していくこととしています。その上で、ライフサイクルの理解やそれぞれのフレームワークへの対応について述べています。(ITABoK p.410-p.418)次にツールに関してですが、V2では記述はなく、V3では、目次としては取り上げられ、今後記述予定であることが伺えます。https://iasaglobal.org/itabok3_0/tools-2/
ITアーキテクトのバリュー・プロポジションについての記述は、ITABoK V2においては、以下のようなIasaの考え方を記しています。
従来のITアーキテクチャのグループは、その価値を主にコスト削減の活動として見なしており、それ以外のアーキテクチャのフォーカスはエンジニアリング上の卓越性に置かれていました。Iasa のモデルは、従来のアーキテクチャのケイパビリティから作り出される価値を維持しながら、その範囲をはるかに超えてアーキテクチャの価値の概念を拡大しています。
(中略)
アーキテクトは自分の価値と進捗を継続的に再評価し、エンゲージメントのアプローチを再調整しながら変化するビジネスに位置付ける必要があります。（ITABoK P387）「従来の価値を維持しながら、その範囲を超えてアーキテクチャの価値の概念を拡大しています。」ということが、具体的には、V3のドラフトで「バリューモデル」のカテゴリーを設けて、10のトピックの記述が予定されています。確認してみてください。
最期の「アーキテクトチームの配置と、ステークホルダーとの相互作用」は、V2ではエンゲージメント・モデルの冒頭で以下の記述があり、プロジェクト成功のアーキテクトの配置の比率などが述べられています。
Iasaでは多くの種類の組織にインタビューを行い、成功するエンゲージメント・モデルに繋がる多くの共通する特徴を発見しました。その最初のものは、ITスタッフに対するアーキテクトの比率です。成功を報告している大半のアーキテクチャチームは、以下のパーセント比になっています。例えば、企業IT部門の場合、全ITスタッフに対して5％のアーキテクトの比率が最も成功を収めるものとして報告されています。チームの配置では、ある程度の複雑性を伴うプロジェクト単位にアーキテクト1人を配置する事が成功の鍵であると報告されています。(ITABoK p.386)
(注；この比率は欧米の企業のデータであり、日本での適用については議論を要します)いづれにしても、エンゲージメント・モデルのチャプターはV3で大幅に改定されます。
4つカテゴリー（Operating Model、Value Model 、People Model 、Implementing The Engagement Model）を新たに設定して、それぞれトピックを設けて述べています。
Iasa日本支部では、V3のドラフト版の2019年3月現在の英語版で日本語翻訳に着手しており、本年11月までには、少なくとも会員向けにα版をリリースする予定です。
尚、以下の図はエンゲージメント・モデルの概念を表すものです。これを解説できるものとして、ITABoK V3のエンゲージメント・モデルの章が充実していくことになります。
特に、中心に描かれているエンゲージメント・モデルの4フェーズ (①Plan ②Build ③Run ④Manage Value) については、ITABoK V2で唯一ともいえるプロセスモデルであり、その解説の充実も期待したいところです。
ドラフト版では記載のない部分も含め、Iasa日本支部でも、我々なりに議論を重ね、先行して共通認識し、エンゲージメント・モデルのあり方の理解を深めていくことも必要かと考えます。