Vsug architect academy_sakakibara_20101016

VSUG アーキテクト・アカデミー

アーキテクトを志向するみなさんへ
2010年10月16日
日本アイ・ビー・エム株式会社
グローバル・ビジネス・サービス事業 CTO
IBMディスティングイッシュト・エンジニア技術理事
榊原彰

© 2010 IBM Corporation

自己紹介
1986年日本アイ・ビー・エム株式会社入社。以来，主にサービス部門にて，
SEとして銀行，新聞社，電子部品メーカー，自動車メーカーなど多数のプロ
ジェクトに参画。専門はアーキテクチャ設計技術。2006年から同社東京基
礎研究所にてサービス・ソフトウェア・エンジニアリングの研究に従事した後，
2008年1月よりグローバル・ビジネス・サービス（GBS)事業に帰任。
現在全世界のエンタープライズ・アーキテクチャ＆テクノロジー部門の責任者兼，
GBS事業技術統括CTO。IBMディスティングイッシュト・エンジニア（技術理事）。
著書：「SEの基礎知識アプリケーション開発技術」（共著，リックテレコム），「ソフトウェ
ア品質知識体系（SQuBOK）ガイド」（共著，オーム社），「ITアーキテクトになる方法」
（翔泳社予定）
訳書：「MDAモデル駆動アーキテクチャ」（共訳，エスアイビー・アクセス），「ソフトウェ
アエンジニアリングの基礎知識体系 –SWEBOK-」（共訳，オーム社），「Eclipseモデリ
ングフレームワーク」（監訳，翔泳社），「実践ソフトウェアエンジニアリング」（監訳，日
科技連出版社），「SOA大全」（共訳，日経BP）MDAマニフェスト」（共訳，エスアイ
ビー・アクセス），「プロブレムフレーム」(監訳，翔泳社，2006），「システムアーキテク
チャ構築の原理」（監訳，翔泳社），「実践アジャイルテスト」（監訳，翔泳社）

情報処理学会，情報システム学会，プロジェクトマネジメント学会，IEEE Computer
Society，ACMの各正会員。 © 2010 IBM Corporation

ITスキル標準（ITSS）におけるITアーキテクトの役割
ＩＴ投資の局面経営戦略策定
経営戦略策定戦略的情報化企画
戦略的情報化企画開発
開発運用・保守
運用・保守
と活動領域
経営目標／ビジネス課題ソリューションコンポネントソリューションソリューションソリューション
ビジョン策定戦略策定整理／分析設計設計構築運用保守
職種
（ビジネス /ＩＴ） (構造/ﾊﾟﾀｰﾝ ) (ｼｽﾃﾑ/ 業務）（開発 /実装）（ｼｽﾃﾑ /業務）（ｼｽﾃﾑ /業務）

目標/ビジョン
目標/ビジョンビジネス
ビジネスビジネス課題
ビジネス課題
セールスの確認
の確認戦略の確認ｿﾘｭｰｼｮﾝ提案
戦略の確認ｿﾘｭｰｼｮﾝ提案

目標/ビジョン
目標/ビジョンビジネス戦略
ビジネス戦略ソリューションソリューション
ソリューション
コンサルタントの提言策定の助言
策定の助言策定のためのの設計
の設計
の提言
助言

ＩＴソリューションソリューションコンポネントのソリューション
の枠組み策定アーキテク設計の構築
アーキテクトの枠組み策定
チャーの設計

プロジェクト基
プロジェクト基
プロジェクトプロジェクトのプロジェクトのプロジェクトのプロジェクトのプロジェクトの
本計画の策定
本計画の策定
マネジメント管理/統制管理/統制管理/統制管理/統制管理/統制

システム・コンシステム・コン
システム構築システム・コン
システム・コンシステムのシステムのシステム・コン
システムの
IT システム構築ポネントの導入
計画の策定ポネントのポネントの運用ポネントの保守
スペシャリスト計画の策定ポネントの設計導入構築
構築運用保守
設計支援
•ビジネス戦略ｱﾌﾟﾘｹｰｼｮﾝｱﾌﾟﾘｹｰｼｮﾝｱﾌﾟﾘｹｰｼｮﾝｱﾌﾟﾘｹｰｼｮﾝ
ｱﾌﾟﾘｹｰｼｮﾝ
アプリケーション
ITアーキテクト
ｱﾌﾟﾘｹｰｼｮﾝ
開発計画の策
開発計画の策定ｺﾝﾎﾟﾈﾝﾄ ITアーキテクチャ
ｺﾝﾎﾟﾈﾝﾄｺﾝﾎﾟﾈﾝﾄｺﾝﾎﾟﾈﾝﾄ
スペシャリスト
•ビジネスプロセスの活動の設計
定の開発の運用支援
の運用
（開発へ）の保守

カスタマ導入計画ハードウェアハードウェアハードウェア
検討結果導入計画
の策定ソフトウェアソフトウェアソフトウェア
サービスの策定
の導入の保守の保守

運用計画 / システムのシステムの
オペレーション運用管理運用と管理運用と管理
の策定
の策定
主たる活動局面従たる活動局面
3 © 2010 IBM Corporation

ITSS v.3にみるITアーキテクトの活動内容
 ビジネス及びＩＴ上の課題を分析し、ソリューションを構成する情報システム化要件として再構成す
る。ハードウェア、ソフトウェア関連技術（アプリケーション関連技術、メソドロジ）を活用し、顧客のビ
ジネス戦略を実現するために情報システム全体の品質（整合性、一貫性等）を保ったＩＴアーキテク
チャを設計する。設計したアーキテクチャが課題に対するソリューションを構成することを確認する
とともに、後続の開発、導入が可能であることを確認する。また、ソリューションを構成するために情
報システムが満たすべき基準を明らかにする。さらに実現性に対する技術リスクについて事前に影
響を評価する。
 ＩＴ投資の局面においては、戦略的情報化企画（課題整理と分析(ビジネス及びIT)、ソリューション
設計(構造とパターン)）を主な活動領域として以下を実施する。
 戦略的情報化企画
–ソリューションの枠組み策定
–ソリューションアーキテクチャの設計
 当該職種は、以下の専門分野に区分される。
 アプリケーションアーキテクチャ
 ビジネス及びＩＴ上の課題を分析し、機能要件として再構成する。機能属性、仕様を明らかにし、アプリケー
ションアーキテクチャ（アプリケーションコンポネント構造、論理データ構造等）を設計する。設計したアーキテ
クチャがビジネス及びＩＴ上の課題に対するソリューションを構成することを確認するとともに、後続の開発、導
入が可能であることを確認する。
 インテグレーションアーキテクチャ
 全体最適の観点から異種あるいは複数の情報システム間の統合及び連携要求を分析し、統合及び連携要
件として再構成する。統合及び連携仕様を明らかにし、インテグレーションアーキテクチャ（フレームワーク構
造およびインタオペラビリティ）を設計する。設計したアーキテクチャが統合及び連携要求を満たすことを確認
するとともに、後続の開発、導入が可能であることを確認する。
 インフラストラクチャアーキテクチャ
 ビジネス及びＩＴ上の課題を分析し、システム基盤要件として再構成する。システム属性、仕様を明らかにし、
インフラストラクチャアーキテクチャ（システムマネジメント、セキュリティ、ネットワーク、プラットフォーム等）を
設計する。設計したアーキテクチャがビジネス及びＩＴ上の課題に対するソリューションを構成することを確認
4
するとともに、後続の開発、導入が可能であることを確認する。 © 2010 IBM Corporation

アーキテクチャとは何か

Architecture: the fundamental organization of a system embodied in
its components, their relationships to each other and to the
environment, and the principles guiding its design and evolution.
「アーキテクチャ：コンポーネントを統合したシステムの基本的な編成，コン
ポーネント相互およびコンポーネントと環境間の関係，そしてシステム設計と
進化を導く原則」
IEEE Std.1471-2000 Recommended Practice for Architectural Description of Software Intensive Systems

キーワード： organization, components, principles

「分け方とつなぎ方」 → 「全体をどう切り分け，部分をどのように関係づけるか」
中国では「結構」（ものごとの構えとその結びつき）と表現される


IEEE Std. 1471-2000 アーキテクチャ記述の概念モデル


ITアーキテクトの主要活動領域

④ ビジネスとITのギャップを埋め，ソリューションの枠組みを作る

ビジネス
③ ビジネスの形態に応じてITソリューションを最適化する

② ITシステム構築手法を決定する
IT
① ITアーキテクチャをデザインする


ITアーキテクトが押さえるべき4つの原則

ITアーキテクチャの構築
 Separation of Concerns
ITソリューションの構築手法決定
 Method Adoption
ITソリューションの最適化
 Solution Optimization
ビジネス戦略・課題の領域からIT領域まで
 Business-IT Alignment



 Method Adoption


アーキテクチャ構成の基本原則
機能要求のモデル化（コンポーネントベースでの分析・設計）
テクノロジー・セレクションのためのモデル化（インフラ設計の抽象化）
コンポーネントをどのようにノードに配置するか
関心事の分離（Separation of Concerns）

機能実装 ITシステム
稼働環境実装

包含する
コンポーネントノード

配置する


Separation of Concerns

アーキテクチャは多様な側面から設計されるべき
 建築の設計図面のアナロジー
 立体を平面に表現しなければならない
IT設計においては以下が必要
 要求の切り分け
 上位概念（メタ）による分類
全体をいかに「切り分け」て，
いかに「組み合せ」るか


ソリューション・アーキテクチャ

ビジネス・アーキテクチャ
• ビジネス・プロセス/ルール
• サービス・ゴール
•…

アプリケーション・アーキテクチャ
• アプリケーション・コンポーネント
• アプリケーション・フレームワーク
•…
ソリューション・
アーキテクチャ配置（データサービス/アプリケーション）
（全体として1 • データサービス・アーキテクチャ
つのアーキテ • コンポーネント配置
クチャ）
•…

インフラストラクチャ・アーキテクチャ
• ネットワーク・アーキテクチャ
• セキュリティ・アーキテクチャ
• ハードウェア・ノード物理配置
•…


エンタープライズ・アーキテクチャとソリューション・アーキテクチャ

ソリューションB ソリューションＤ

ソリューションＣ
ソリューションA

全全
社社
経Ｉ
営Ｔ
戦戦
略略

全社インフラストラクチャ・アーキテクチャ

アーキテクチャ・ガバナンス



 Method Adoption


構築技術の変遷とプラットフォーム

方法論の
人口データ中心
(世界)

機能中心

オブジェクト指向

1970 1980 1990 2000

ＵＮＩＸ
メインフレーム

プラットクライアント／
フォームサーバー
Web


構築技術変遷の背景

 機能中心
 演算コストの高価な時期に処理機能を中心に最適化
CASEツール
 データ中心
 取り扱うデータの種類・項目数の増大に伴い，DB編成や入出力のコストが機能より高価に
 データ項目／データ構造／データの流れ中心，機能は単なるデータ変換の役割
 オブジェクト指向
 データ構造と処理をカプセル化 Visualプログラミング
 GUIやイベント駆動のプログラミング・モデルに合致
 コンポーネント指向
 再利用性の追求が必要に J2EE/.NET など
 変化に対する柔軟性が求められる
 サービス指向
 サービスの柔軟な組み合わせを指向
 ビジネスの変化に対するスピード性を重視 Webサービス, ビジネス・インテグレーション
 …


開発規模と負荷
1Kステップ（LOC）当たりの相対負荷

30

個人差
25

欠陥除去活動

20 最小労力

15

10

5

0
1 2 4 8 16 32 64 128 256 512 1,024 2,048
開発Kステップ（LOC）

開発における手戻りコスト

前工程以前の欠陥に対する除去コスト

工程内の欠陥に対する除去コスト

本来の理想的な開発コスト

開発工程

要件定義外部設計内部設計開発実施統合テストb システムテスト

（統合テストa）


構築手法の選択はリスクヘッジの組み込みでもあります。

IT構築は実装終了間近まで要求の実現可能性を確
信しづらい
アプリケーション開発プロジェクトの成功率 == 28%*
要求定義段階からリリースまでのタイムラグ
ビジネスシステムとしての観点まで広げるなら，更に不透明
いくつかのリスクヘッジ手法
–プロトタイピング
–モデル駆動型開発
–反復型開発プロセス
–スモールリリースと継続的インテグレーション
–ビジネスプロセス・モデリングとシミュレーション
* Standish Group “Chaos Report 2007”


構築手法の選択は、何を重視するかによって変わります。

プロセスウォーターフォール開反復型開発アジャイル開発
発
成功の測定計画への適合変化への対応
動くコード
マネジメント文化命令と制御リーダーシップ
協業的
要求と設計大きくて前払い継続的・発現的
ジャストインタイム
コーディングと実装全機能を同時にコーディングとユニッ
コーディングトテスト
後でテスト順番に納品
テストと品質保証大きく、計画に基づく継続的・同時発生
遅くテスト早期にテスト
計画と PERT・詳細・範囲固定 2レベル計画・期日固定
スケジューリング時間と工数を見積もり範囲を見積もり

出展：「アジャイル開発の本質とスケールアップ」


 Method Adoption


ソリューションの最適化とは。

ITソリューション実現方法のコスト・方法の最適化
ソリューション自体のパラダイムチェンジ
– e.g. 飲料自販機の補充に最適経路の実装を求められたら
最適なソリューションを生むために必要なもの
 ドメイン知識
 実現技術を選択するための知識
 問題分析とパターン化の知識ドメイン
（要求工学プラクティス）知識

最適化
実現問題
技術分析


要求工学の技術体系に学ぶ。

要求工学=要求開発+要求管理
要求工学 RE
(Requirements Engineering)

要求開発 RD 要求管理 RM
(Requirements Development) (Requirements Management)

要求獲得要求分析要求仕様記述要求検査
(Requirements
Elicitation / (Requirements (Requirements (Requirements
Acquision) Aanalysis) Specification) Validation)

P. Sawyer, Software Requirements, R. H. Thayer, et al., Software Engineering, 3 rd ed, IEEE Computer Society, 2005


要求のスコープを確実に理解し、インパクトを認識します。

階層的なスコープ：ビジネス/システム/ソフトウェア/ハードウェア
環境: ステークホルダ，市場/ビジネス慣行，法規制 etc

ビジネスビジネス要求

ビジネス戦略ビジネスビジネス
データ
/ ゴールプロセスルール

システムシステム要求

ソフトウェアソフトウェア要求
ハードウェア
機能要求非機能要求将来要求要求


Non-Functional Requirements (NFR) ：非機能要求

Non-functional requirements, as the name suggests, are those
requirements which are not directly concerned with the specific functions
delivered by the system. They may relate to emergent system properties
such as reliability, response time and store occupancy. Alternatively, they
may define constraints on the system such as the capabilities of I/O
devices and the data representations used in system interfaces.
(Software Engineering 6th Edition, Ian Sommerville, 2001)

非機能要求は，時として，制約条件(constraints)もしくは品質要求(quality
requirements)として知られている。また，この要求はさらに以下のように分類できる。
（例えば）性能要求，保守容易性要求，安全性要求，信頼性要求，電磁気互換性要求，
その他の様々なタイプの要求である。
（ソフトウェアエンジニアリング基礎知識体系 – SWEBOK, 2003）


NFRの特徴

主観的
ヒトによって解釈と評価が異なる面を持つ
相対的
重要な点は，対象システムの特性によって異なる
相互干渉的
一つのNFRを達成しようとすると，他のNFRを「損じる」

このように扱いが難しいのに，
システムの重要成功要因として大きな比重を占めている


NFR トレードオフの例
Inter- Maintain-
Availability Efficiency Flexibility Integrity Portability Reliability Reusability Robustness Usability
operability ability

Availability ＋＋

Efficiency －－－－－－－

Flexibility －－＋＋＋

Integrity －－－－

Inter-
－＋－＋
operability

Maintain-
＋－＋＋
ability

Portability －＋＋－＋－

Reliability ＋－＋＋＋＋

Reusability －＋－＋＋＋－

Robustness ＋－＋＋

Usability －＋

Source: “Software Requirements”, Karl E. Wiegers


 Method Adoption


ビジネスとITライフサイクルの一体化が重要です。

ビジネスゴールの設定と
ブレイクダウン
メトリクス・ポートフォリオ分析
ビジネスプロセス・モデリング

ビジネス
要求定義
監視

IT運用

開発リソース最適化

テストとディプロイソフトウェア開発

設計と構築


ビジネス・アーキテクチャーの全容をカバーする方策が必要です
。
*
BusinessEnvironment

is influenced by
*

assembles
Business BusinessResource

performs 1..* 1..*
1 1
input
*
belongs
BusinessUnit Role
is defined by 1 1..* output
1..*
achieves 1..*
drives
* * 1
1..* 1..* 1

1..* 1..*
BusinessGoal BusinessProcess is driven by BusinessEvent
1 fulfills 1..*
1
1 1
consists of 1
1..*
1..*
estimates evaluates includes
is decomposed by
BusinessPolicy
1 1 *
1..*
constraints
BusinessPerformance 1..* BusinessRule

IPA ITスキル標準センターアーキテクチャ・メタモデル解説書

“Business”関連ソリューションが密接に連携します。

Detect
何が起こっているか？いつ行動をとるか？
What’s Happening When to Act BEP
イベントソース
BAM Decide
BEPランタイム BRMS
評価・相関

何を実行するか？
What to Do !

• BEP := Business Event Processing
• BPM := Business Process Management
BPM
• BAM := Business Activity Management
• BRMS = Business Rule Management System


異なる課題に対する異なる技術を統合して，総合的なソリューションを構築します。

イベントの関連付けやイベント・パターン検知し、他のプロセスへの通知や対応
アクションの発動を行う
• 製品調査のイベントが発生したら、ダイレクト・メールのデータベースを更新
ビジネス・イベント処理 • 製品調査のイベントが２回発生したら、テレマーケティングのワークフローを発動
（BEP） • 製品調査のイベントが２回発生し、かつ、2日以内に購入のイベントが発生しないなら、営
業によるフォローアッププロ説を発動

サービスやプロセス・ステップにおけるビジネス判断や推奨を自動化するための
ビジネス・ルールを実装する
• 口座審査結果を受けて、顧客のクレジット限度額の変更を実施
• 申し込みから社会福祉援助の適格性を判断
ビジネス・ルール管理 • 保健契約申込書の承諾と保険料の価格設定
（BRMS)

キャプチャー、集約、測定、KPIの表示を行い、閾値を超えた場合にアラートを発動
する
• 重要性のアクティビティを示すグラフ
• データの集約と閾値
ビジネス・アクティビティ監視 • 例外に起因したアラート通知
(BAM)

人間系およびシステム・アクティビティの特定のシーケンスを実行する
• ヘルプデスクへの電話に対応するためのプロセス
• 新しいクライアントをサインアップするためのプロセス
• 新規従業員を登録するためのプロセス
ビジネス・プロセス管理
(BPM)

時間制約のあるイベントを処理する一般的なフレームワーク

金融市場イベントベース・エンジンは時間制約を
データ守りつつ、イベント・データのルーティン
グ、順序付け、フィルタリングを行う

RFID データ適宜選択してシステム
や人に通知
イベントの通知

イベントベース・エンジン
リッチ・メディア
イベント・ストリームを関心のあるパターンを
連続的に解析識別
イベントの解析イベントに対するアクション

監視システム
データ TDDB: Time-dependent DB
TDDB DB
ウェアハウス


 Method Adoption
ニュー・パラダイムへの挑戦


データは時間的にも空間的にもますます細かな精度で
得られるようになっています。

 「人」に対するセンサー: 居場所
（その人が持っているデバイスの位置より
推測）、活動（カレンダーやデスクトップ情
報から推測）、生体認証、
など

 「場所」に対するセンサー: 部屋の状態（動
きや音から推測。ただし、人物の特定はし
ない）、（人や物の）所在確認、混雑具合
（圧力パッドやカメラの映像より推測）、な
ど

 「モノ」に対するセンサー: 位置（RFID）、
状態（テレマティックスやデスクトップなど
の監視センサー）、
など

 「ビジネス」に対するセンサー: データベー
ス、Webなどから得られる状況データ
（医療データ、クレジットカードの利用履歴、
場所の履歴）、業務プロセスより得られる
状況データ


クラウド・コンピューティングはアーキテクチャ設計技術に大きな
変化をもたらすでしょう。

キーとなる5つの性質:
1. On-demand self-service
2. Ubiquitous network access
3. Location independent resource pooling
4. Rapid elasticity
5. Flexible pricing models

36

企業システムの価値や求められる優先順位が変化しています。

時間軸企業システムの価値（例）キーワード

• 手作業をITに置き換えて人件費を下げる
旧来 • 人・ライン等の資源の生産性を上げる QCD
• IT処理により品質を上げる

• 新しい商品やサービスに素早く対応できる
近年 • 柔軟かつ迅速にサプライチェーンの変更ができる Agility
• 段階的・連続的なシステム変更ができる

• 大量・連続的データをリアルタイムに解析できる
Dynamic /
将来 • 解析結果をもとにビジネス行動の最適化を図る
• ITリソース自体の最適化が動的に行われる Optimization


技術の変化に追随しつつ、
技術の断片に惑わされない原則を身につける。
ITアーキテクトの醍醐味はそこにあります。


Vsug architect academy_sakakibara_20101016

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Similaire à Vsug architect academy_sakakibara_20101016

Similaire à Vsug architect academy_sakakibara_20101016 (20)

Dernier

Dernier (8)

Vsug architect academy_sakakibara_20101016