エンタープライズアーキテクチャー

 

enterprisearchitecture_smallアジャイル・エンタープライズアーキテクチャーのプロセスブレード(未翻訳)は、ディシプリンド・アジャイル・EAチームがどう取り組むのか、その概要を示している。アジャイル・エンタープライズアーキテクチャーは、柔軟性があり、容易に拡張でき、組織の基礎となる機構とプロセスの集合体として容易に進化させることができる。アジャイル・エンタープライズアーキテクチャーの活動とは、協働的であり、進化するための探求であり、そして状況に応じた組織のアーキテクチャーエコシステムのあるべき姿をモデル化することである。その意味合いは、エンタープライズアーキテクト達が協働により柔軟に取り組まなければならず、ITデリバリーチームがエンタープライズアーキテクト達と緊密に協力しなければならないということである。

本稿を構成するトピックは以下のとおり。

 

なぜエンタープライズアーキテクチャーなのか?

エンタープライズアーキテクチャーは、ディシプリンド・アジャイルの手法で実施するならば、アジャイル・ソフトウェア・デリバリーの重要な鍵となる。これにはいくつかの根拠がある。

  1. 共通のアーキテクチャによって、アジャイルチームは価値創造へのフォーカスが可能になる
    共通のエンタープライズアーキテクチャーによって、デリバリーチーム間での再利用が可能になる。アジャイルチームが高品質な資産(マイクロサービス、レガシーデータソース、フレームワークなど)を再利用できるようになれば、彼らは利害関係者にとっての新たな価値の創造にフォーカスでき、既存のインフラストラクチャーの新バージョンを再発明することはなくなる。
  2. 共通の技術的ガイダンスによって、一貫性が向上する
    効果的な共通の慣習にチームが従うことで、結果として品質が向上する。これによって彼らがこれまで気づかなかった資産(具体的には既存のソースコード)について学習し、必要に応じてそれらの資産を発展させることが容易になる。また、一貫性の向上によって、人々はチーム間を移動しやすくなる。なぜなら、新しいチームが何をしているのかを人々が迅速に把握し、そのチームのメンバーとスキルを共有することが容易になるからだ。
  3. アジャイルアーキテクチャーによって、分散化が可能になる
    ソリューションが疎結合で、凝集度の高いコンポーネントで構成されているならば、開発作業をより小規模なチームの間で分散させるのは容易である。このことは全体的なリスクと組織の複雑さを軽減し、デリバリーの時間を短縮する。
  4. 共通のインフラストラクチャーによって、継続的なデリバリーが可能になる
    ITデリバリーチームに、デプロイするための共通の技術的インフラストラクチャーがあるならば、デプロイはより容易になる。 デプロイが容易になればなるほど、デプロイの頻度は高くなる。
  5. エンタープライズアーキテクチャーによって、アジャイルをスケールする
    エンタープライズアーキテクチャーに対するディシプリンド・アジャイルのアプローチによって、組織はIT部門間全体に渡って「水平に」アジャイル戦略をスケールすることが可能になる。

 

エンタープライズアーキテクチャーのプロセス

アーキテクチャー要件をエピックとして明文化したり、「アーキテクチャー滑走路」を事前に構築したりといった、単一のアプローチを定める選択もあるだろう。けれども、Disciplined Agile Delivery(DAD)のフレームワークは、適応型・状況対応型の戦略を促進する。DADはこれを、ゴール駆動のアプローチによって行う。そのアプローチは、考慮する必要があるプロセス要因、各プロセス要因を扱うための技法や戦略の範囲、そして各技法の長所と短所を示している。この段落では、エンタープライズアーキテクチャーのプロセスブレードについてのゴール図を提示し、そのプロセス要因を概観する。

次の図は、ディシプリンド・エンタープライズアーキテクチャーに関する潜在的な活動の概要を示している。

goal-it-enterprise-architecture-ja

 

 

