SOAは終わたのか？ SOAは終わったのか？

SOAは終わたのか？
SOAは終わったのか？
－技術の空白と失われた10年－
SOAやるべきかやめるべきか
2009年4月
清水敏正
金融危機から始まった実体経済の混乱で、コスト削減だけが期待されるIT部門にはなりたくない。
そう思いながらクラウドを検討しているのが最近のIT部門の管理者の方々でしょうか。
最新技術のつまみ食いで、世界は簡単に変わるのか？
SOAが叫ばれてすでに４年以上。
ほとんどの企業はSOAの実践に着手できていない現在アプローチは正しかったのか？
ほとんどの企業はSOAの実践に着手できていない現在、アプロ
チは正しかったのか？
SOAの最大の売り手である大手ミドルウェア・ベンダーの売り方やユーザー企業の受け止め方の
双方に大きな誤りがあったのではないか？
消化できない技術が溢れる一方、巣ごもり状態でじっと動かない大勢は、
あたも失われた年
あたかも失われた10年のように、技術の流れを眺めているだけの層を作りだしている。
う
技術流れを眺
だ
を作だ
ユーザ企業のIT 部門管理者にとって、SOAをどう受け止めれば将来につながるのか？
それともSOAはただ終わったのか？
1
SOAとクラウド&SaaSの関係
Anne Thomas Manes
9 参照したBlogs
http://www.ibm.com/developerworks/blogs/page/gcuomo?entry=le_morte_d_soa_la#comments
http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html
2
SOA met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic
recession. SOA is survived by its offspring: mashups, BPM, SaaS, Cloud Computing, and all other architectural
approaches that depend on “services”
services . Once thought to be the savior of IT,
IT SOA instead turned into a great
failed experiment—at least for most organizations. SOA was supposed to reduce costs and increase agility on a
massive scale. Except in rare situations, SOA has failed to deliver its promised benefits. After investing millions,
IT systems are no better than before. In many organizations, things are worse: costs are higher, projects take
longer, and systems are more fragile than ever. The people holding the purse strings have had enough. With the
tight budgets of 2009, most organizations have cut funding for their SOA initiatives.
It’s time to accept reality. SOA fatigue has turned into SOA disillusionment. Business people no longer believe
that SOA will deliver spectacular benefits. “SOA” has become a bad word. It must be removed from our
vocabulary.
Th demise
The
d i off SOA is
i tragic
t i ffor th
the IT iindustry.
d t Organizations
O
i ti
d
desperately
t l need
d tto make
k architectural
hit t l
improvements to their application portfolios. Service-orientation is a prerequisite for rapid integration of data and
business processes; it enables situational development models, such as mashups; and it’s the foundational
architecture for SaaS and cloud computing. (Imagine shifting aspects of your application portfolio to the cloud
without enabling integration between on
on-premise
premise and off-premise
off premise applications
applications.)
) Although the word “SOA”
SOA is
dead, the requirement for service-oriented architecture is stronger than ever.
But perhaps that’s the challenge: The acronym got in the way. People forgot what SOA stands for. They were too
wrapped up in silly technology debates (e.g., “what’s the best ESB?” or “WS-* vs. REST”), and they missed
p
stuff: architecture and services.
the important
Successful SOA (i.e., application re-architecture) requires disruption to the status quo. SOA is not simply a
matter of deploying new technology and building service interfaces to existing applications; it requires redesign
of the application portfolio. And it requires a massive shift in the way IT operates. The small select group of
organizations that has seen spectacular gains from SOA did so by treating it as an agent of transformation. In
each
h off th
these success stories,
t i
SOA was jjustt one aspectt off th
the ttransformation
f
ti effort.
ff t A
And
dh
here’s
’ th
the secrett tto
success: SOA needs to be part of something bigger. If it isn’t, then you need to ask yourself why you’ve been
doing it.
The latest shiny new technology will not make things better. Incremental integration projects will not lead to
significantly reduced costs and increased agility.
agility If you want spectacular gains,
gains then you need to make a
spectacular commitment to change. Like Bechtel. It’s interesting that the Bechtel story doesn’t even use the
term “SOA”—it just talks about services.
And that’s where we need to concentrate from this point forward: Services.
3
日本のSOAは離陸できたのか？
基本的な仕組みは理解されているだろうか
技術的見地からの分析
9 XMLスキ
XMLスキーマを日常的に作成しているか？
マを日常的に作成しているか？
9 WSDLを普通に作成しているか？
9 WS-I
WS I BPやBSPを、すでに使用しているか？
BPやBSPをすでに使用しているか？
9 BPELの良さを利用しているか？
9 サービスのメタ情報管理を行っているか？
他の技術との関連性からの分析
他技術
関性
分析
9 業務分析と改善のBPMをIT部門が手伝っているか？
9 アジャイルな開発手法を内製で始めているか？
4
センセーショナルな技術
だけを追っていると
基礎体力がつかない
ひょっとして
この６年間で
技術の空白状態を
作ってしまったのでは？
5
バブル崩壊と空白の10年
日経平均最高値
３８915円
路線価最高値
バブル崩壊
中東戦争と
オイルシク
オイルショック
空白の10年
6
技術者個人で消化できない技術が...
Linux
.NET
Active Directory
XML
DCE
インターネット
Encina
VISTA
WCF
WF
Webサービス
OASIS
Web
WS-Transaction
WS-I RSP
WS-RM
SCA
Java
EJB
J2EE 1.2
J2EE 1.3
J2EE 1.4
JavaEE 5
Transaction
Web以外は投資できない
今の時代
CORBA
~‘90
‘99
‘00
‘01
‘02
‘03
‘04
’05
’06
’07
7
消化されていない基本技術
XML
9 企業内情報のXML化、XMLスキーマ作成
Webサービス
W bサビス
9 インターネット経由の企業間システム連携
BPEL
9 プログラム・フローは、Javaで書けばよく、BPELは不要？
プグラムフ
は、Javaで書けばよく、BPELは不要？
9 抽象化・階層化の必要性、考え方が理解しにくい？
9 人間系・画面系のフローを中心に考えてしまい、ビジネス
人間系・画面系のフローを中心に考えてしまいビジネス
・ロジックとの結合度を緩やかにできない？
9 呼び出せるサービスを作れていない
8
参考：サービスの論理アーキテクチャー
サービス・コンシューマー
Proxy コード等
サービス・インタフェース
サ
ビスインタフェス
サービス名
呼び出し先情報（URIなど）
実行内容（メタ情報）
入出力データの格納場所
入出力データの規定情報
エラー処理情報
サービス・コンシューマーは、サービスの
インタフェース情報からProxyコードなど
を生成しそれによ
を生成し、それによってサービスを呼び出す
サビを呼び出す
生成
サービス・インタフェースの情報は、個別に
配布したり中央リポジトリから検索し取り出し
配布したり、中央リポジトリーから検索し取り出し
たりすることで利用者が入手する。
サービスのメタ情報により、利用目的に合致する
かどうか等が判別できる。
サービス実装
実装コド
実装コード
トランスポート・プロトコル
伝送特性
セキュリティー特性
ト
トランザクション特性
ザクシ
特性
サービスの実装コードは、コンシューマーからは、
サ
ビスの実装
ドはンシ
からは
見えない。それにより、実装コードの変更などは
コンシューマーに影響を与えない。
しかし、各種の特性は、コンシューマーにとっても
しかし、各種の特性は、コンシュ
マにとっても
重要な情報なのでサービスのメタ情報に含める
ことが必須である。
参考：サービスの分類
サビス
サービス
他との依存関係が無く、インタフェース情報だけでリモート呼び出し可能な
他との依存関係が無く
インタ
ス情報だけでリモト呼び出し可能な
プログラム・エンティティー
コンポジッッション
ポジ
シ
単独でも実行可能な
サービスを、ある目的で
複数組み合わせて
意味を持たせること
コンポジット
ンポジト
サービス
複数のサービスを
組み合わせて作った
サービス
RESTサービス
RESTを使用した
単一のサービス
オーケストレーション
特殊な組み合わせで
単純な組み合わせ以上の
高度な操作を行うこと
ローカル・コンポジッション
フロー
BPELで定義されたシーケンス・フローで、
任意のサービス（人間系の処理なども）を
組み込めるサービス
ルール・エンジン＆デシジョン・テーブル
メディエーション
目的のサービスにアクセスする際に、中間の
どこかで各種の操作（ログ、分岐、別のサービス
に振り向ける、など）を行い、付加価値を付ける。
Handler PatternやESBパターンとも言われる。
サービスの実体
システムの外にあるサービスを呼び出し
組み合わせること
システムの内部にあるサービスを
密に組み合わせること
WSDLサービス
Webサービスを使用
した単一のサービス
リモトンポジシン
リモート・コンポジッション
サービスの操作
処理に必要な判断条件を分けて、
処理に必要な判断条件を分けて
外に出した形で実行できるサービス
状態遷移エンジン
外からのイベントによって状態が遷移する形式
の処理フローを実行できるサービス
参考：
サービス・コンポジッションの論理モデル
Java/C++/PHP系
Aシステム
コンシューマー
（SCAクライアント）
SCAドメイン
Bシステム
Webサービス
リモートEJB
JMS
REST
Spring
Bean
業務
アプリケーション
SCA
コンポジット
J2EE / レガシー
Webサービス
Webサ
ビス
.NET系
一般的
コンシューマー
WCF
Cシステム
.NET
アプリケーショ
ン
.NET Framework 3.0
SOAに対する典型的リアクション
サ
サービスの作り方
ビスの作り方、粒度の決め方が難しい
粒度の決め方が難しい
再利用できるとか、共通で利用できるサービスは、
そんなに簡単には作れないよね
SOAにつなげられる上流設計が出来る会社ってあ
るんですか？
見積もってもらうとWebアプリよりかなり高くなるので
なかなか踏み切れない
各社の製品が安心して使えるまで成熟しているのか
しら？
12
広すぎるSOAの影響範囲
EAとの接点
ITア－キテクチャー
プログラムの作り方
データへのアクセス方法
アプリケーションの開発・メンテナンス
ビジネス
ビジネス・プロセスとの接点
プロセスとの接点
要求・設計開発手法
経営との接点（KGI、KPIの実装）
13
本当のSOAって？？
企業のITシステムのア
企業のITシステムのアーキテクチャーや作り方を
キテクチャや作り方を、
『サービス』という見方で大きく変革するもの
純粋にIT的な目で見ても、プロセス、データ、サービ
純粋にIT的な目で見てもプロセスデタサビ
スのメタデータの整備や再構築へのロードマップ作
成など幅広さや現時点製品技術未熟さな
成など、幅の広さや現時点の製品技術の未熟さな
どでハードルはかなり高い（難しい）
真面目に実施しようと思うと、BPMやアジャイルを同
時に実行しないと、SOAだけでは正当化できない
14
未熟な技術・標準・製品の顛末
SOA技術は4年前にはまだ未熟だった
9 プログラミング・モデル、SCA、メタ情報、レジストリ・リポジ
トリ BPM/BPEL標準とツール
トリ、BPM/BPEL標準とツ
ル、セキュリティ
セキュリティー、性能、
性能
運用管理と変更管理、スキル、業界XML標準…..足りな
いものばかりだった
Cloud Computingのブームにも同様の傾向が
9 Cloud providers must work together to ensure that the challenges to
cloud adoption (security, integration, portability, interoperability,
governance/management, metering/monitoring) are addressed through
open collaboration and the appropriate use of standards.
O
Open
Cl
Cloud
d Manifestoから引用
M if t から引用
15
SOAと組み合わせるきもの
SOAと組み合わせるべきもの
目的
手段
SOA
アジリティー実現
再利用
組み合わせ開発
業務レベルのサービス部品
BPM
業務改善
分析ツールとシミュレーション
SOA実装
実装
アジャイル
迅速で正しい開発
短期の反復サイクル
利害関係者の継続的フィードバック
サービス部品
サ
ビス部品
目的は、アジリティ
目的は、アジリティーの実現
の実現
SOAは、情報システム全体を変化に俊敏
に追従できるように改革すること
16
SOAとBPMの関連性
関連性
SOAは、ITシステム全体を変化に俊敏に追
従できるようにすることである
9 ITアーキテクチャーをサービス中心に変えてゆくこ
とが重要となる
BPMは、広い視野で、かつ科学的な業務改
善であり、改善は変更を意図している
ビジネス目的から来る変更を、即座に実現でき
ビジネス目的から来る変更を即座に実現でき
るITシステムにするためには、IT部門内部の
体質改善や業務改善（BPM）が必要である
強いリーダーシップが必要
強いリ
ダシップが必要
17
CIOは不要？？
日本情報システムユーザー協会の2008年度企業IT動向調査2008より
大企業の8割がCIOまたはIT担当役員を設置して
大企業 8割がCIOまたはIT担当役員を設置し
いながら「CIO」という役職を明確に定義している企
業はわずか14％
9 理由としては「経営者がCIOを必要としていない」とする
大企業が実に65％を記録
「IT部門が経営層から期待されている領域」として
IT部門が経営層から期待されている領域」として
は、「ビジネスプロセスの変革」が約8割
2009年3月の追加調査では、IT予算の「増加」は
2009年3月の追加調査では IT予算の「増加」は
20％、「減少」は実に55％を記録し、特に製造業で
大幅に落ちている
18
不思議な調査結果
19
変化が一番多いところは？
ビジネスの現場、ビジネスプロセス Æ BPM
変化を正しく把握した情報がアクセスできること
9 現状をくまなく調査・記述したビジネスプロセス・モデル図
現状をくまなく調査記述したビジネプセ
デ図
9 定量的に把握されたKGIとKPI
変化対応のために必要な、メタ情報の連鎖
9 変更箇所の影響度合いが即分析できるか？
9 処理フローの変更を、最小のIT開発で対応できるか？
今までのITは、開発して動かすことが最優先
今までのITは開発して動かすことが最優先
9 ビジネス・エンティティーからデータ項目までのメタ情報
の関連性をオンラインリアルタイムで分析できない
の関連性を、オンライン・リアルタイムで分析できない
20
BPMからSOAへの流れ
（従来）
人手による
現状分析
要件定義
・人間系の仕組み変更で改善
・オフィス・ツールで改善
・コラボレーション・ツールで改善
コラボレションツルで改善
（BPM）
BPMツールで
定量的現状分析と
改善を模索
変更シミュレーション
IT開発によるシステム化で改善
プロセス
フロー図
（SOA）
ビジネスプロセス中心の
ITアーキテクチャー
SOAによる
システム化で改善
21
BPMのステップ
• BPMの概略ステップ
１．プロセス改善のゴールを企業レベルのストラテジーから決める
２．現在のプロセスと定量的なデータを調査し明確に記述する
３．データを分析し、すべての相関関係を洗い出す
４．分析したデータとゴールに基づき、あるべきプロセスを模索し
決定する（KGI、KPI、KAIの設定）
５．あるべきプロセスを適用し、改善結果（効果）を確認し、継続的
に効果を測定する
この改善ステップはDMAIC（Define, Measure,
この改善ステップはDMAIC（Define
Measure Analyze,
Analyze Improve,
Improve Control）の
名前でSix Sigmaの手法として知られている
9 6σは、元々モトローラで考案されGEで発展した統計学的な品質管理手法だが、現代ではビジネ
スマネジメントの戦略となっている
ス・マネージメントの戦略となっている
9 語源の6σは、例えば100万個の部品製作で、3.4個以内のばらつき（不良品）であることを意味
する
参照： http://en.wikipedia.org/wiki/Six_Sigma
22
ビジネス・プロセスとAPQC
APQC Webサイト
9 http://www.apqc.org/
• 元の名前はAmerican Productivity & Quality Center
• 1978年設立
PCF （Process
P ocess Classification Framework
F ame o k）
9 インダストリー共通のものと固有のもの
9 例えばサプライチェーンのプロセスを詳細に分析・記述し
てあり、KPIが詳細に定義されてある
9 BPMを始める場合に、欧米のプロセスの参照モデル的に
使える
23
代表的BPMメソドロジ
代表的BPMメソドロジー
発見の段階
開発の段階
新製品の設計
継続的な改善の段階
既存製品/プロセス/サービスの改善
既存製品/プロセス/サ
ビスの改善
DFLSS
Design for Lean Six Sigma
リーン開発
アジャイル
Six Sigmaによる設計
ソフトウェア
DMAIC
Define, Measure, Analyze, Improve, Control
リーン
TOC
Six Sigma
Theory of
Contrain
サービス/プロセス/製品
アジャイル
Seven
Basic Tools
無駄の
分析
XP
DMEDI
Define, Measure, Explore, Develop, Implement
TRIZ
IIDOV
Kaizen
BPM
Invent, Innovate, Develop, Optimization, Verification
24
アジャイルとBPM/SOAの関係
アジャイルなアプリケ
アジャイルなアプリケーション開発手法は
ション開発手法は、実はソフ
実はソフ
トウェア開発の世界でのBPM
SOAが単なるITの技術のことだけなら、従来のウ
SOAが単なるITの技術のことだけなら従来のウ
ォーターフォール型のシステム開発でも問題なく適
用できそうであるが現実には SOAの実現には
用できそうであるが、現実には、SOAの実現には、
技術以外の必須要素が存在する
9 ウォーターフォールの神話と現実
BPM/SOAの目的と、アジャイルの目的は同じと
考えるべき
25
ヨーロッパのWS事例
事例
• QCON LondonのPaul Fremantleの資料から
– http://pzf.fremantle.org/2009/03/three-soa-casehttp://pzf.fremantle.org/2009/03/three soa case
studies.html
9 デンマークのB2Gから始まりヨーロッパ全域に拡大中
9 PEPPOL（Pan-European Public eProcurement On-Line）
• http://peppol.eu
• デンマーク、ドイツ、フランス、オーストリア、イタリア、ノルウェ
ー、ハンガリー
• RASP（Reliable Asynchronous Secure Profile）
– SOAP 1.2
– WS-Security 1.1
– WS-ReliableMessaging 1.0
– WS-Addressing
WS Add
i
– HTTPとSMTPをサポート
26
RASPの実績
サポートされるプラットフォーム
9 .NET – WCF 3.0 ベース
9 Java – Apache Axis2 ベース
ス
利用実績
27
結論としては
今の状態では、製品は完璧からはほど遠いし、ベン
ダーのスキル・経験も頼れないし、フルセットのSOA
は何年経っても到底無理だろう
何年経
も到底無理
う
その意味では「SOA」は死語にしても良いだろう
しかし、サービス化などの疎結合のシステム・アーキ
しかしサビス化などの疎結合のシステムアキ
テクチャーへの変革への道筋は道理があるのでじっ
くりと取り組むしかない
くりと取り組むしかな
ユーザー企業は、むしろBPMに幅を広げ、同時に
業、
幅広、同時
ITスキル育成を図り、内製化を進めるべきだ
XML、Webサ
XML WebサービスのEDIへの適用を進めよう
ビスのEDIへの適用を進めよう
28

Download Report