既に適用中の旧版システムがあって、新版システムで代がわりさせるときのみ、旧→新へのデータ流用/継続性の維持が要件になる程度である。
ソフトウェアとしてのシステムは、もともと自己最適化を目指すものであり、互換性が即システムの成立に役立つか、外部から互換性や接続性の制約が与えられないかぎり、これからも、その本質は変わらないだろう。
したがって互換性そのものは、事後の手立てとなるのが普通であり、これまでもそれで済んできている。
事後の手立てとしての互換性の取り方には、[図6.4.1 互換方式]に示すように、2通りがある。
(a) 中間フォマット
互換性を取りたい各種システムの合意で、図の(M)：標準の中間フォマットを決め、その(M)フォマットに対する変換システムを準備する。各システム毎に、○→(M)、(M)→○、行き帰り変換があるから、この方式での必要な全変換システム数は、システム数：nなら2nとなる。ただし、それぞれのシステムにとっては、自前で(M)対応だけ検討して1回準備さえすれば、他がどのようであろうと、nが増えようと関わりはなくなる。
(b) 1対1変換
標準は不要。互換性が必要なら各種システムが、相互に変換システムを準備する。ただし、それぞれのシステムは、自分以外の(n-1)個のシステムを調査検討して、すべてに個別に対応しなければならない。1対1のどちらが準備すべきか…も問題となる。この方式での必要な全変換システム数は、n(n-1)となる。
ここでn＞２、図はn=４なので、(a)2n=8、(b)n(n-1)=12通りの変換システムとなっている。nが少なければ、(a)と(b)の差は小さいが、nが増えると差は次第に大きくなる。n=40→(a)=80/(b)=1560
この理由から、一般には(a)の標準化が志向される。