エンタープライズアーキテクチャーについて考慮する必要があるプロセス要因は次のとおり。

    1. 利害関係者を支援する
      エンタープライズアーキテクトは、ビジネスやITの利害関係者と定期的に連携することで、彼らのニーズを理解し、組織のビジョンを構築する手助けをする。
    2. デリバリーチームを支援する
      エンタープライズアーキテクトは、ITデリバリーチームと定期的に連携する(理想的にはITデリバリーチームのアクティブメンバーになる)。彼らはビジネスとテクノロジーのロードマップをチームに指導し、再利用可能な資産や技術的負債を見定めるためにチームを手助けし、そして彼らのスキルと知識をチームメンバーに伝達するだろう。
    3. 技術的な依存関係をネゴシエートする
      好むと好まざるとにかかわらず、私達が作成するソリューションの間には依存関係がある。例えば、あるシステムが、別のシステムが提供するWebサービスを起動したりAPIを呼び出したりすると、そのシステムに依存することになる。エンタープライズアーキテクトは、しばしば他のチームとこれらの依存関係をネゴシエートする必要があることに気づくだろう。エンタープライズアーキテクトとしての役割のハイレベルか、時にはデリバリーチームのアーキテクチャーオーナーとしての役割の詳細レベルで。
    4. アーキテクチャーの展望を探究する
      組織というのは複雑であり、結果として様々な視点から理解しなければならない。それは、単に「アーキテクチャーエピック」をインデックスカードの束に書くということではない。
    5. アーキテクチャーフレームワークを適合させる
      エンタープライズアーキテクチャーチームは、既存のエンタープライズアーキテクチャーフレームワークを採用し、適合させるだろう。これらのフレームワークが一般的に示唆するのは、作成の成果物やその技術に関する多くの視点である。
    6. エンタープライズアーキテクチャーを発展させる
      エンタープライズアーキテクトは、お互いに、そして利害関係者とも、様々な方法で協力する。彼らは、アーキテクチャーのエンビジョニング/モデリング・セッションや、学習したことを互いに共有する定期的なミーティングを開催することもできる。彼らはしばしば共同で、またはITデリバリーチームと協力して、新技術を調査したりアーキテクチャー戦略の候補を特定したりする。
    7. ロードマップを発展させる
      エンタープライズアーキテクチャーへの尽力の重要な成果として、テクノロジー戦略やアーキテクチャー戦略を記述した、1つまたは複数のロードマップがある。アジャイルな組織では、このロードマップ作りを、ローリングウェーブのアプローチで定期的にロードマップを更新して行う。
    8. エンタープライズアーキテクチャーを明文化する
      エンタープライズアーキテクトが彼らの仕事を明文化するには、大きく2通りのやり方がある。それは、資料を作るか、実施例/実行可能例を示すかである。ハイレベルなモデルは資料として適しているけれども、時には詳細な資料も必要になることがある。一般に、資料よりも実行可能な成果物(実行可能な参照アーキテクチャーやアーキテクチャー滑走路など)をデリバリーチームは優先する。
    9. アーキテクチャーを統制(govern)する
      組織内におけるアーキテクチャーの活動は、軽量で共同的なやり方で統制すべきである。これは、ITガバナンスチームだけでなく、エンタープライズアーキテクトにとっても重要な活動である。

 

他のITチームとのワークフロー

次の図は、ディシプリンド・アジャイルなエンタープライズアーキテクチャーの活動に関する、主要なワークフローの概要を示している。なお、この図はフィードバックを含んでいることに注意されたい。例えば、「エンタープライズアーキテクチャー」から「リユーズエンジニアリング」への、「技術ロードマップとガイダンス」のフローには、リユーズエンジニアからエンタープライズアーキテクトへのフィードバックループがある。また、ワークフローには必ずしも成果物があるとは限らないことに注意されたい。例えば、エンタープライズアーキテクトが行うガイダンスのいくつかは、利害関係者とのディスカッションかも知れない。

goal-it-enterprise-architecture-workflow-ja

次の表は、上図に示すワークフローをまとめたものである。

