そごうソフトウェア研究所

SOA、開発プロセス、ITアーキテクチャなどについて書いています。Twitterやってます@rsogo

本ブログのSOA系のエントリをまとめました。

私は日本オラクルでコンサルティングに所属していて、SOAというキーワードで7年間ほど日本のプロジェクト現場で製品の導入方法論や、システム全体の分析・設計、運用・ガバナンスなどについてコンサルをやっていました。
もともとJavaのエンジニアだったので、アプリケーションサーバのチューニングや、トラブルシューティングなんかもやっていました。


ある日から担当している製品がOracle Application ServerからWebLogicに変わったり、Sunの買収にびっくりしたのが懐かしいです。
日本を代表する大企業のシステムを数多く担当させてもらい、優秀なプロジェクトメンバーの方々や、同僚と仕事ができて、本当にエンジニアとして幸せだったと思います。


2012年6月で日本オラクルを退社しましたので、振り返りも含めてSOA関連のエントリをまとめてみます。



ずいぶん昔の記事ですが、私のSOAに対する考え方です。
SOAが終わったのかどうか、に関する自分の考え

今でのこの考えは変わっていません。ことさらSOAという必要はなく、普通に機能の分析や、どこに何を配置するのかを1システムごとではなく全社的に考えられればそれで良いと思います。



とあるSOAのプロジェクトが終わったときに、現場でどのような苦労があったのか、またどのような気づきがあったのかを書いています。
SOA実装プロジェクトでの苦労と対策
SOA実装プロジェクトでの苦労と対策 その2

他のシステムとリアルタイムにやり取りしながら、ある処理を完結するというのはやはり、難易度は高いと思います。それは、技術的な面もありますし、うちが作ってないから〜という連携先の仕様がよく分からないというのもあります。
この苦労を味わうとガバナンスの重要性に気づきますよね。かってにAPIのインターフェイス変更するんじゃない!とか、うちのDBをどこか知らないシステムが参照してます!みたいな。



サービス化を利用者側のニーズ、サービス提供側のニーズ、どちらで始めるにしても、それぞれ超えないと行けない課題があります。
サービス化のインプリをどこから始めるか


データ統合、マスターデータ管理などは昔からどの企業も関心の高いテーマだと思います。データ統合のパターンごとに、サービスや、ESBを使ってどのようなことができるかを書いています。
SOAとデータベース(1)
SOAとデータベース(2)
SOAとデータベース(3)

この3つのエントリは再編集してOTNの記事にしてもらいました。
第1回 SOAと4つのソリューションパターンとその効果
第3回 SOAの4つの事例から見るデータマネジメントの本当