自社システム（サーバ）と他社システムで連携を行う方法、Webの場合は主に２パターンに分かれます。
１つは時差があってもかまわないので、ＣＳＶデータの交換で処理をする方法です。
１日に１回、または１時間に１回などルールを決めて、自社サーバ（データベース）に蓄積してある情報をＣＳＶ形式で書き出しを行います。
その書き出されたＣＳＶを連携会社のサーバに自動で渡し、取り込みを行ってサービスを展開してもらいます。
この方法であれば、リアルタイム性は損なわれますが、お互いの責任範囲がかなり明確になるので、開発時のトラブルは発生しにくいです。
お互いに書き出すＣＳＶの項目があっているか、形式があっているのかを判断するだけなので、文系人間にも一目瞭然です。
で、リアルタイム性を追求した場合、ＡＰＩ（ＸＭＬ）を使った方法があります。
ＡＰＩには規格があるので、まずはどのような規格、例えばＡｔｏｍで進めるとか連携会社と決めます。
そして、それに沿った形で提供元がドキュメントを作成します。
リクエストした場合（情報を欲しているサーバから情報提供を依頼した場合）に、どのような形でレスポンスを返すか（求められたサーバーからどのように情報を返すか）を決めます。
リクエストが正しければ、ページ番号や個人情報を含んだＸＭＬを返すし、リクエストが間違っていれば、エラーのＸＭＬを返す等を決めます。
また、そもそもリクエストができていなければ、何も返せないという場合もあります。
これらをドキュメント上でしっかりと決めて、お互いに納得してから開発に入るのが通常です。
しかし、実際にＡＰＩ（ＸＭＬ）連携を行う場合、提供先と提供元では、開発方法の文化に違いがあったりするので、うまくいかないケースが多いです。
最初の責任範囲を決めておかないと、特に提供元は「ここまでやったらこちらは開発終了です！」ということを決めておかないと、提供先から「うまく連携できないからこっちに合わせろ！」みたいなことを言われて、仕様変更したりだとか、うまく動かないとケチをつけられることがあります。
提供元の立場からすれば動いているが、提供先の立場からすれば動いていない。
では、この溝を埋めるのはどうしたらよいのか・・・。
提供元が提供先のサーバにアクセスして、エラーログを解析してアドバイスしたりします。
しかし、これで提供先が動くのであれば、提供元の方があきらかに技術レベルが上であったということの証明になってしまい、提供先の技術者に精神的なダメージを与えてしまいます。
また、提供元も無駄な時間、想定外の時間をさくことになります。
すでにプロジェクトはＡＰＩ（ＸＭＬ）の開発ではなく、先方の検証テストに参加し、提供先のプログラムを解析しながら、提供先のサービスを動かしてあげるということになっています。
なので、別途費用となったりするわけです。
この責任範囲をきっちりと決めるということが、プロジェクトの進行、またリスクヘッジになり、Webディレクターには必要不可欠な要素になります。