プロセスブレード プロセスブレードの概要 EAについてのワークフロー
ITデリバリー ディシプリンド・アジャイルの流儀でソリューションを開発する方法を扱う。これは、DADフレームワークがサポートする4つのライフサイクル(基本/アジャイル、アドバンスド/リーン、継続的デリバリー、および探索的)に加えて、プログラム管理ブレードを含んでいる(実際には、大規模チームは1つ以上のライフサイクルに従う)。 エンタープライズアーキテクチャーは、ITデリバリーチームにコーチングとメンタリングによるガイダンスを行い、アーキテクチャーの課題について、技術ロードマップや開発ガイドライン(コーディング規約、セキュリティ規約、データベースガイドラインなど)を提供する。
継続的改善(未翻訳) 次に示す取り組みを支援する方法を扱う。チーム間のプロセスと組織構造の改善(軽量、共同的なやり方で)、チーム内での改善の実験、およびIT部門のプロセス改善。 継続的改善の活動は、エンタープライズアーキテクチャーの取り組みを改善し得る提案を行う。 同様に、EAチームが洞察を得たならば組織の別の人と共有する。
データ管理(未翻訳) 次に示す取り組みを実施する方法を扱う。データ品質の向上、マスターデータやテストデータなどのデータ資産の充実、および組織内のデータ活動の統制。 エンタープライズアーキテクチャーは、データ管理活動のガイダンスを行う。データソース生成およびデータ活動に関するオペレーショナルインテリジェンスをEAチームが活用することで、長期的計画を支援するだろう。
ITガバナンス(未翻訳) 次に示す取り組みの戦略を扱う。様々なガバナンスの視点の統合、メトリクスの定義、測定の実施、測定のモニタリングとレポーティング、ガイダンスの作成と明文化、役割と責務の定義、組織内のナレッジの共有、ITリスクの管理、および様々なガバナンスの尽力(EAガバナンスを含む)の調整 ITガバナンスの尽力は、EAチームに対してガイダンスを提供することになるだろう。
オペレーション 次に示す取り組みを実施する方法を扱う。システムの運用、ITインフラストラクチャーの発展、オペレーショナルエコシステムでの変化の管理、災害の緩和、ITオペレーションの統制。 エンタープライズアーキテクチャーは、技術ロードマップとガイダンスをオペレーションに提供し、ITインフラストラクチャーを発展させるために全体的な組織戦略を反映できるようにする。オペレーショナルインテリジェンスをEAチームが活用することで、様々なアーキテクチャー戦略の有効性について洞察を得る。
ポートフォリオ管理
(未翻訳)
次に示す取り組みを実施する方法を扱う。ITの挑戦が支える新たなビジネス価値の確認、それらの新たな挑戦をより詳細に理解するための探究、挑戦の優先順位づけ、挑戦の開始、ベンダーの管理、およびITポートフォリオの統制。 エンタープライズアーキテクチャーは、技術ロードマップをポートフォリオ管理に提供する。そのロードマップは、ITおよび優先順位の決定が支える新たなビジネス価値を確認するための情報として使用する。
プロダクト管理
(未翻訳)
次に示す取り組みのプロダクト管理戦略を扱う。プロダクトへの機能の割当、プロダクトのビジネスビジョンの展開、機能の依存関係の管理、およびプロダクトラインのマーケティング エンタープライズアーキテクチャーは、技術ロードマップをプロダクト管理に提供する。 それは、プロダクトのビジョンを発展させたり、プロダクトの新たな機能を特定したりするための情報になる。プロダクト管理は、ビジネスロードマップと利害関係者による優先順位をエンタープライズアーキテクチャーに提供する。それは、エンタープライズアーキテクチャーを発展させるための情報として利用する。
プログラム 管理
(未翻訳)
次に示す取り組みの戦略を扱う。大規模なプロダクト/プロジェクトチームの管理、サブチーム間での要求の割当、サブチーム間の依存関係の管理、各サブチームの調整、およびプログラムの統制。 エンタープライズアーキテクチャーは、大規模ITデリバリーチーム(プログラム)に対してガイダンスを行う。アーキテクチャーの課題についてのコーチングやメンタリング、技術ロードマップの提供、および開発ガイドライン(コーディング規約、セキュリティ規約、データベースガイドラインなど)の提供という形で。
リリース管理(未翻訳) 次に示す取り組みの戦略を扱う。ITリリーススケジュールの計画、ソリューションのリリースの調整、リリースインフラストラクチャーの管理、デリバリーチームの支援、およびリリース管理の取り組みの統制。 エンタープライズアーキテクチャーは、技術ロードマップとガイダンスをリリース管理に提供し、その計画が組織全体の方向性を反映できるようにする。オペレーショナルインテリジェンスをEAチームが活用することで、現在のアーキテクチャー戦略のリリース全体への影響について洞察を得る。
リユーズ エンジニアリング(未翻訳) 次の取り組みを実施する方法を扱う。再利用可能な資産を特定して取得、再利用できるよう資産を公開、資産を再利用する際のデリバリーチームの支援、長期的な資産の発展、および再利用の取り組みの統制。 エンタープライズアーキテクチャーは、技術ロードマップとガイダンスを再利用管理に提供し、再利用可能な資産をよりうまく特定できるようにする。リユーズインテリジェンスをEAチームが活用することで、技術的負債の削減努力をどこにフォーカスするかについて洞察を得る。
サポート 次に示す取り組みを実施する方法を扱う。ITサポート戦略の採用、インシデントのエスカレーション、インシデントへの効果的な対処、およびITサポートの取り組みの統制。 エンタープライズアーキテクチャーは、技術ロードマップとガイダンスをサポートチームに提供し、ITエコシステム全体とその方向性をよりよく理解できるようにする。オペレーショナルインテリジェンスをEAチームが活用することで、作成中の様々なソリューションのサポータビリティについて洞察を得る。

