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

－技術の空白と失われた10年－SOAやるべきかやめるべきかSOAやるべきかやめるべきか

2009年4月2009年4月

清水敏正

金融危機から始まった実体経済の混乱で、コスト削減だけが期待されるIT部門にはなりたくない。そう思いながらクラウドを検討しているのが最近のIT部門の管理者の方々でしょうか。

最新技術のつまみ食いで、世界は簡単に変わるのか？SOAが叫ばれてすでに４年以上。ほとんどの企業はSOAの実践に着手できていない現在 アプローチは正しかったのか？ほとんどの企業はSOAの実践に着手できていない現在、アプロ チは正しかったのか？SOAの最大の売り手である大手ミドルウェア・ベンダーの売り方やユーザー企業の受け止め方の双方に大きな誤りがあったのではないか？消化できない技術が溢れる一方、巣ごもり状態でじっと動かない大勢は、あた も失われた 年 う 技術 流れを眺 だ を作 だあたかも失われた10年のように、技術の流れを眺めているだけの層を作りだしている。

ユーザ企業のIT 部門管理者にとって、SOAをどう受け止めれば将来につながるのか？それともSOAはただ終わったのか？それともSOAはただ終わったのか？

1

SOAとクラウド&SaaSの関係

Anne Thomas Manes

参照したBlogs

2

参照したBlogshttp://www.ibm.com/developerworks/blogs/page/gcuomo?entry=le_morte_d_soa_la#commentshttp://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html

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” Once thought to be the savior of IT SOA instead turned into a greatapproaches that depend on services . Once thought to be the savior of 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 d i f SOA i t i f th IT i d t O i ti d t l d t k hit t lThe demise of SOA is tragic for the IT industry. Organizations desperately need to make architectural 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-premise and off-premise applications ) Although the word “SOA” iswithout enabling integration between on premise and off premise applications.) Although the word 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 the important stuff: architecture and services.pSuccessful 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

h f th t i SOA j t t f th t f ti ff t A d h ’ th t teach of these success stories, SOA was just one aspect of the transformation effort. And here’s the secret to 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 If you want spectacular gains then you need to make a

3

significantly reduced costs and increased agility. If you want spectacular 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.

日本のSOAは 離陸できたのか？日本のSOAは 離陸できたのか？

基本的な仕組みは理解されているだろうか

技術的見地からの分析

XMLスキーマを日常的に作成しているか？XMLスキ マを日常的に作成しているか？

WSDLを普通に作成しているか？

WS I BPやBSPを すでに使用しているか？WS-I BPやBSPを、すでに使用しているか？

BPELの良さを利用しているか？

サービスのメタ情報管理を行っているか？

他の技術との関連性からの分析他 技術 関 性 分析

業務分析と改善のBPMをIT部門が手伝っているか？

アジャイルな開発手法を内製で始めているか？アジャイルな開発手法を内製で始めているか？

4

センセーショナルな技術だけを追っていると

基礎体力がつかない基礎体力がつかない

ひょっとしてこの６年間でこの６年間で

技術の空白状態を技術の空白状態を作ってしまったのでは？

5

バブル崩壊と空白の10年

日経平均最高値日経平均最高値３８915円

路線価最高値

バブル崩壊

中東戦争とオイルシ クオイルショック

空白の10年

6

技術者個人で消化できない技術が...Linux

.NETActive Directory VISTA

Encina

DCE

インターネット

XML WebサービスActive Directory

OASIS

VISTAWCFWF

Java

Web WS-Transaction

WS-RM WS-I RSP

SCAJava

EJB

J2EE 1.3 J2EE 1.4J2EE 1.2 JavaEE 5

CORBA

Transaction

Web以外は投資できない今の時代今の時代

7

~‘90 ‘99 ‘00 ‘01 ‘02 ‘03 ‘04 ’05 ’06 ’07

消化されていない基本技術

XMLXML企業内情報のXML化、XMLスキーマ作成

W bサ ビスWebサービス

インターネット経由の企業間システム連携

BPELプログラム・フローは、Javaで書けばよく、BPELは不要？プ グラム フ は、Javaで書けばよく、BPELは不要？

抽象化・階層化の必要性、考え方が理解しにくい？

人間系・画面系のフローを中心に考えてしまい ビジネス人間系・画面系のフローを中心に考えてしまい、ビジネス・ロジックとの結合度を緩やかにできない？

呼び出せるサービスを作れていない呼び出せるサービスを作れていない

8

サービスの論理アーキテクチャー参考：

