SOAの実装設計を説明した出版物が多数あるがそのインタフェース（コントラクト）設計を重点的に説明したものはほとんど存在しないということから、インタフェース設計より実装設計の方が格段に重要でより注意を払う必要があるものだと思われているかもしれない。これを正当化する事実としてコントラクトは時間と共に変化してゆくものであること、またプロジェクトの開始時期に定義作業に時間をかけすぎるのはアジャイル開発手法の考えと矛盾するということがある。
Steven Jonesは 最近のポスト でこのよくある誤解に反論している：
私にとってそういう見かたは、非常に高品質のソースコードを作成しそれ自体がドキュメントに相当しているというならともかく、単にドキュメント化などやっていられないと言っていドキュメントを書かない偽アジャイル実践者のようなものである。これは基本的に、システムが行うことを話し合う前に全員システムが稼働可能になるまで待ちなさいと言っているようなものである。これは要件を変更し実装に合致させるということに等しい。ただ、私は要件が変化しないと言っている訳ではなく、ウォータフォール方式を推奨している訳でもない。私の言っているのは、SOAのプログラムにおける時間配分として、大部分の仕様開発・設計の時間はコントラクトとサービス間の相互動作に対して使われるべきで、サービスがどのようにコントラクトを実現するのかという設計にはそんなに時間をかけることはない、ということである。
SteveによるとSOA実装においてコントラクトが最も重要なものであるという理由がいくつか存在する:
- 他者は設計ではなくコントラクトに依存する。コントラクトを間違った場合のコストは提供者数に関連し指数関数的に増大する。正しいコントラクトがきちんと用意されている場合、人々は独立して開発作業を行うことが出来、それによりシステム開発スピードを大きく向上させると共にリスク低減につながる。
- テスト作業は設計ではなくコントラクトに基づいて行われる。コントラクトこそ厳密な仕様であり、設計が実現するものであり、すべての形態のテスト作業でベースとして用いられるべきものである
- 設計内容は変更されることがあるが、それもコントラクトの枠内でのことである
コントラクトが重要という考え方は新しいものではない。Dimuthu Leelarathneによれば:
最初にサービス間のコントラクトを設計しないなら、後でサービス間の複雑なサービス統合問題に直面することになるだろう。
実際のところ、良いサービスコントラクトの作成はたやすいものでなく、そのエンタプライズの中核ビジネスの深い理解が必要となる。サービスインタフェース設計に関して 充分確立されたアプローチ は存在するが、どちらかというと科学というよりアートである。そのため、開発者もソフトウェアベンダも通常は彼らがそうするよう（そして販売するよう）訓練されてきたことをしてしまう。それは、サービス実装の設計とコーディングである。Steveの意見:
... ITの世界では.. 外部インタフェースが最低でもある時間間隔において正しいことを確かめるような努力がほとんど行われない。コントラクトは時間と共に進化・変化することもあり、ここで慎重な言葉使いをするが、大抵の場合人が新しいコントラクトに移行して行くに際して古いコントラクトもサポートされていることが多い。これはコントラクトの方が設計よりはるかに長い生存期間を持つということを意味する。.. コントラクトこそが重要なものであり、設計は一時的なものである。
整合のとれたビジネスとIT に向けたSOA利用の普及活動を続けるにあたり、ビジネス要件と整合したサービスコントラクトの果たす役割は拡大し続けるだろう。