問題に合わせてアジャイル、ウォーターフォールを工夫することが肝要だよね

アジャイルが否定したものを見直そう - arclamp

 

上記の記事を読んでいて少し考えるところがあったので。

 

SOAとウォーターフォール開発

とあるシステムの話です。

社会規模と呼ばれる様な巨大なサイズのシステムであり、そのデカイ図体を支えるためにSOA（Service Oriented Architecture）の考え方をベースとしたシステムで構築されてます。

 

それぞれのサービスは、サブシステムにより構築されるわけですが、サービス間の整合性や機能重複など、サービスとして効率的に開発するためには、アーキテクチャ設計をきちんと考えることが必要だったりして、トップダウン設計の色が濃い面があったりもします。きちんとしたドメイン設計を行わないと恐ろしいことになります。

で、こういった構造のシステムだったりすると複数の分散した機能を改修したりするわけで、全体整合性を保つ都合上、テストタイミングを揃えて一貫性のあるテストをしなければならない。

 

つまり、オッサンの経験の範囲ではあるのですが、SOA開発では、ウォーターフォール型開発をきちんと適応しないとうまくいかない場合がしばし発生するんですよね。

 

もうちょい言うと、ここでいうウォーターフォールも、古きよきガントチャートを使った進捗率片手にガリガリ進めるタイプ、と言うよりか、各サービスは自由に開発しながらも設計、テスト等の要所で同期を取る様なタイプになっていたりもします。

イメージにするとこんな感じ。

上記の開発手法（パラレルウォーターフォール*1）は、単一システム開発で適応するとかなり恐ろしいことになるんですけど、SOAみたいな形態だと綺麗にまとまるのが、システム開発では面白いところですね。

 

※まあ、業務ドメインを分割している都合上、上記のような開発スタイルを取らざるを得ないのが実情かなとは思いますが。。。

 

SOAとmicroservice、ウォーターフォールとアジャイル

さて、ここまで書いてふと思い出したのが、数日前見た以下の記事。

 

microservices_and_soa.md

 

類似する技術が流行ってきた起点を考えれば、多分SIerが抱える問題と同じような問題にウェブ業界の世界もぶつかったんだろうな、と思ってます。

  

さて、ここで元記事の話に戻るのですが。。。

 

ところで、SOAってSIerでは枯れてきた技術ではあるわけで、発生した問題についてもある程度見えたりもしてます。

前述のような、全体整合性を保つアーキテクチャ設計やテストが必要なため、ウォーターフォールが見直された、みたいな話もそう。

 

ということは、microservicesはSOAと類似した部分も多いことから、開発の中で抱える問題も似たようなものが今後発生するんじゃないのかな、なんて思うわけです。

つまり、microservicesの現場でも、ウォーターフォールも見直されるのだろうか？microservicesが巨大化したシステム、サービスを効率的に開発するために必要とされた背景で導入されたのであれば、SOAと同じくウォーターフォールが必要な場面が出てくるんじゃないだろうか？あるいは、ウォーターフォールと類似の概念が異なる言葉で語られるようになるのではないか？なんて思うわけです。

 

今回の記事を見て、ふと上記のような感想を思い出したわけです。

 

オマケ１：microservicesとSOAの相似性

上記の記事を含めて、microservicesが語られるとき、SOAとは違う、みたいな記載がありますけど。。。

 

実装例を見るに、10年以上前に構築された事例だとSOAミドルウェアを使わずに、MQとAPI（SOAPやWSDLなど）だけでESB作ってSOA構築するなんて構築例ありますし。メーカ系SIer以外では、自前で作る例が結構あるんじゃあないのかな。

SOAって実装例、開発方法が様々なんですよね。なので、構造や組織論などの枝葉を見ると同じだ、違うって話が出やすいんでしょう。

 

実際　Microservices　にあるmicroservicesアーキテクチャの特徴をみるに、SOA型のシステムのうち、重厚なミドルウェアが売り出される前にSIerオリジナル技術で構築されたSOAが備える特徴と一致しているのですね。アーキテクチャだけでなく、開発スタイルみたいな組織論としても、この手のSIerでは、独立したサービスを独立したチームが開発するみたいな感じの開発スタイルを取っており、一致してたりもするわけで。

 

SIerでもエンプラシステムが肥大化しすぎた結果、解決方法として分散型のアーキテクチャが必要となった背景より、上記のようなSOAを導入した経緯があります。

問題が似ていれば解決方法も似てくるわけで、SIerかWEB系か起点が違うだけの収斂進化みたいなもんだと思ってます。

 

オマケ２：SOA後のエンプラ技術の進化

SOAが導入されると、SIerでもより効率的な開発を目指して工夫を追加したりするんですよね。

例えば、従来型の３層アーキテクチャだと開発しづらい場面があるので、プレゼンテーション層、フロントアプリケーション層、データベース層にバックアプリケーション層、データバス層を追加した５層アーキテクチャに変えてみたりとか。

 

こういった技術についても、そのうち広がっていくか、もしくはSIerは技術情報をあまりオープンしないので、前述のように収斂進化の形で開発されるんじゃないかな、なんて思ってます。

 

違う方向に進化したら面白いので、引き続き技術動向は追っていきたいな、なんて思ってますね。

 

まとめ

 まあ、だらだらと書きましたが、結局のところ、技術って問題を解決するための手段であり、類似する問題があれば類似した技術が必要になるってのが重要なんじゃないかなと思います。

 

前記とは視点を変えてみると、SOAにより分割された小ドメインのオンライン中心のサービスは、特定業務ドメインに特化した小さなモノリシックなWEBシステムと見ることもできるわけで、そういったシステム特性があるのであればアジャイルが楽となる場面も多い。

 

そういった点では、以前の記事*2で紹介したハイブリッドアジャイルみたいな、ウォーターフォールとアジャイルの良いと取りを目指した開発手法などが有効だったりもする場面も多いです。

※オッサンも愛用してます。

 

というわけで、一番重要なことは何かといえば、問題に合わせてありとあらゆる工夫することが肝要だろうなあと思うわけです。

 

以上

  

 

SOA大全 サービス指向アーキテクチャ導入・設計・構築の指針

 

*1:サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ

*2:サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