1. アーキテクチャとは何か？
    1. システムの分け方と組み合わせ方のこと
      1. ミッションに従う
      2. 制約や環境を前提とする
      3. 複数の利害関係者の関心ごとを整合させる
    2. アーキテクチャの成果とは
      1. 構造とプロセスの決定
        1. 構造
          1. 機能がどのような要素に分解されるか
        2. プロセス
          1. それらの要素をどのように組み合わせるか
        3. 上記にリソースとスケジュールを加味すると、WBS(ガントチャート) になる
    3. エンタープライズ・アーキテクチャとは
      1. 企業システムを対象
        1. 利害関係者が多い
        2. 連携先システムが多い
        3. 急激に変化できない
        4. 現状維持が重要
        5. 様々なシステム
        6. 様々なルール
    4. なぜアーキテクチャを定義するのか
      1. アーキテクチャがすべてのスタート
        1. 構造とプロセスが明確でなければチームは動けない
        2. プロジェクトマネジメントはアーキテクチャを前提とした実行段階の営み
        3. 最初にすべてを固定的に決める必要はない
          1. 「選択肢を残す決定」はできる
          2. YNGNIの法則は今でも有効
          3. つくりすぎないくらいが適当
  2. どうやって選択したらよいのか？
    1. 選択の観点
      1. 様々な観点でバランスをとる作業
      2. 3つの観点
        1. ITサービス運営
          1. 「アプリケーションを作る」から「ITサービスを運営する」へ
          2. 利用者からのフィードバック
          3. 様々な人が関わる
          4. 終わることのない持続的な活動
          5. ITサービス運営モデル
          6. 構造、プロセス、機能、ITサービス、サービス、満足度
          7. 運用、業務、企画、開発
          8. より、「ITサービス運営」を意識したアーキテクチャ設計になっていく必要性がある
          9. 指標
        2. 品質
          1. IT/ソフトウェア品質特性
          2. 品質とはなにか？
          3. 多面的
          4. 8つの品質特性と31の副特性
          5. 経済産業省
          6. ソフトウェアメトリクス高度化プロジェクト
          7. 情報システム/ソフトウェアの品質メトリクスセット
          8. 技術選択においては、品質特性同士が打消し合う場合もある
          9. 安易な両立は避けるべき
          10. コストの観点では保守性が重要
          11. 性能効率性は、仮想化/クラウドいにより少し自由に
          12. 互換性はあらゆるシーンで重要
          13. エンタープライズでは、信頼性、セキュリティが重要
        3. 技術
          1. 共有と固有のバランス
          2. 共有された資源を最大限に活用
          3. 固有ドメインの特性を最大限に発揮
          4. プラットフォームとマイクロサービス
          5. プラットフォーム
          6. 共有資源の定義
          7. IaaS,PaaS,SaaS
          8. マイクロサービス
          9. サービスによってシステムを構成
          10. APIによって連携
          11. 独立した構造とプロセス
          12. 独自のライフサイクル
          13. 個別のドメインに従う
      3. 多面的に組み立てることが大事
        1. すべての要素に利害関係者がいることを把握
      4. アーキテクトの覚悟と責任
        1. 最大公約数を目指す
        2. 銀の弾丸はない
        3. 妥協せずあきらめる
  3. 最後に
    1. アーキテクチャ設計の観点は変化して切る
    2. チームで取り組もう
    3. よりよい選択のために継続的な努力を