最近のIT動向に於いては「クラウド化」は欠かせません。持たない経営は益々加速することでしょう。
しかしながら、クラウド化に向けての課題は山積み。簡単に現有IT資産を移行することは容易ではありません。
中でも、COBOL資産を今でも活かしている企業は少なくありませんね。ITプラットフォームが急激に変化する中、その追随(単にOSや開発言語を最新版へ対応するためのバージョンアップなど)のためだけにIT投資を図るのは、経営者目線では理解し難いものでしょう。
そんな中、ふと目にしたのが「COBOLクラウド」の文字!PaaS(文末参照)として提供される、そういったもの。
コンピュータが普及し、活用されるにあたり、COBOLは登場から約50年間も愛され、現在でも多くの企業で活用されている開発言語。このCOBOLをクラウド化する動きが加速しているようです。
確かに、当時はコンピュータベンダが提供する「専用機(汎用機やオフコン)」上に稼働環境を載せるため、ハードウェア費用は高額です。昨今では、オープン系のOS環境上に擬似的に独自OSを載せ、そこでCOBOLプログラムを動作させています。
その稼働環境を雲の上、クラウド環境としてのデータセンタに配置された機器に置き、高額な機器投資費用を抑え、同時に、これに関わる保守料金の低減化も実現する。
データバックアップなどの管理要員や監視要員もシェアできますし、電源供給や耐震対策などの事業継続性の確保も容易です。
COBOL資産をオープン言語(.netやJavaなど)に置き換えるサービスもありますが、オープン化のメリットとしてはパッケージ製品などの適用を主体に考えねばなりません。単にCOBOL資産をオープン言語に置き換えても、今後も落ち着きを見せないシステムインフラや言語の動向に追随するのは困難ですから。
ますます、バラエティに富んだサービスが登場します。これらをどの領域に当てはめるかがポイントとなるでしょう。
●SaaS[Software as a Service]
→ ハードウェアからアプリケーションまでの全てを利用できる
●PaaS[Platform as a Service]
→ ハードウェアやOS、DB、開発ツール等の開発・実行環境を利用できる
●IaaS[Infrastructure as a Service]
→ ハードウェアとその稼動に必要なファシリティ等を利用できる
2011年6月26日日曜日
2011年6月19日日曜日
BC/DRに対する東西の温度差
東日本大震災以降、BC/DR[Business continuity/Disaster recovery](事業継続・災害対策)を見直す企業が増えているようです。
ITベンダーでも、これらに関わる製品の露出を高めたり、ソリューション提案に力が入っているようで、傾向として感じられます。
しかしながら、事業継続のセミナーの申し込み数は、東日本と西日本では温度差があるのも事実です。
今夏、東日本では各企業、大変な努力が強いられますが、この流れは中部を経て、西日本にも拡大されます。
事業継続は経営者責任にてトップダウンが成されるものです。IT領域に於ける対策も無視できません。
IT部門は、経営者が理解できる言葉で、コストとスコープを明確にした上で訴求することが求められます。
今一度、自社の事業継続を診断することをお勧めします。
ITベンダーでも、これらに関わる製品の露出を高めたり、ソリューション提案に力が入っているようで、傾向として感じられます。
しかしながら、事業継続のセミナーの申し込み数は、東日本と西日本では温度差があるのも事実です。
今夏、東日本では各企業、大変な努力が強いられますが、この流れは中部を経て、西日本にも拡大されます。
事業継続は経営者責任にてトップダウンが成されるものです。IT領域に於ける対策も無視できません。
IT部門は、経営者が理解できる言葉で、コストとスコープを明確にした上で訴求することが求められます。
今一度、自社の事業継続を診断することをお勧めします。
2011年6月12日日曜日
経営者不在のIT化は無い
今日は雨。ムシムシと寝苦しい季節がやってきましたね。まだ涼しいからマシですが。。。
さて、今回はパッケージ導入に関して。
業務アプリケーションは、世の中にピンからキリまで。そのため、自社の業務への適応性を勘案して、選択する必要があります。
ただ、以前にも書きましたが、汎用パッケージは全てではありませんが、商業的に規模の経済を狙うべく、ニッチな業界は意識していません。そのため、カスタマイズやアドオンを考慮せざるを得ません。
カスタマイズでは、ソフトウェア開発言語やOS(WindowsやLinuxなどのバージョン)動向、互換性を考慮しなければならず、また、アドオンする際も、元になっているパッケージとの連携は将来に渡って保証される訳ではありません。
業務を細分化し、適用に無理のないパッケージ選定を行うことは大切ですが、これを機に、業務プロセスを変更することも大切です。
但し、ボトムアップでは時間も掛かり、部門間のエゴが出ます。全社目線で最適な解を出すには、トップダウンが欠かせませんね。
さて、今回はパッケージ導入に関して。
業務アプリケーションは、世の中にピンからキリまで。そのため、自社の業務への適応性を勘案して、選択する必要があります。
ただ、以前にも書きましたが、汎用パッケージは全てではありませんが、商業的に規模の経済を狙うべく、ニッチな業界は意識していません。そのため、カスタマイズやアドオンを考慮せざるを得ません。
カスタマイズでは、ソフトウェア開発言語やOS(WindowsやLinuxなどのバージョン)動向、互換性を考慮しなければならず、また、アドオンする際も、元になっているパッケージとの連携は将来に渡って保証される訳ではありません。
業務を細分化し、適用に無理のないパッケージ選定を行うことは大切ですが、これを機に、業務プロセスを変更することも大切です。
但し、ボトムアップでは時間も掛かり、部門間のエゴが出ます。全社目線で最適な解を出すには、トップダウンが欠かせませんね。
2011年6月4日土曜日
登録:
投稿 (Atom)