TAKAが試したこと考えたこと

移行というと、レガシーシステムから利用しているデータを抽出して、新システムへデータを投入する「データ移行」が代表的です。 データ移行は、既存システムのデータスキーマ（抽出するデータフォーマット）と新システムのデータスキーマの形式・意味上の差異を把握し、その変換をおこなうことが主たる表の作業となります。 表と書いたのには理由があって、いわゆるデータクレジングという地道な作業が裏の作業としてあります。抽出したデータが矛盾のない、整合性のある、同じデータが複数ない（名寄せ）といった状態にして、移行プログラムで移行します。（既存、新システムとも止められないとなるとその差分の移行中のトランザクションデータをどうするといった問題もあったり、移行は一発でうまくいかないといったいろいろな問題もありますが、主たるという意味では上記のようにとらえることができます。） どうしても、データ移行に意識がいきがちな移行ですが、新システムを使った新しい業務がスムーズに実行できるように考える業務移行というのも一つの移行ですし、システム化計画を考える場合には、システムがどう移行させていくかという観点の「システム移行」が大事になります。システム移行は、システムをリプレースされていく中で安全にリプレースできる仕掛けを用意することを考える必要があります。システム間が複雑に関連しあっている場合にビッグバンでやらずに一部だけを置き換えて他のシステムに影響与えないように、一層、層を設けて影響をその層で吸収するように工夫します。 移行は難しいですね。

[続きを読む →]

Cloudera Distribution for Hadoopのインストール方法を拝見した。 コンフィグレーションを管理サイトで登録して、コンフィグレーション済みのパッケージングされたソフトをRPMとしてダウンロードしてインストールする。 Hadoopだからということではなく、コンフィグレーション管理のサービスが生まれ、クラウド上にカスタマイズされたソフトウェアをダウンロードしてクラウド上のノードで実行する。クラウドを移設することも可能になるだろうし、発展すれば、コンフィグレーションがプロファイルのようなものになり、どこで実行するのかはクラウドの価格やリソースなどで動的に変更できる。（データ移行もあるのでそう簡単ではないが） そういう新しい時代のソフトウェア管理方法を見たような気がして、はっとさせられた。もちろん、HPC的なクラウドも、ガｰトナーの言うところの、CDA（Context Deliver Achitecture）のコンテキスト情報を扱う上で、重要な要素であることは間違えないのでおろそかにできないのだが、今日は別のことを感じた。

[続きを読む →]

Amazon.comからKindleを買いました。洋書用で買ったのですが日本語を表示するHackがあったのでそれを導入したところ、日本語が読めました！ Hackを紹介していたBlogのYoshiさんありがとうございます。PDFを変換して日本語のPDFも読めるようになったので、手持ちの資料の持ち歩きたいものは入れておこう。

[続きを読む →]

ITILを考える上で青本（サービスサポート）ばかりを見ていたので、ちょっと反省し赤本（サービスデリバリ）について考えてみる。 まず、なぜ赤本を見なかったかを振り返ってみると、サービスレベル管理・IT財務管理あたりが話が大きくなりすぎている感を受けているからだった。 確かに話が大きいが、全体方針がないところで部分を考えても仕方がない面があるので確認するとサービスデリバリに沿って計画された内容を運用管理・運用オペレーションをおこない、その結果が反している場合、あるいは利用者から問合せ（クレーム、要望なども含む）があった場合にサービスサポートのプロセスを利用するという理解をした。 その流れを図にしたら以下のようになった。

[続きを読む →]

http://journal.mycom.co.jp/articles/2009/10/23/extdesigner/001.html この記事にでている内容で、サーバサイドのJSONやXMLをデータストアとして取り扱うところがあるので これに注目したい。

[続きを読む →]

全社レベルでシステム基盤を考える場合、階層化された各層を定義し、それぞれのパタンを検討することが重要となる、 ネットワーク、ハードウェア（サーバ）　/仮想化 ミドルウェア（AP、DBMS） アプリ基盤 システム間連携の基盤 それぞれの階層に標準を決定し、ガイドラインを明確にする。 全体構造とアプリケーションの構造が融合することが基幹システムのポイントだと思われる。

[続きを読む →]