相互運用性

概要

他のソフトウェアないしは、システムとの対話能力である。
異なるシステム同士が情報のやり取りしたり、相互に同じプロトコルで接続しあったり。
SoSが異なるSoSと情報を共有する際にもこの性質が求められる。

リスク

ただし問題点もある。
たとえば汚いデータ(要は不整合起きたままだったり、最新状態でないデータ)が、
もう片方のシステムに流れ出すと、汚染水のようにもう片方も浸食されてしまうリスク。
そのためにセキュリティ項目の完全性という非機能で、
データの正確さ・完全さを担保してあげることで、そのリスクを回避できると考えられる。
そこで重要なのが【不変オブジェクト】の思想である。
詳細については、別記事を参照してほしい。

背景

お互い情報を交換し合うことで、相手先で起こったアンチパターンや
サービスの質向上の成功事例などといったデータ利活用をするためにも、
他のシステムとの対話・情報交換は有力な手段である。

このことは、アナロジー思考で考えたら我々人間同士の情報交換でも同じ理屈が成り立つ。
自分一人・少人数の閉じた空間で学ぶよりも、積極的に外部との情報交換をする方が
文明は進化し、退化しにくいことは歴史でも物語っている。

したがって、この相互運用性が高いことによって嬉しいことは、
外部との交流にとってシステムの用途の選択肢を広げてくれて、
すでにある知見を有効活用することで開発期間やコストの削減に貢献することである。

どうすれば

わかりやすくシンプルな接続が理想ではある。
たとえば業界標準の規格プロトコルに従った設計にしておくなどである。
ただし、このわかりやすさを犠牲にしてでも接続先のシステム独自の規格に合わす必要がある場面もある。

下図のような自分の準拠する規格とは異なる規格を持った相手とつなぎたいという時である。
この場合図のように直接繋ぐってのはあまりよろしくない設計、
OCP(オープンクローズド原則)に反したものである。(下図のような構図)

なぜなら仮に相手先で規格を変えたりした場合に、こちら側までその影響を受けてしまう。

そこで接続先が自分のとこの規格と一致してないような場合、
もしくはこれから規格を変更することがほぼ確定していたりする場合には、
間に仲介を担ってくれるようなサブシステムの導入を検討することで、
OCPを守りつつ、接続したいシステムに問題(規格を変えるetc)が発生したとしても、
そのサブシステム内に影響範囲を閉じ込めるってことが可能になる。
要は、デザインパターンのAdapterパターンをシステムスケールの世界で適用てこと。
（下図を参照）

まとめ

Adapterパターンはシンプルさは少し下がってしまうと感じる。
そこでわたしならこのように使い分けたアーキテクチャ方針を立てる。

接続したい相手先のシステムはほぼ高確率で自分のとこの規格と一緒にするって場合には、
こんなAdapterパターンは適用しない。
逆に、相手先では規格を変更することが前向きに検討されているのであれば
Adapterパターンの適用を検討しておく。

こういう風にしておけばAdapterがあるかないかで
「こことここのシステムは同じ標準規格に従ってるのね」
「ああ、ここには仲介人がいるってことだから異なる規格の相手と連携したいってことなのね」
という風に容易に判断もできることになるので、
結果的にシンプルなアーキテクチャで相互運用性を実現できると考えられる。