アプリケーションの肥大化は、なにも今に始まったことではない。アーキテクチャを問わず昔からずっと継続的に発生している。アプリケーションを機能単位で整理して区分けするようなことはメインフレームの時代から普通に行われてきた。ＩＴの利用が進むにつれて、ビジネスサイドからＩＴに要求される内容がどんどん増えていくのだから、システム側もそれに対応した開発や運用の方法を考えていかないと、パンクしてしまうからだ。
しかし、不幸なことに、オープン化、クライアント・サーバ化の流れの中で、アーキテクチャとそれを扱う技術者、カルチャーの変化に伴い、これまでの流れが一旦途切れてしまったように思う。ともかく、データベース以外のほとんどの処理を、ＰＣ上のアプリケーションに押し込んでしまったため、アプリケーションが複雑怪奇なものになってしまったわけだ。Ｗｅｂアプリケーション化で、これらの処理をサーバ側に戻した時も、同じようにサーバ側アプリは、当初は肥大化し、混とんとした状態になってしまったようだ。
しかし、Webアプリの良い点は、１ページの処理単位で、プログラムを分割できる点だ。１本のプログラムがスパゲティー化する危険性は低くなる。しかし、これは、また一方でこれまでのプログラミングに慣れたプログラマーにとっては、悩みのたねになる。１ページごとに処理が途切れるのだから、その流れの管理、つまりセッション管理を別枠で行う必要が生じるからである。これをきちんと考えてやらないと、処理の遷移が複雑になり、システムとしてのスパゲティー化をもたらしてしまう。おまけに、サーバは１台ではない。対象となる業務単位に冗長系を含む多数のサーバが置かれ、しかもその裏側には巨大なデータベースサーバが存在している。ビジネスロジックは依然としてユーザ向けの画面処理と一体化しており、プログラムが細分化されてしまったぶん、似て非なる処理があちこちに分散してしまって、システム全体としてのコードサイズはふくらんでしまう。おまけに、クライアント・サーバの時と同様に、同時利用者数分のアクセスがランダムにデータベースに集中することで、データベースの負荷は大きくなる一方だ。
結局のところ、クライアント・サーバ型からサーバ集中型に戻したことで、クライアント側の運用は楽になったものの、サーバサイドが肥大化、複雑化し、情報システム、とりわけその改良や保守・運用のボトルネックとなってしまったわけだ。特に、近年、会社の合併などでのシステム統合があいつぐ中、いつまでたってもシステム統合がうまくいかない背景のひとつにもなっている。それもそのはず、情報システムの作り方がバラバラでは、機能の共通化や統廃合ができず、とりあえずは、間でデータ交換をする連携プログラムを作ってお茶をにごしておいて、次の開発で一から作り直し・・・・となってしまうからである。経営統合による効率化という掛け声は、こと情報システムに関して言えば、むなしく聞こえる。
さて、これを解決するいい手段はないのだろうか。
（続く）
コメントする