これらのプロセスブレードに関する各活動は、非常に関連性が高いことが多い。例えば、ある組織では、エンタープライズアーキテクチャーと再利用管理に関する活動を1つのグループが遂行する。他の組織では、プロダクト管理活動の一部をポートフォリオ管理チームが行い、一部をエンタープライズアーキテクチャーチームが行う。ある組織では、プロセスブレードごとに別々のグループを選択することもある。そしてもちろん、様々なチームが互いの取り組み方を学ぶにつれ、組織構造は時間をかけて進化する。どの組織も同じではない。

 

チーム内のワークフロー

ディシプリンドアジャイル・エンタープライズアーキテクチャーチーム内のワークフローを次の図に表す。

goal-enterprisearchitecture-team-workflow

これには4つの主要な活動がある。

  1. 初期のアーキテクチャーを構想する
    エンタープライズアーキテクトは、初期のエンタープライズアーキテクチャーのハイレベルなモデルを考え出すのに数日間を費やす。これは、フェイス・トゥ・フェイスによる初期のアーキテクチャー構想セッションであり、そのスコープは単一のITソリューションではなく組織全体である。理想的には、コミュニケーションと共同的モデリングを合理化するために、アジャイルモデリングルームでこのセッションを行うべきである。そのような部屋はホワイトボードをたくさん使えるだけの広さがあり、チームは複数のモデルを並行して取り組むことができる(各モデル用の場所が壁面にある)。このセッションの主な目的は、EAチームが共通理解(とにかくエンタープライズアーキテクチャーの現状をハイレベルで)、およびビジョン(チームがどのように進化するか)を持つことである。副次的な成果として、エンタープライズアーキテクトが時間をかけて進化させるようなこと、(もしかすると)お互いが最初に出会ったり、チームメンバー間のきずなを作ったりするといったことがある。この活動で課題になるのは、アジャイルモデリングルームを確保すること(既存の部屋を改造するか、そのような部屋を確保できなければ生産性の低下を受け入れるか)、および適切な人々を同時に集めることである。
  2. ビジネスの利害関係者と協力する
    エンタープライズアーキテクトは定期的に利害関係者と連携して、彼らのニーズを理解し、将来のビジョンを描く。そして、テクノロジーの可能性や制約を彼らに教える手助けをする。 このコラボレーションは、ワーキングセッション、プレゼンテーション、または1対1の会話の形式で行う。これらのセッションは必要に応じて実施する。しかし、利害関係者は非常に忙しい人々なので、なかなか会えないことがある。
  3. IT利害関係者と協力する
    ディシプリンドアジャイルEAは、自分の時間の大部分(通常は80から90%)を、ITデリバリーチームのメンバーとして働くことに費やす。これによって彼らは、自分の知識・ビジョン・スキルを、実用的・実践的なやり方でチームにもたらす。ディシプリンドアジャイルデリバリー(DAD)チームでは、彼らがアーキテクチャーオーナー(AO)の役割を担うことがよくある。エンタープライズアーキテクトは、他のIT利害関係者(オペレーションエンジニア、サポートスタッフ、データ管理(未翻訳)チームなどを含む)とも連携して、彼らのニーズを理解する。
  4. アーキテクチャー資産を発展させる
    エンタープライズアーキテクチャーチーム、または少なくとも現在応じられるチームの一部は、定期的に会合して、彼らが学習したことに基づいてエンタープライズアーキテクチャーの資産を発展させる。よくあるパターンは、チームが毎週金曜日の午後に2時間のミーティングを行い、その週にデリバリーチームの作業や様々な利害関係者との作業から学習したことを議論する。ミーティングの結果、エンタープライズアーキテクトの何名かは、EAの既存の成果物を更新するためのアクションアイテムを引き取るかも知れない。これらの成果物は、EAモデル、参照アーキテクチャー、開発ガイドライン、ホワイトペーパーなどを含む。新たなプラットフォームの導入や他の組織との合併など、新たに主要トピックが生じたときは、EAがアジャイルモデリングセッションをスケジュールしてそのトピックを探究するかも知れない。

 

関連記事

 

オリジナル:Eenterprise Architecture
http://www.disciplinedagiledelivery.com/agility-at-scale/enterprise-architecture/

 (翻訳 大隈登)

Pocket