チェンジ＆レジリエンスが出発点. そしてテスト・ケース縮減への拘り
JEANSとeCloud研究会の精神はこの図を出発点にしています。
システムは生き物ですから常に修正・変更が入っているわけですが、そのために、経時的に劣化していくのは宿命です。
どんなに整合性をとってスタートしたシステムでも、継ぎはぎだらけになっていく。 トップダウンの限界でしょうか。
それでもシステム屋は頑張る。慈愛に満ちた観音様のようなフォローで、システム・ライフサイクルを延ばしに延ばす。
特に基幹系システムでは、おいそれと捨てきれない非活性化したレギュレーションや企業ルールが休火山になっています。
もう何年前になるのでしょうか、某銀行の日本市場最大級の統合プロジェクトが成功裏に終わりましたが、その前後で上図のような明示的な版化を発想し、IBM科学アカデミーの勉強会に持ち込んで議論を無理やり作り出したりもしていました。
その議論の中から、ソフトウェア・アプライアンス化の構想も生まれてきました。
それはお客様プロジェクトとは何の関係もない、勝手なアーキテクチャ志向の勉強会でした。
ここで某プロジェクトを全く無関係の第三者が勝手に引き合いに出すことの非礼をお許しください。
某プロジェクトは100%の目標達成で終わりましたが、先ず、そのプロジェクトの完璧さに小生は最大級の敬意を表したいと思います。
一方で、小生は外から見ていただけで無責任な発言になりますが、同じ方法はもう２度とできないだろうな、と考えたりしていました。
ちょっとした一部の躓きさえ許されない中での、大変困難なプロジェクトは、そう何度も成功させることは難しいと思います。
それではこれからのグローバル化が進む中で、M&Aやシステム統合・変革の迅速化、柔軟さの課題解決の方法は何なのだろうか。
実はこのプロジェクトの話が持ち上がった時、小生はIBMの担当SEに、SOAで提案したら、と吹き込んでいました。
小生のIBMへのSOA推進言いだしっぺの動機は、そもそもこういうケースに対応するためにこそあったのですから当然です。
しかし、システム統合のアーキテクチャのIBM側提案は片寄せに決まりました。
提案は北城さんの鶴の一声で決まったようですが、小生も納得しています。
この超重要プロジェクトでは当然の選択だろうと思いました。SOAなんて未だ影も形も無かったのですから。
それまでも、北城さんとは Sysplexの構想やLinux/z などの導入時点で盛んに”言い争い”ました。
北城さんは立場も含めて冒険主義者ではありません。大局的なシステム・センスに大変強い反面、堅実なステップを重視します。
一方で小生は”エエカゲン”に物事を置いたままで、飛び込んでいく危うさを持っています。要は”気合や”の感性一本です。
その意味で、誰が真のリーダーで誰が駒なのかは、はっきりしていますよね。
さて、小生は技術最前線での威力偵察が大変好みです。
しかし当時既に現場の修羅場に口出すにはもう老いぼれ過ぎていて、当事者能力を無くしていた小生は、全く深入りしませんでした。
しかし今思うに、仮定の話など何の価値もありませんし、不埒千万な議論になりますが、仮に、
当プロジェクトをSOAで実施し、成功していれば、SOAも離陸し、世界のリーダーとして日本ITの展開も大きく変わっていたでしょう。
できる、といえばできそうですし、できない、といえばやっぱり無理なような。システム創り、造り、とはそういうものなのでしょうね。
いずれにしても、小生の追い求めるシステム観は、過去・現在・未来をどうやったら無理なく整合させることが出来るのか、保守と革新のせめぎ合いでのアウフヘーベン（古い！）の実現を模索してきたようです。ライフワークのようになってしまいました。
Sysplexやネットワーク・コンピューティングでは冒険に自分で手を染めましたが、SOAではもうその気力を無くしていました。
で、最後のご奉公のような形で彷徨っている、その集大成のようなものが、"Programming Model Agnostic" の主張です。
過去・現在・未来を通したシステム構築と”システム・ライフサイクル”の上手な構成のための大風呂敷です。
IT屋がいう”Agnostic" というのは、まぁぁ精神論みたいなもので、大筋であんまり気にしなくっていいよね、という感じでしょうか。
しかしこれこそが基幹系を預かるガチンコのIT屋さんからみれば、許しがたい虚言・妄言ということになってしまいます。
特にぎりぎりの信頼性が要求されるシステムでは、中途半端な自動化などもっての外なのは理解できます。
小生にはガチンコのIT屋の能力がありません。
ホメオトシスのスレッドでも書きましたように、若輩のころには車の生産現場を半日止めた実績（？）もあるほどです。
しかし一方で、北城さんが作り上げた金融系のお客様ミラー・システムに、マネージャとして直接・間接に関わったこともあります。
北城さんは営業部長時代に、お客様システムの冒険を担保するために数十億円に上る完全ミラーのテスト・ベッドを用意していました。
そこで頭角を現したのがあの河野文豊さんですよね。。。おっと、ここは研究スレッドでした。この辺の事情は別途ということで。
いずれにしても、小生もPTF(Program temporary fix)やPTF ErrorなどのテストやPD(Problem Determination)の修羅場を知っています。
また、違うタスクではソフトウェアの構造分析やトレーサビリティのツールを設計・開発したこともあります。ずぶの素人でもありません。
仮想化とアプライアンス化で出発.
回りくどい文章が続きましたが、基本概念は単純です。
アプリケーションやミドルウェアなどをvmイメージ単位、仮想アプライアンス（eVA）で原則として塩漬けにしつつバージョン管理をする。
構想のフィージビリティは、仮想化とクラウドの運用管理システム、そしてこれから世に出てくるであろう各社のイメージ管理のツール群を基に構成するわけですから、今までのHW実機上での塩漬けとは違って十分にあると考えています。
さらにeVAは、SOAの受け皿のクラウド・サービスとなり、アプリケーションはソリューション統合体としての部分に分解されていきます。
運用系の変更管理だけではなく、eVAによる版管理はSOAのコモナリティとバリアビリティという基本理念の実態にも深く関わります。
アーキテクチャとしてはリンク・アーキテクチャとして分散していきます。
一方で、アプリケーションやミドルウェアを積極的に版化して其々を塩漬けにするためには、いろんな課題を解決する必要があります。
構成されるSW製品のサポート期限切れの問題、課金の問題、プラットフォームやデータをeVAから切り離しやすくすること、システム側に運用スクリプトなどの作りこみを極力行わないこと、パーフォーマンス劣化などなど、出来ない論が噴出することになります。
ですから、ユーザー主導のアーキテクチャとして構想・構築していこう、ということです。
お手本はあるわけです。自然界の生命システムでの種の保存と適応ですね。
eCloud研究会のスタートの議論、”仮想化とアプライアンス化の視座”です。
そして重要なのは、何度も記述していますように、クラウドを飛翔させるvmイメージ管理とその将来像のビジョンの共有です。
|
