System iを愛するすべての人のためのコミュニティサイト

「日経コンピュータ」2010年5月12日号の第一特集が「『オープンレガシー』を救え」というテーマになっています。
http://itpro.nikkeibp.co.jp/article/NC/20100507/347796/

上記リンクの（衝撃的な）冒頭です。

>>
　保守することもままならず塩漬けにされたオープンシステムが増えている。

　「早く安く作れる」「新しい技術が使える」「1社のベンダーに縛られない」――。1990年代から2000年代の初め、こうしたメリットを追って、多くの情報システム部門がメインフレームからオープンシステムへ開発の軸足を移した。特定の製品や技術に縛られることのない“自由なシステム”の誕生に、誰もが熱狂したはずだ。

　しかし今、オープンシステムのメリットは裏返しの格好となり、「作りすぎて保守できない」、「選んだ製品が廃れた」、「組み合わせの制約で更改しにくい」といった理由で塩漬け状態になり、情報システム部門を苦しめている。
<<

確かにひところ（今も?!）、「レガシー」を「オープン」で置き換える、といった"流れ"がありました。
いろんな"新技術"を自由に組み合わせて、ベンダーに縛られず、しかも"安く"できる、というのが歌い文句でした。
が、技術が時代にあわせて変化し、ハードウェアも OS もやはり進化していくのは避けられません。
それにつれて新たなセキュリティの脅威、ハードウェアの老朽化やパフォーマンス不足、サポート切れなのに今頃現れた不具合 … などなど、
いろんな問題が起きてきます。（やはり"作ったまま"で「時間よ止まれ」というわけにはいきません。。）
問題を解決し、解決策を検証し、大丈夫だと太鼓判を押すという面倒な仕事が、実はユーザー側に移ってしまっていた（だから自由度も高く価格も低い）、
ということを見過ごしていた面がなかったとは言えそうにありません。

ソフトウェア技術やハードウェア技術の組み合わせの検証がメーカーからユーザーの責任になり、
できあがったシステムを使う側でそれを適宜検証して更新していく仕組みがあらたに必要になったことの自覚があまりなかったのかもしれません。
できあがったシステムが「レガシー」化していってしまうのはやはり避けられないことだったのでしょう。

よく、作ってしまった施設の維持の問題がありますよね。費用が思いのほかかかってしまっている、とか修繕費用が心配だ、とかいったはなしを聞くことがありますが、
（たとえば、オリンピックで作った施設とかいわゆる"ハコモノ"などで。。）
あらかじめメインテナンスのコスト（手間やお金やそのタイミングなどなど）を考えておく必要がある、という観点では今も昔も箱物も IT も変わらないんですね。

それが変わらない以上おそらく、今まさしく作っている「オープン」についてもきちんと行く末を考えておかないと、早晩「レガシー」になってしまう危険性は減りません。
つまり、自己責任で組み合わせの検証や保証、組み合わせを含めたサポート切れの対応、問題判別などを行い続ける覚悟とその現実のワークロードを用意しておく必要があるわけです。
PC でも何かの拍子に入ってしまったドライバが悪さをしたり、何の影響かわからず挙動が変わってしまって「?」となることはそんなに珍しいことではありませんよね?!
作る時は一所懸命で考えられないかもしれませんが、時限爆弾のように、後から効いてくるボディブローのようにそんな問題が起こってくるわけです。。

最近出た「モジュール化の終焉―統合への回帰」という本にもありましたが、
今はばらばらの要素を自前で自由に組み合わせるその自由より、それを統合化して生まれたシナジー効果の方に"価値"がおかれている時代のような気もします。
メーカー側で統合化し稼動保証してくれれば、組み合わせの検証は必要ないわけですし、意味不明の問題が起きてどこに問い合わせていいか途方に暮れる、ということもなくなるので、システムを運用する上ではかなり助けになります。

まさしくその「メーカー側で統合化し稼動保証しているマシン」ということを訴求して Oracle Exadata などは出てきているわけですから、やはり大きな流れは「統合への回帰」なのかもしれませんね。
（以前、ちょっとシャレで書いた記事も案外、的を大幅にはずしているわけではないのかも?!）

ついでですが、われらが System i もそうした「メーカー側で統合化し稼動保証しているマシン」です。元祖と言っていいでしょう!!
Oracle Exadata はまだ出たばかりなので、Oracle のバージョンが変わったり、パッチが出たり、基盤となるテクノノロジが変わったりしたときにどういう手順になるのかまったくわかりませんが、System i には 20年以上の実績があるわけです。
基本となる通信が SNA から TCP/IP になり、チップも CISC から RISC になる中、データベースの最新機能を取り込み続け、さらには Java も動くようになっています。
この間、コマンドインターフェイスは変わりませんし、ユーザー作成アプリケーションはリコンパイルをすることもなく動き続けています。
こうした積み重ねの努力が、ユーザー主催である iSuc に毎年何千人も集まり続ける理由なんじゃないかと思います。

せっかく無から有を生み出すように作ったアプリ、いつまでも使い続け、成長させられるインフラであり続けたいものです。
それを助ける「統合化」への、進化し続けてきた答えが IBM i なんですね。

「日経コンピュータ」2010年5月12日号の特集「『オープンレガシー』を救え」、いろんな事例が載っていて興味深いです。
ぜひご一読を。

ちなみに、IBM i を採用するに至ったあるお客様の事例（「商談の軌跡」）も載っています。