nav-portfolio-ent-architect

人みな我が勝つゆえんの形を知るも、我が勝を制するゆえんの形を知ることなし。

- 孫子

 

エンタープライズアーキテクトの概要

企業規模のシステムにおいては、戦略的に技術を見通せなければ大きなシステムの再設計が必要になり、経済的結果が悪化する可能性がある。現在および近い未来のフィーチャーのニーズをサポートするため、一定量の意図的なアーキテクチャー滑走路をシステムに組込むことは、企業システムに役に立つ。また、アーキテクチャーガバナンスは、企業のプロダクトやサービスを横断する共通のユーザビリティやシステム動作の構造が作られるため、有益である。プログラムレベルでは、我々はこのガイダンスを提供するシステムアーキテクトの役割に注目した。

ポートフォリオレベルでは、合併や買収、基本となる技術の変化、新たな基準、競争力の変化などのビジネス活動によって、企業はアジャイルプログラムの範囲から外れた方向に向けられてしまう。SAFeでは、複数のプログラムにまたがって仕事をし、企業の成果を最適化できる戦略的な方向性を提供するために必要な知識を持つ責任者として、エンタープライズアーキテクト(またはCTOやアーキテクチャーチームなど)を導入した。この戦略には、開発と納品の技術スタック向けの推薦、プログラム間のシステム協力とAPI、ホスティング戦略などの側面が含まれる。エンタープライズアーキテクトがインクリメンタルな実装を促進しながらも、チームの現実と確実に連携していれば、これらの戦略が最も効果的になる。

詳細

役割の概要説明

エンタープライズアーキテクトはビジネス利害関係者やシステムアーキテクトと一緒に作業し、複数のプログラムにまたがる全般的な技術実装を進める。エンタープライズアーキテクトは継続的なフィードバックに基づいて、適応型設計やエンジニアリングプラクティスを促進し、1つの共通の技術ビジョンを中心にプログラム間、チーム間の協調体制を築く。

責務

SAFeのコンテキストでは、エンタープライズアーキテクトは主に以下の責務に注力する。

  • 企業のソリューションと開発取り組みに関する高いレベルの総合的なビジョンを維持する。
  • アーキテクチャーエピックを介し、予算をサポートする重要な取り組みの定義を支援する。
  • 企業のアーキテクチャー滑走路の構築と維持のための戦略に関与する。
  • 戦略テーマやアーキテクチャーに関する重要なビジネス推進要因を理解し、システムアーキテクトに伝達する。技術者以外の利害関係者に技術面の決定を伝達する。
  • アーキテクチャーエピックカンバンを促進し、必要に応じてエピックの分析に参加する。
  • 共通のモデリング、設計、コーディングのプラクティスに影響を与える。
  • 企業全体に応用できる革新的なアイディアや技術を収集し、促進し、分析する。
  • アイディアやコンポーネントや検証されたパターンの再利用を促進する。
  • 必要に応じて以下をソリューション間で同期する。
    • システム、データセキュリティ、品質
    • 本番インフラ
    • システムからシステムへのUXガバナンス
    • 拡張性、性能などの非機能要求(NFRs)

企業アーキテクチャー戦略

組織的な変更を抱擁するという企業能力は重要な競争優位性であり、企業アーキテクチャー戦略はその主要な要素の1つである。図1にこの戦略の要素を示す。

図1.企業アーキテクチャー戦略の5つの要素

技術の選択と利用。現在の予算にもっとも合った技術を選択することは重要な戦略要素の1つである。そのための作業には、調査やプロトタイプ作成、適用可能性と範囲に関する理解、革新的な新技術の成熟度の評価が含まれる。

システムアーキテクチャー戦略。エンタープライズアーキテクトはシステムアーキテクトと密に協力し、個々のプログラムやプロダクトの戦略が企業目標に沿ったものになるよう気を配る。ローカルな問題を解決するために現れたソリューションは、戦略と調和したものでなければならない。そうでない場合には、決定は明示的に行わなければならない。そうすればそれが企業戦略に影響を及ぼす可能性がある。

開発と開発インフラ戦略。機能を適切に果たしている間は開発と開発インフラは目立たない。しかしながら、インフラの構築と維持の戦略は重要な課題であり、システムアーキテクトの責務と重なっている。これには、設定パターンの再利用、共通の物理インフラ、リリース列車(特にシステムチーム)間の知識共有が含まれる。また、一部の開発と開発インフラは内部ITシステムと重なる場合があり、エンタープライズアーキテクトはこれに関して方向性を示すこともできる。

プログラム間の協力。チームやプログラムによって、異なるアーキテクチャー作業が必要になる。したがって、可能であれば共通の技術、共通の設計プラクティス、共通のインフラを使用するようにしておくと有益である。しかし、プログラムに十分な自由度を与えるのも大事である。そうしないと、革新はほとんど起きない。そのため、共同設計ワークショップ、設計の実践コミュニティ等を介して、ART間で共通アーキテクチャーと可変アーキテクチャーを積極的に共有しなければならない。

実装戦略。効果的でアジャイルなインクリメンタル実装戦略は、言い表せないほど重要である。アーキテクチャー滑走路にビジネスエピックのための技術な土台を構築するのは、継続的な技術の学習と迅速なフィードバックに基づくインクリメンタルなプロセスでなければならない。そして、アーキテクチャーとビジネス機能が時とともに同期しながら成長していく。これは、必要に応じてリファクタリングしたり、現実的であれば複数の設計の選択肢を持っておくような、アジャイルチームやプログラムの能力によって支えられる。このいくらかは、抽象化や汎化の利用を通じて実現される。そうすることで、早すぎる段階で具体的な詳細事項に縛られることなく、将来のビジネスニーズのためのアーキテクチャーの柔軟性を維持できる。

人の尊重と現場改善

「行ってみる」(現場、実際の場所)のはリーンの概念である。これによって、人々が仮定ではなく事実に基づいて仕事をするという健全な環境が作られる。日常的な開発作業から「1(または2)ステップを削除!」することに取り組むエンタープライズアーキテクトにとって、これは特に重要である。各アジャイルリリース列車や列車のシステムアーキテクトと個人的な付き合いを維持する、現在の企業全体の取り組みについてのフィードバックを得る、プログラムレベルの設計CoPに参加する、重要な再設計や基盤作業が進行しているときはデモに参加するなどの活動は、エンタープライズアーキテクトに役立つ。開発者やテスターたちは、自分たちが現在抱えている課題やコンテキストをよく理解している人が促進している戦略であればより深く信頼できる。同様に、エンタープライズアーキテクトは、現在のコンテキストを完全に示してくれるチームをより深く信頼できる。


Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011. 第20章 (邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)

[2] Larman, Craig & Vodde, Bas. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, 2010. 第 8章。

 Last update: 25, July 2014

This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.