vsug architect academy_sakakibara_20101016

© 2010 IBM Corporation

アーキテクトを志向するみなさんへ

2010年10月16日

日本アイ・ビー・エム株式会社

グローバル・ビジネス・サービス事業 CTO

IBMディスティングイッシュト・エンジニア技術理事

榊原彰

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


自己紹介

1986年日本アイ・ビー・エム株式会社入社。以来，主にサービス部門にて，SEとして銀行，新聞社，電子部品メーカー，自動車メーカーなど多数のプロジェクトに参画。専門はアーキテクチャ設計技術。2006年から同社東京基

礎研究所にてサービス・ソフトウェア・エンジニアリングの研究に従事した後，2008年1月よりグローバル・ビジネス・サービス（GBS)事業に帰任。

著書：「SEの基礎知識アプリケーション開発技術」（共著，リックテレコム），「ソフトウェア品質知識体系（SQuBOK）ガイド」（共著，オーム社），「ITアーキテクトになる方法」（翔泳社予定）訳書：「MDAモデル駆動アーキテクチャ」（共訳，エスアイビー・アクセス），「ソフトウェアエンジニアリングの基礎知識体系 –SWEBOK-」（共訳，オーム社），「Eclipseモデリ

ングフレームワーク」（監訳，翔泳社），「実践ソフトウェアエンジニアリング」（監訳，日科技連出版社），「SOA大全」（共訳，日経BP）MDAマニフェスト」（共訳，エスアイビー・アクセス），「プロブレムフレーム」(監訳，翔泳社，2006），「システムアーキテクチャ構築の原理」（監訳，翔泳社），「実践アジャイルテスト」（監訳，翔泳社）

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

現在全世界のエンタープライズ・アーキテクチャ＆テクノロジー部門の責任者兼，GBS事業技術統括CTO。IBMディスティングイッシュト・エンジニア（技術理事）。

© 2010 IBM Corporation 3

主たる活動局面従たる活動局面

システムの

運用と管理

システムの

運用と管理

運用計画 /

運用管理

の策定

ハードウェア

ソフトウェア

の保守

ハードウェア

ソフトウェア

の保守

ハードウェア

ソフトウェア

の導入

導入計画

の策定

ｱﾌﾟﾘｹｰｼｮﾝ

ｺﾝﾎﾟﾈﾝﾄ

の保守



の運用



の開発



の設計


開発計画の策

定

システムの

保守

システムの

運用

システムの

導入構築

システム・コン

ポネントの

設計

システム構築

計画の策定

プロジェクトの

管理 / 統制


管理 / 統制


管理 / 統制


管理 / 統制


管理 / 統制

プロジェクト基

本計画の策定

ソリューション

の構築

コンポネントの

設計


アーキテク

チャーの設計


の枠組み策定


の設計


策定のための

助言

ビジネス戦略

策定の助言目標 / ビジョン

の提言

ビジネス課題

ｿﾘｭｰｼｮﾝ提案

ビジネス

戦略の確認

目標 / ビジョン

の確認


保守

（ｼｽﾃﾑ / 業務）


運用



構築

（開発 / 実装）

コンポネント

設計

( ｼｽﾃﾑ / 業務）


設計

( 構造 / ﾊﾟﾀｰﾝ )

課題

整理／分析

（ビジネス / ＩＴ）

ビジネス

戦略策定

経営目標／

ビジョン策定

運用・保守開発戦略的情報化企画経営戦略策定

システムの

運用と管理

システムの

運用と管理

運用計画 /

運用管理

の策定

オペレーション

ハードウェア

ソフトウェア

の保守

ハードウェア

ソフトウェア

の保守

ハードウェア

ソフトウェア

の導入

導入計画

の策定

カスタマ

サービス



の保守



の運用支援



の開発



の設計


開発計画の策定

アプリケーション

スペシャリスト

ポネントの運用支援

システム・コン

ポネントの設計

システム構築

計画の策定 IT

スペシャリスト


管理 / 統制


管理 / 統制


管理 / 統制


管理 / 統制


管理 / 統制

プロジェクト基

本計画の策定プロジェクト

マネジメント


アーキテク

チャーの設計


の枠組み策定

ＩＴ

アーキテクト


の設計


策定のための

助言

ビジネス戦略

策定の助言目標 / ビジョン

の提言コンサルタント

ビジネス課題

ｿﾘｭｰｼｮﾝ提案

ビジネス

戦略の確認

目標 / ビジョン

の確認セールス


保守



運用



構築

（開発 / 実装）

コンポネント

設計

( ｼｽﾃﾑ / 業務）


設計

( 構造 / ﾊﾟﾀｰﾝ )

課題

整理／分析

（ビジネス / ＩＴ）

ビジネス

戦略策定

経営目標／

ビジョン策定

運用・保守開発戦略的情報化企画経営戦略策定ＩＴ投資の局面

と活動領域

職種

主たる活動局面従たる活動局面

システム・コンシステム・コンシステム・コン

ポネントの導入

構築ポネントの保守

ITアーキテクトの活動

•ビジネス戦略

•ビジネスプロセス検討結果

ITアーキテクチャ（開発へ）

ITスキル標準（ITSS）におけるITアーキテクトの役割


ITSS v.3にみるITアーキテクトの活動内容ビジネス及びＩＴ上の課題を分析し、ソリューションを構成する情報システム化要件として再構成する。ハードウェア、ソフトウェア関連技術（アプリケーション関連技術、メソドロジ）を活用し、顧客のビジネス戦略を実現するために情報システム全体の品質（整合性、一貫性等）を保ったＩＴアーキテクチャを設計する。設計したアーキテクチャが課題に対するソリューションを構成することを確認するとともに、後続の開発、導入が可能であることを確認する。また、ソリューションを構成するために情報システムが満たすべき基準を明らかにする。さらに実現性に対する技術リスクについて事前に影響を評価する。

ＩＴ投資の局面においては、戦略的情報化企画（課題整理と分析(ビジネス及びIT)、ソリューション設計(構造とパターン)）を主な活動領域として以下を実施する。戦略的情報化企画

–ソリューションの枠組み策定

–ソリューションアーキテクチャの設計

当該職種は、以下の専門分野に区分される。

アプリケーションアーキテクチャビジネス及びＩＴ上の課題を分析し、機能要件として再構成する。機能属性、仕様を明らかにし、アプリケーションアーキテクチャ（アプリケーションコンポネント構造、論理データ構造等）を設計する。設計したアーキテクチャがビジネス及びＩＴ上の課題に対するソリューションを構成することを確認するとともに、後続の開発、導入が可能であることを確認する。

インテグレーションアーキテクチャ全体最適の観点から異種あるいは複数の情報システム間の統合及び連携要求を分析し、統合及び連携要件として再構成する。統合及び連携仕様を明らかにし、インテグレーションアーキテクチャ（フレームワーク構造およびインタオペラビリティ）を設計する。設計したアーキテクチャが統合及び連携要求を満たすことを確認するとともに、後続の開発、導入が可能であることを確認する。

インフラストラクチャアーキテクチャビジネス及びＩＴ上の課題を分析し、システム基盤要件として再構成する。システム属性、仕様を明らかにし、インフラストラクチャアーキテクチャ（システムマネジメント、セキュリティ、ネットワーク、プラットフォーム等）を設計する。設計したアーキテクチャがビジネス及びＩＴ上の課題に対するソリューションを構成することを確認するとともに、後続の開発、導入が可能であることを確認する。


アーキテクチャとは何か

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システム

コンポーネントノード

配置する

包含する



アーキテクチャは多様な側面から設計されるべき建築の設計図面のアナロジー

立体を平面に表現しなければならない

IT設計においては以下が必要要求の切り分け

上位概念（メタ）による分類

全体をいかに「切り分け」て，

いかに「組み合せ」るか


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

• ネットワーク・アーキテクチャ

• セキュリティ・アーキテクチャ

• ハードウェア・ノード物理配置

• …

配置（データサービス/アプリケーション）

• データサービス・アーキテクチャ

• コンポーネント配置

• …

アプリケーション・アーキテクチャ

• アプリケーション・コンポーネント

• アプリケーション・フレームワーク

• …

ビジネス・アーキテクチャ

• ビジネス・プロセス/ルール

• サービス・ゴール

• …

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

（全体として1

つのアーキテクチャ）

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


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

全社経営戦略

全社ＩＴ戦略

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

ソリューションA

ソリューションB

ソリューションＣ

ソリューションＤ

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






Method Adoption






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

1970 1980 1990 2000

方法論の人口(世界)

プラットフォーム

機能中心

データ中心

オブジェクト指向

メインフレーム

クライアント／サーバー

ＵＮＩＸ

Web


構築技術変遷の背景

機能中心演算コストの高価な時期に処理機能を中心に最適化

データ中心取り扱うデータの種類・項目数の増大に伴い，DB編成や入出力のコストが機能より高価に

データ項目／データ構造／データの流れ中心，機能は単なるデータ変換の役割

オブジェクト指向データ構造と処理をカプセル化

GUIやイベント駆動のプログラミング・モデルに合致

コンポーネント指向再利用性の追求が必要に

変化に対する柔軟性が求められる

サービス指向サービスの柔軟な組み合わせを指向

ビジネスの変化に対するスピード性を重視

…

CASEツール

Visualプログラミング

J2EE/.NET など

Webサービス, ビジネス・インテグレーション


開発規模と負荷

0

5

10

15

20

25

30

最小労力

欠陥除去活動

個人差

1 2 4 8 16 32 64 128 256 1,024 2,048 512

1Kステップ（LOC）当たりの相対負荷

開発Kステップ（LOC）


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

開発工程

要件定義外部設計内部設計開発実施

（統合テストa）

統合テストb システムテスト

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

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

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


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

IT構築は実装終了間近まで要求の実現可能性を確信しづらい

アプリケーション開発プロジェクトの成功率 == 28%*

要求定義段階からリリースまでのタイムラグ

ビジネスシステムとしての観点まで広げるなら，更に不透明

いくつかのリスクヘッジ手法

–プロトタイピング

–モデル駆動型開発

–反復型開発プロセス

–スモールリリースと継続的インテグレーション

–ビジネスプロセス・モデリングとシミュレーション

* Standish Group “Chaos Report 2007”


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

20

プロセスウォーターフォール開発

反復型開発アジャイル開発

成功の測定計画への適合変化への対応

動くコード

マネジメント文化命令と制御リーダーシップ

協業的

要求と設計大きくて前払い継続的・発現的

ジャストインタイム

コーディングと実装全機能を同時にコーディング

後でテスト

コーディングとユニットテスト

順番に納品

テストと品質保証大きく、計画に基づく

遅くテスト

継続的・同時発生

早期にテスト

計画とスケジューリング

PERT・詳細・範囲固定

時間と工数を見積もり

2レベル計画・期日固定

範囲を見積もり

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






Method Adoption






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

ITソリューション実現方法のコスト・方法の最適化

ソリューション自体のパラダイムチェンジ – e.g. 飲料自販機の補充に最適経路の実装を求められたら

最適なソリューションを生むために必要なものドメイン知識

実現技術を選択するための知識

問題分析とパターン化の知識

（要求工学プラクティス）ドメイン

知識

実現

技術

問題

分析


最適化


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

要求工学=要求開発+要求管理

要求工学 RE

(Requirements Engineering)

要求開発 RD

(Requirements Development)

要求管理 RM

(Requirements Management)

要求獲得

(Requirements

Elicitation /

Acquision)

要求分析

(Requirements

Aanalysis)

要求仕様記述

(Requirements

Specification)

要求検査

(Requirements

Validation)

P. Sawyer, Software Requirements, R. H. Thayer, et al., Software Engineering, 3rd 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 トレードオフの例

Availability Efficiency Flexibility Integrity Inter-

operability

Maintain-

ability Portability Reliability Reusability Robustness Usability

Availability ＋＋

Efficiency －－－－－－－

Flexibility －－＋＋＋

Integrity －－－－

Inter-

operability －＋－＋

Maintain-

ability ＋－＋＋

Portability －＋＋－＋－

Reliability ＋－＋＋＋＋

Reusability －＋－＋＋＋－

Robustness ＋－＋＋

Usability －＋

Source: “Software Requirements”, Karl E. Wiegers






Method Adoption






ビジネスプロセス・モデリング

要求定義

テストとディプロイ

設計と構築

監視

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

ソフトウェア開発

IT運用

ビジネス

ビジネスゴールの設定とブレイクダウン

メトリクス・ポートフォリオ分析

開発リソース最適化


BusinessGoal

BusinessPerformance

BusinessUnit Role

BusinessProcess

BusinessRule

BusinessEnvironment

Business

*

1

*

1 1

1..*

1..*

1..*

1

drives

is decomposed by

is influenced by

constraints

fulfills

1..*

1..*

BusinessEvent

BusinessResource

BusinessPolicy

*

assembles

1

*

is defined by

performs

*

1

belongs

achieves

1

1..*

input

output

1

1..*

1..* includes

1..*

consists of

1..*

1..*

1 1

1

estimates evaluates

* 1..*

1..*

1

1..* is driven by

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

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


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

• BEP := Business Event Processing

• BPM := Business Process Management

• BAM := Business Activity Management

• BRMS = Business Rule Management System

評価・相関

イベントソース

BEPランタイム

!

What’s Happening When to Act

What to Do

何を実行するか？

いつ行動をとるか？何が起こっているか？

BPM

BAM

BEP

BRMS

Detect

Decide


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

• 製品調査のイベントが発生したら、ダイレクト・メールのデータベースを更新

• 製品調査のイベントが２回発生したら、テレマーケティングのワークフローを発動

• 製品調査のイベントが２回発生し、かつ、2日以内に購入のイベントが発生しないなら、営業によるフォローアッププロ説を発動

イベントの関連付けやイベント・パターン検知し、他のプロセスへの通知や対応アクションの発動を行う

• 重要性のアクティビティを示すグラフ

• データの集約と閾値

• 例外に起因したアラート通知

キャプチャー、集約、測定、KPIの表示を行い、閾値を超えた場合にアラートを発動する

• 口座審査結果を受けて、顧客のクレジット限度額の変更を実施

• 申し込みから社会福祉援助の適格性を判断

• 保健契約申込書の承諾と保険料の価格設定

サービスやプロセス・ステップにおけるビジネス判断や推奨を自動化するためのビジネス・ルールを実装する

ビジネス・イベント処理

（BEP）

ビジネス・ルール管理

（BRMS)

ビジネス・アクティビティ監視

(BAM)

人間系およびシステム・アクティビティの特定のシーケンスを実行する

• ヘルプデスクへの電話に対応するためのプロセス

• 新しいクライアントをサインアップするためのプロセス

• 新規従業員を登録するためのプロセスビジネス・プロセス管理

(BPM)


監視システム

金融市場データ

RFID データ

リッチ・メディア

TDDB DB データ

ウェアハウス

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

イベントに対するアクションイベントの解析

イベントの通知

イベントベース・エンジン

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

TDDB: Time-dependent DB

イベント・ストリームを連続的に解析

関心のあるパターンを識別

適宜選択してシステムや人に通知






Method Adoption





ニュー・パラダイムへの挑戦


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

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

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

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

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

http://images.google.com/imgres?imgurl=http://www.kennedygrp.com/user_images/RFID%2520Nameplate.jpg&imgrefurl=http://www.kennedygrp.com/home.cfm&h=1101&w=1488&sz=332&tbnid=EsRrZ6pqK_oJ:&tbnh=110&tbnw=150&hl=en&start=1&prev=/images?q=RFID&svnum=10&hl=en&lr=&sa=N

© 2010 IBM Corporation 36 36

クラウド・コンピューティングはアーキテクチャ設計技術に大きな

変化をもたらすでしょう。

キーとなる5つの性質:

1.On-demand self-service

2.Ubiquitous network access

3.Location independent resource pooling

4.Rapid elasticity

5.Flexible pricing models


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

旧来

近年

将来

• 手作業をITに置き換えて人件費を下げる

• 人・ライン等の資源の生産性を上げる

• IT処理により品質を上げる

• 新しい商品やサービスに素早く対応できる

• 柔軟かつ迅速にサプライチェーンの変更ができる

• 段階的・連続的なシステム変更ができる

QCD

Agility

Dynamic /

Optimization

• 大量・連続的データをリアルタイムに解析できる

• 解析結果をもとにビジネス行動の最適化を図る

• ITリソース自体の最適化が動的に行われる

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


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