MomentumSIのCEOであるJeff Schneider氏はITサイロ（SOAになってないITのこと。サイロは貯蔵庫のことで、中身を外から隔離していることから）とサービス指向アーキテクチャ（SOA）との間の関係性を定義しようと試みている(リンク)。
システムあるいは情報レポジトリとしてのサイロは企業のある部分についての問題を解決すると思いますが、一方で同じような問題を抱える他の部分を置き去りにしてしまいます。サイロはシステムやビジネスルールやデータの重複を引き起こすのです。
この関係を探ったのは氏が初めてではない。SAP Labsでリード規格アーキテクトを務めるDave Frankel氏はSOAをこのように定義している(リンク)。
SOA はIT資産を疎結合のコンポーネントへと再組織化することです。SOA環境の基本的な部分を構成するツールを使ってつくられた複合アプリケーションは、それぞれの方法で複数のコンポーネントを統合します。それが広がることで最終的には統合を妨げる硬直したサイロを解体することになります。サイロは複数のレベルでデータの統合やクレンジングが必要となるため、保守と運用のコストが高くなることになります。往々に、サイロは悪と言えるでしょう。
それより最近だと、Joe Mckendrick氏がカナダの農業ビジネス向けの金融サービスをおこなうFarm Credit Canada（FCC）がどのようにSOAの手法を取り入れてサイロ組織の再構築を行ったかを詳しくのべたレポート(リンク)を紹介した。特定のビジネス機能をもつアプリケーションのためのそれぞれのサイロは、「サービス指向」モデルへと再構築され、そこではSOAの原則に従ってアプリケーションが構築されていく。彼はこのレポートからの引用を使って、このレポートが6つのステップで構成されると述べた。
1) CEO主導：「CEOが企業文化の変化を先導し、その行動は顧客指向の組織を作ろうという彼のビジョンに支えられていた。」
2) プロセス改革：「優れた顧客サービスを提供できるようなシステムと企業プロセスを導入するために何が必要なのかに焦点を当てた。」
3) IT自体が変化した：「CIOはIT部隊の現状分析に取り掛かり、それが終わるまでは全ての現行ITプロジェクトが凍結されることになった。」サイロ型の方法を捨ててSOAの原則に合うアーキテクチャ指向の方法が採られた。
4) 概念実証が「慎重に選ばれたSOAを伴うビジネスプロセスを実装することで」おこなわれた。
5) ガバナンス：「この組織は他のプロセスを詳細に再設計することを始め、プロセス主導型IT組織を経営するためのガバナンスに関する問題に取り組んでいた」
6) IT機能とそのテクノロジを変更する利点がはっきりと示された。ビジネスとITとの連携の改善から再利用可能なIT資産の開発にいたるまで、CIOがメリットの広さを調べて確認した。
Jeff Schneider氏は一般的にはこうであると述べている。
ほとんどの大組織は多くのサイロを持っていますが、そのようなサイロが存在する理由には次のようなものが含まれます。
- IT予算は部署ごとに割り当てられ、それぞれのところで独自のサイロ型システムが購入されたり構築されたりした
- M&Aによりサイロシステムが重複することになった
- 企業全体を見通したり企業全体で計画しなかったせいで望まなかったサイロができてしまった
･･･（さらに）このような企業は「サイロ分析」を行わないのです。
彼の記事ではその分析を行うための実践的なステップを紹介している。
- 自分たちのサイロはなにか？
- そのサイロの正当な理由はあるか？
- どのサイロが最期まであってほしいと思うか？
- どのサイロを実際に（政治的に資金的になど）潰すことができるか？
- SOAは「サイロサービス」をもたらすか？
このリストでキーとなる問いが最後の「SOAはサイロサービスをもたらすか？」だ。Jenny Ang氏と彼女の仲間はすでにこのことを潜在的なSOAアンチパターン(リンク)としてまとめている。
この年の初めにEric Roch氏も同じ問いを投げかけていた(リンク)
SOAがあれば事業部隊の中に新しいサイロを生み出さないということを保証できるものでしょうか？
彼は次のことを推奨している。
- 戦略的なサービスの青写真を作ること（将来のビジネスサービスのカタログ）
- SOAの支援者、各アプリケーションシステムのリードアーキテクト、エンタープライズアーキテクトから成る横断的なSOA運営委員会を組織する
Joe McKendrick氏はこの問題を解決する相互に関係しあう2つのレベルがあるとしている(リンク)。
- まず、テクノロジのレベルにおける連携です。4つにつき1つの企業はすでに複数のESBや仲介サーバを連携させるインフラへと移行しています。単一のESBによって成長するSOAを管理しようと試みても長くは続かないでしょう。
- そして、ビジネスのレベルにおけるガバナンスです。効果的なガバナンスによりそれぞれ違いがはっきりとした、かつ連携しあうサービスを生みます。
氏はこう締めくくる。
サイロ分析はビジネスアナリスト、アーキテクト、ディベロッパ、ガバナンス専門家の意識にしっかり根付かないといけません。次の世代に伝えるのに失敗すれば、Javaで書かれたものをRubyで書いたりと、より多くのsiloを生み出すことになるでしょう･･･
彼はいくつかの重要な問いを提起した。それは全てのSOAガバナンスをおこなう組織がどこかの時点で問うべきものだ。SOAの実装をおこなう時にサイロを考慮しているだろうか？実装したサービスによって新しいサイロができることを止めることに成功しただろうか？BPM（ビジネスプロセス管理）やMDM（マスタデータ管理）戦略をサイロに横断させるにはどうすればいいだろうか？