サービス・コンシューマー サービス・コンシューマーは、サービスのインタフェース情報からProxyコードなどを生成し それによ サ ビ を呼び出す

サービス・インタフェース

Proxy コード等を生成し、それによってサービスを呼び出す

サ ビス インタフェ ス

サービス名呼び出し先情報（URIなど）

実行内容（メタ情報）

生成

サービス・インタフェースの情報は、個別に配布したり 中央リポジトリ から検索し取り出し実行内容（メタ情報）

入出力データの格納場所入出力データの規定情報

エラー処理情報

配布したり、中央リポジトリーから検索し取り出したりすることで利用者が入手する。サービスのメタ情報により、利用目的に合致するかどうか等が判別できる。

実装コード

サービス実装

サ ビスの実装 ドは ンシ からは実装コ ドトランスポート・プロトコル

伝送特性セキュリティー特性ト ザクシ 特性

サービスの実装コードは、コンシューマーからは、見えない。 それにより、実装コードの変更などはコンシューマーに影響を与えない。しかし、各種の特性は、コンシューマーにとっても

トランザクション特性しかし、各種の特性は、コンシュ マ にとっても重要な情報なのでサービスのメタ情報に含めることが必須である。

サ ビス 他との依存関係が無く インタ ス情報だけでリモ ト呼び出し可能な

サービスの分類参考：

サービス

ポジ シ ンポジ ト リモ ト ンポジ シ ン

他との依存関係が無く、インタフェース情報だけでリモート呼び出し可能なプログラム・エンティティー

コンポジッッション コンポジットサービス

リモート・コンポジッション

単独でも実行可能なサービスを、ある目的で複数組み合わせて

複数のサービスを組み合わせて作った

システムの外にあるサービスを呼び出し組み合わせること

WSDLサービス

ローカル・コンポジッション複数組み合わせて意味を持たせること

組み合わせて作ったサービス

システムの内部にあるサービスを密に組み合わせること

RESTサービス

オーケストレーション

特殊な組み合わせで単純な組み合わせ以上の

フロー

BPELで定義されたシーケンス・フローで、任意のサービス（人間系の処理なども）を

Webサービスを使用した単一のサービス

単純な組み合わせ以上の高度な操作を行うこと

ルール・エンジン＆デシジョン・テーブル

組み込めるサービス

処理に必要な判断条件を分けてメディエーション

RESTを使用した単一のサービス

状態遷移エンジン

処理に必要な判断条件を分けて、外に出した形で実行できるサービス

目的のサービスにアクセスする際に、中間のどこかで各種の操作（ログ、分岐、別のサービスに振り向ける、など）を行い、付加価値を付ける。

外からのイベントによって状態が遷移する形式の処理フローを実行できるサービス

Handler PatternやESBパターンとも言われる。

サービスの実体 サービスの操作

サービス・コンポジッションの論理モデル参考：

Java/C++/PHP系

コンシューマー（SCAクライアント）

SpringBean

Aシステム Bシステム

WebサービスリモートEJB

SCA

業務アプリケーション

JMSREST

コンポジット

J2EE / レガシー

Webサービス

SCAドメイン

.NET系 Cシステム

Webサ ビス

WCF .NETアプリケーショ

ン

一般的コンシューマー

.NET Framework 3.0ン

SOAに対する典型的リアクション

サービスの作り方 粒度の決め方が難しいサ ビスの作り方、粒度の決め方が難しい

再利用できるとか、共通で利用できるサービスは、そんなに簡単には作れないよねそんなに簡単には作れないよね

SOAにつなげられる上流設計が出来る会社ってあるんですか？

見積もってもらうとWebアプリよりかなり高くなるので見積もってもらうとWebアプリよりかなり高くなるのでなかなか踏み切れない

各社の製品が安心して使えるまで成熟しているのか各社の製品が安心して使えるまで成熟しているのかしら？

12

広すぎるSOAの影響範囲広すぎるSOAの影響範囲

EAとの接点

ITア－キテクチャー

プログラムの作り方プログラムの作り方

データへのアクセス方法

アプリケーションの開発・メンテナンス

ビジネス・プロセスとの接点ビジネス プロセスとの接点

要求・設計開発手法

経営との接点（KGI、KPIの実装）

13

本当のSOAって？？

企業のITシステムのアーキテクチャーや作り方を企業のITシステムのア キテクチャ や作り方を、『サービス』という見方で大きく変革するもの

純粋にIT的な目で見ても プロセス デ タ サ ビ純粋にIT的な目で見ても、プロセス、データ、サービスのメタデータの整備や再構築へのロードマップ作成など 幅 広さや現時点 製品技術 未熟さな成など、幅の広さや現時点の製品技術の未熟さなどでハードルはかなり高い（難しい）

