進化型SOA

SOAはアジャイルアプローチで実現できるか？

SOA（サービス指向の曖昧性）という混沌とした世界に深入りすることはあまりしませんが、この質問は（何らかの形で）よく聞かれるので、持論を述べる価値はあるでしょう。

私が初めてアジャイルソフトウェア開発（エクストリームプログラミングの形で）に出会ったとき、最も悩ましいと思ったのは、ソフトウェア設計へのアプローチでした。多くの人と同様に、私はソフトウェアはプログラミングの前に設計されるべきだという考え方に慣れていましたが、XPは設計の無知を意図的に受け入れているように見えました。2000年に最初のアジャイル/XPカンファレンスの閉会の基調講演を依頼され、考えをまとめるために設計は死んだか？というエッセイを書きました。このエッセイは、アジャイルの世界における設計の運命を考察したものです。

私は今でもこのエッセイを誇りに思っており、今日でも読む価値があると思っています。しかし、このBlikiのエントリでは要約します。私は、ソフトウェア設計には、計画型と進化型の2つの推進アプローチがあると述べました。計画型設計は、ソフトウェアの設計を1つのフェーズで行い、その後で構築（プログラミング）します。この場合、構築を開始した後に設計を変更するのは困難です。進化型設計は、かなりのプログラミングを行った後でも、設計を定期的に変更することを前提としています。私は、XPのプラクティスは進化型設計への規律あるアプローチを提供し、人々が認識していたよりもはるかに実用的になっていると結論付けました。この変化はソフトウェア設計をなくしたわけではありませんが（設計は死んでいません）、設計に対する考え方を変えました。

SOAの文脈における計画型設計の論拠は、相互接続され、疎結合されたシステムのWebを構築しているということです。この状況では、各システムは、そのサービスを公開インターフェースとして企業全体に提供しています。公開インターフェースは変更が難しいため、変更する必要がないように、計画型設計によって正しく設計する必要があります。計画型設計は、ほとんどの組織で見られる混沌的なシステム相互接続への対応でもあります。この混沌は設計のまずさの結果であるため、より計画的な設計によってこれが将来起こるのを防ぐことができると感じられています。

進化型設計は、アジャイル手法の本質的な側面です。アジャイル手法の重要な基盤の1つは、変化を処理し、むしろ歓迎したいという願望です。計画型設計は変化が難しいと仮定し、変化がどこで起こるかを予測しようとします。変化が予測された範囲内で発生すれば簡単ですが、その範囲外で発生すると、運が悪くなります。アジャイル思考は、予測不可能な変化は避けられないと仮定し、制御された方法でそれを可能にするよう試みます。

そのため、SOA、あるいはその他の設計コンテキストを見るとき、私が根本的に問う質問は、「変化は予測可能か？」ということです。変化が予測可能な場合にのみ、計画型設計アプローチは有効です。私の感覚では、単一のアプリケーションのコンテキスト内で予測可能性が難しい場合、企業全体では二重に難しいということです。予測不可能なコンテキストで計画型設計を使用すると、計画がどれほど優れていても、予測不可能な変化によって計画が損なわれ、現在と同じ混乱に陥ることがわかります。しかし、通常は、計画型設計には大きなサンクコストがかかるため、混乱はさらに悪化します。これは、特に市場投入までの時間が重要な場合、SOAの取り組みがもたらすはずのビジネス価値を容易に低下させる可能性があります。

その結果、私たちは覚悟を決めて、この疎結合のコンテキストで進化型設計を行う方法を見つけなければならないと思います。結局のところ、疎結合のポイントは、変更を容易にすることです。コンシューマ主導契約などのアイデアで、変化の観点から契約について考えることが中心となります。

この方向性は、ジム・ウェバーのゲリラSOAの概念のようなものにつながります。これは、ビジネス価値を生み出すことに焦点を当てた小さなステップを使用してSOAを構築します。ビジネス価値を生み出すことがすべてであるため、これは投資収益率を大幅に向上させる道筋を提供します。それは確かに、お客様が評価するアプローチです。

進化型設計はSOAの規模にまで拡張できるでしょうか？私の見解では、大規模なSOAの取り組みよりもはるかに大きな規模での実例があります。それはWeb自体です。Webは、非常に疎結合で、多くの予測不可能な変化に基づいて構築されています。多くの点で、それは混乱していますが、毎日多くの人々に真の価値を提供している、機能する混乱です。