OSIに対する失望の原因としてOSIの仕様(スペック)そのものが魅力的でなかった事を述べましたが、もう一つの要因としてOSIの接続設定に非常に手間がかかったことが挙げられます。
むしろ、後者の接続に手間が掛かることこそが、圧倒的に重要な問題でした。
 |
| 姫路城の桜 |
OSIの仕様が魅力的でないと言うのは、当時の一般人、マスコミの評価であって、システム関係者や専門家にとっては、仮にそう言ったことが問題であったとすれば、わざわざ時間をかけて標準の実装を行い接続試験をするまでもなく、仕様そのもの策定段階で既に解っている事であり、接続実験後に改めて騒ぐ事はありません。
システムの専門家にとっては、標準化というのは、決して新しいアプリや機能を生み出すものではない事は、当たり前のことであり、十分承知していました。
システムの専門家のOSIに対する最大の期待は新たな機能やアプリの登場ではなく、接続の容易性の向上そのものにありました。
それを説明するためには、OSI誕生以前の異機種間のシステム接続に関する状況に触れた方が良いでしょう。
OSI誕生以前の状況
OSI誕生以前にも異機種間のネットワーク接続はありましたが、大変に手間と時間がかかるものでした。
あるユーザー企業が、例えばA社製とB社製の２種類のコンピュータを持っており、仮にA社製のプロトコルで両機を繋ぐと決定したとします。
そうすると、ユーザー企業はA社側に接続仕様を提出させて、それを元にB社側にインタフェースを実装させることになります。
そして、実装が終了すると、接続テストは、ユーザー企業のコンピュータ環境で、ユーザー企業のアプリケーションを使って行います。
こう言った作業だけでもユーザー企業にとっては手間の掛ることでしたが、
接続が上手く行った後も問題は続きます。
例えば、ソフトウェアのリリースアップやハードウェアのコンフィグ変更のタイミングで、あるいは、極端な例では、ある日突然、何のシステム変更もしたつもりはないのに障害が発生し始めるするなんて言うことがにありました。
そう言った場合、A社側は接続仕様に変更が無いこと、さらにA社側の後方互換性(バックワード・コンパチブル）の確認（例えば、A社製の既存の機器と、新しいリリース・レベルが接続して問題が無いか等の確認）を行い、B社側でも、仮に直接繋がっている機械に変更がなくても他の間接的に繋がっている後方システムに変更が無いかを調べます。
システムに何の変更も加えてないのに、ある日突然、障害が出始めると言うパターンは、往々にして、ユーザー側での使い方の変化や、ユーザー・データーの構成フローの変化が原因だったりするのですが、システム関係者はその変化を知らず、トレースをとって見て初めて発見されると言うケースがままありました。
このような作業をユーザー企業が中心となって行わなければならない訳で、極めてユーザー企業の負担が大きく、またメーカー側の負担も相当なものでした。
そして、OSIの登場以降は、ユーザーは単に「異機種間の接続はOSI仕様で」と指定すれば良いだけであり、メーカー側の余計な負担も無くなるはずでした。