真面目に実施しようと思うと、BPMやアジャイルを同時に実行しないと、SOAだけでは正当化できない時に実行しないと、SOAだけでは正当化できない

14

未熟な技術・標準・製品の顛末

SOA技術は4年前にはまだ未熟だったSOA技術は4年前にはまだ未熟だった

プログラミング・モデル、SCA、メタ情報、レジストリ・リポジトリ BPM/BPEL標準とツール セキュリティー 性能トリ、BPM/BPEL標準とツ ル、セキュリティ 、性能、運用管理と変更管理、スキル、業界XML標準…..足りないものばかりだったいものばかりだった

Cloud Computingのブームにも同様の傾向がCloud providers must work together to ensure that the challenges toCloud providers must work together to ensure that the challenges tocloud adoption (security, integration, portability, interoperability,governance/management, metering/monitoring) are addressed throughopen collaboration and the appropriate use of standards.O Cl d M if t から引用Open Cloud Manifestoから引用

15

SOAと組み合わせるべきものSOAと組み合わせる きもの

目的 手段目的 手段

SOA アジリティー実現 再利用組み合わせ開発業務レベルのサービス部品

BPM 業務改善 分析ツールとシミュレーションSOA実装実装

アジャイル 迅速で正しい開発 短期の反復サイクル利害関係者の継続的フィードバックサービス部品

目的は、アジリティーの実現

サ ビス部品

目的は、アジリティ の実現

SOAは、情報システム全体を変化に俊敏に追従できるように改革することに追従できるように改革すること

16

SOAとBPMの関連性

SOAは、ITシステム全体を変化に俊敏に追

関連性

従できるようにすることである

ITアーキテクチャーをサービス中心に変えてゆくことが重要となる

BPMは、広い視野で、かつ科学的な業務改BPMは、広い視野で、かつ科学的な業務改善であり、改善は変更を意図している

ビジネス目的から来る変更を 即座に実現できビジネス目的から来る変更を、即座に実現できるITシステムにするためには、IT部門内部の体質改善や業務改善（BPM）が必要である体質改善や業務改善（BPM）が必要である

強いリーダーシップが必要

17

強いリ ダ シップが必要

CIOは不要？？

大企業 8割がCIOまたはIT担当役員を設置し

日本情報システムユーザー協会の2008年度 企業IT動向調査2008より

大企業の8割がCIOまたはIT担当役員を設置していながら「CIO」という役職を明確に定義している企業はわずか14％

理由としては「経営者がCIOを必要としていない」とする大企業が実に65％を記録

「IT部門が経営層から期待されている領域」としてIT部門が経営層から期待されている領域」としては、「ビジネスプロセスの変革」が約8割2009年3月の追加調査では IT予算の「増加」は2009年3月の追加調査では、IT予算の「増加」は20％、「減少」は実に55％を記録し、特に製造業で大幅に落ちている大幅に落ちている

18

不思議な調査結果

19

変化が一番多いところは？

ビジネスの現場、ビジネスプロセス BPMビジネスの現場、ビジネスプロセス BPM変化を正しく把握した情報がアクセスできること

現状をくまなく調査 記述したビジネ プ セ デ 図現状をくまなく調査・記述したビジネスプロセス・モデル図

定量的に把握されたKGIとKPI

変化対応のために必要な、メタ情報の連鎖

変更箇所の影響度合いが即分析できるか？変更箇所の影響度合いが即分析できるか？

処理フローの変更を、最小のIT開発で対応できるか？

今までのITは 開発して動かすことが最優先今までのITは、開発して動かすことが最優先

ビジネス・エンティティーからデータ項目までのメタ情報の関連性を オンライン リアルタイムで分析できないの関連性を、オンライン・リアルタイムで分析できない

20

BPMからSOAへの流れ

（従来）IT開発によるシステム化で改善人手による

現状分析

要件定義

（従来）

・人間系の仕組み変更で改善現状分析 ・人間系の仕組み変更で改善

・オフィス・ツールで改善

・コラボレーション・ツールで改善

（BPM）

コラボレ ション ツ ルで改善

（SOA）

BPMツールで定量的現状分析と

改善を模索

ビジネスプロセス中心のITアーキテクチャー

SOAによるプロセス

改善を模索 SOAによるシステム化で改善変更シミュレーション

フロー図

21

BPMのステップ

• BPMの概略ステップ

１．プロセス改善のゴールを企業レベルのストラテジーから決める

２．現在のプロセスと定量的なデータを調査し明確に記述する

３．データを分析し、すべての相関関係を洗い出す

４．分析したデータとゴールに基づき、あるべきプロセスを模索し決定する （KGI、KPI、KAIの設定）

５．あるべきプロセスを適用し、改善結果（効果）を確認し、継続的に効果を測定する

この改善ステップはDMAIC（Define Measure Analyze Improve Control）のこの改善ステップはDMAIC（Define, Measure, Analyze, Improve, Control）の名前でSix Sigmaの手法として知られている

6σは、元々モトローラで考案されGEで発展した統計学的な品質管理手法だが、現代ではビジネス・マネージメントの戦略となっている

22

ス マネ ジメントの戦略となっている

語源の6σは、例えば100万個の部品製作で、3.4個以内のばらつき（不良品）であることを意味する 参照： http://en.wikipedia.org/wiki/Six_Sigma

ビジネス・プロセスとAPQC

APQC WebサイトAPQC Webサイト

http://www.apqc.org/•元の名前はAmerican Productivity & Quality Center•元の名前はAmerican Productivity & Quality Center• 1978年設立

PCF （P ocess Classification F ame o k）PCF （Process Classification Framework）

インダストリー共通のものと固有のもの

例えばサプライチェーンのプロセスを詳細に分析・記述してあり、KPIが詳細に定義されてある

BPMを始める場合に、欧米のプロセスの参照モデル的に使える

23

代表的BPMメソドロジー代表的BPMメソドロジ

発見の段階 開発の段階 継続的な改善の段階

新製品の設計 既存製品/プロセス/サービスの改善新製品の設計

DFLSSDesign for Lean Six Sigma

既存製品/プロセス/サ ビスの改善

DMAICDefine, Measure, Analyze, Improve, Control

リーン開発 Six Sigmaによる設計

ソフトウェア サービス/プロセス/製品

リーン Six SigmaTOC

Theory ofContrain

アジャイルアジャイル

XP無駄の分析

SevenBasic Tools

DMEDIDefine, Measure, Explore, Develop, Implement

IIDOVTRIZKaizen

BPM

24

IIDOVInvent, Innovate, Develop, Optimization, Verification

TRIZ BPM

アジャイルとBPM/SOAの関係

アジャイルなアプリケーション開発手法は 実はソフアジャイルなアプリケ ション開発手法は、実はソフトウェア開発の世界でのBPMSOAが単なるITの技術のことだけなら 従来のウSOAが単なるITの技術のことだけなら、従来のウォーターフォール型のシステム開発でも問題なく適用できそうであるが 現実には SOAの実現には用できそうであるが、現実には、SOAの実現には、技術以外の必須要素が存在する

ウォーターフォールの神話と現実

BPM/SOAの目的と、アジャイルの目的は同じとBPM/SOAの目的と、アジャイルの目的は同じと考えるべき

25

ヨーロッパのWS事例事例• QCON LondonのPaul Fremantleの資料から

– http://pzf.fremantle.org/2009/03/three-soa-case-http://pzf.fremantle.org/2009/03/three soa casestudies.html

デンマークのB2Gから始まりヨーロッパ全域に拡大中

PEPPOL（Pan-European Public eProcurement On-Line）

• http://peppol.euhttp://peppol.eu•デンマーク、ドイツ、フランス、オーストリア、イタリア、ノルウェー、ハンガリー

• RASP（Reliable Asynchronous Secure Profile）– SOAP 1.2– WS-Security 1.1– WS-ReliableMessaging 1.0

WS Add i– WS-Addressing– HTTPとSMTPをサポート

26

RASPの実績

サポートされるプラットフォーム

.NET – WCF 3.0 ベース

Java – Apache Axis2 ベースJava Apache Axis2 ス

利用実績

27

結論としては

今の状態では、製品は完璧からはほど遠いし、ベンダーのスキル・経験も頼れないし、フルセットのSOAは何年経っても到底無理だろう何年経 も到底無理 う

その意味では「SOA」は死語にしても良いだろう

しかし サ ビス化などの疎結合のシステム ア キしかし、サービス化などの疎結合のシステム・アーキテクチャーへの変革への道筋は道理があるのでじっくりと取り組むしかなくりと取り組むしかない

ユーザー企業は、むしろBPMに幅を広げ、同時に業 、 幅 広 、同時ITスキル育成を図り、内製化を進めるべきだ

XML WebサービスのEDIへの適用を進めようXML、Webサ ビスのEDIへの適用を進めよう

28