2012年2月9日

エンタープライズ・モビリティ 走り出す前に考えるべきこと 2

経営品質向上に結びつく開発プラットフォームの要件

企業の、経営品質を高めるためのモビリティの取り組みにおいて、肝になるのは 
①WindowsOSおよび複数のモバイルOS上で動作する、
②企業システムと連携するデータベース・アプリケーションを、
③開発・運用コストを抑え、セキュリティを高めて実装・運用していくことにある。
在来型の、クライアント・サーバにプログラムが分断される開発プラットフォームは構造的にこれら要件を満たせない。マルチOSに対応し、フルセット開発が可能なプラットフォームが必要とされている。



本論では、モビリティを高めるためにシステムに求められる要件を明確化し、複数の開発プラットフォームが要件にどの程度整合するのかを見ていこう。

ホワイトカラーのモビリティを高める6つのシステム化要件
本論では、企業におけるエンタープライズ・モビリティの目的を、ホワイトカラーの生産性向上に置く。工場システムほかロジスティクス系現業システムへの適応は取り上げない。
図式的にいうと、ホワイトカラーの生産性向上は、顧客へのサービス品質とレスポンスの向上、および、企業システムのデータ鮮度・精度の向上をもたらし、以って、経営決定の質の向上、ひいては経営品質の向上に結びついていく。




さて、ホワイトカラーの生産性を向上させるため、企業のエンタープライズ・モビリティを高めるためシステムに求められる要件は、次の6つに集約できる。
まず、4つの利用要件を、優先順位に沿って挙げてみよう。


(1)業務処理をおこなえること
そのためには、一定規模で動作するデータベース・アプリケーションである必要がある。クライアント単体で動作するモバイル・アプリケーションは、ホビーでこそあれ、企業用途には適さない。


(2)場所やデバイス種類による利用制約がないこと
エンタープライズ・モビリティはモバイルOS対応を考えるだけでは十分でない。他方、企業アプリケーション開発はWindowsクライアントだけを前提とするものでは最早ありえない。複数のモバイルOS、および、 WindowsOSで動作する必要がある。


(3)モバイルの特性を活かすためのユーザビリティを備えること
?    基幹系をはじめとした企業システムとの連携がなされていること。社内と同等な情報に常に接することができることは、ビジネスモバイルの必須要件といえる。
?    短時間で処理できるよう、役割に特化したUI(ユーザ・インタフェース)を備えること。モバイルユーザは、画面への滞留時間が短いため、必要な処理をすぐ行える必要がある。携帯しているため、アラート等によるプッシュ型通知も有効だ。


(4)モバイルならではの利用方法を開拓できること
デバイスの機能(電話・GPS・カメラなど)との連携が可能なこと。これにより、電話受信をトリガーにした業務処理が可能になる、等。ただし、この要件は、ビジネスモバイルが、コンシューマライゼーションの洗礼をうけてより深化していくなかで漸次明確化していくものと考えられる。当面の優先順位は高くなくてよいだろう。

一方、管理要件は次の2つに収斂されるだろう。
(5)開発・運用コスト
開発・運用コストの多寡は、開発プラットフォームに依存する。複数OSに対応する利用要件の重要性は高く、モバイルOSのアップデートはWindowsOSと比べて頻繁だ。これを勘案すると、開発はもとより、小改修を含めた運用コストを抑えることを、仕組み的に担保しておく必要があろう。企業のシステム管理責任者にとって、最も重要度の高いイシューといえる。


(6)セキュリティが確保されること
デバイスそのもののセキュリティ、および、通信セキュリティを考慮する必要がある。リスク評価と統制手段の決定が必要という意味で、情報セキュリティの範疇で対処されるべき 。開発側からすると、データ・通信の暗号化、および、認証が基本点になろうか。認証は、企業システムとの連携の枠内で捉えることができよう。
以上から、開発プラットフォームが満たすべき要件は次のようにまとめられよう。



要件の区分 要件内容 優先順位
利用要件 データベース・アプリケーションを制作できること ●必須
利用要件 複数のモバイルOS+ WindowsOSで動作するアプリケーションを制作できること ◎優先
利用・管理要件 企業システムと連携できること(データおよび認証) ◎優先
利用要件 役割に特化したUIを開発できること ○中位
利用要件 デバイス機能(電話・GPS・カメラ等)と連携できること △下位
管理要件 開発・運用コストを抑える仕組みを持っていること ◎優先
管理要件 データ・通信を暗号化できること ◎優先


在来の開発プラットフォームを評価する
では、既存の開発プラットフォームはこれら要件を満足するだろうか。各プラットフォームを簡単にレビューしていこう。特定製品を挙げていないため控えたが、みなさんで独自に加重加点評価を試みるのもよかろう。

OS毎のネイティブ開発プラットフォーム
iOSアプリケーションをObjective-Cで、Android OSをjava開発環境+Android SDKで開発する場合。
当然に、これら環境はクライアント側の開発をおこなう環境だ。したがって、データベース・アプリケーションを制作するためには、上流設計でサーバ・クライアント構成と処理分担をおこなったうえで、サーバ側開発と、これら環境によるクライアント開発を平行させることになる。サーバ側は、たとえば JSP・Servlet などで開発することになろうか。WIndowsOSクライアントの位置づけも難しい。開発環境が多岐に亘るということは、当然に開発・運用コストが高止まりすることを意味する。
メリットが上述した優先順位の逆張りといえる。企業向け開発プラットフォームとしては、この選択肢は特殊な用途以外はほぼありえないだろう。

長所
  • デバイス機能連携に優れること
短所
  • 開発・運用コストの高止まりが想定されること(サーバ・クライアントの別開発+クライアントOS毎の別開発)
WEBアプリケーション
たとえば、HTML5+CSS+JavaScriptで開発する場合。
マルチOS対応のデータベース・アプリケーションを制作する観点で、最もとっつきやすいのがこの選択肢だろう。利用要件に抵触するのは、UIがリッチでないこと、html5実装状況がブラウザによって異なっているために実装機能の選択(特にデバイス連携)に慎重になる必要があることだが、これらは相対的に優先順位が低い項目である。
むしろ、問題は、先端的なアプリケーションを制作しようとするほど、モバイルOSの進化、ブラウザのW3C勧告準拠動向、W3C勧告そのものを常に睨みながら、開発・運用を行わなければならない点にあろう。技術的な進歩に伴って発生するであろう技術的な課題や折々のトラブルへの対処を、個々の企業単位でおこなうための人・もの・金。これらを費やす価値は本当にあるのだろうか。
また、当然ながらサーバ側とクライアント側の開発を分ける必要があり、この点ではOSネイティブと同様である点も留意しておきたい。特に開発規模が大きい場合は、大変だろう。

長所
  • 複数のOSに対応できること
短所
  • 開発・運用コストの懸念(OS・ブラウザ環境への対応の継続+サーバ・クライアントの別開発)

ハイブリッド開発プラットフォーム
iOSとAndroid他のモバイルOSに対応した開発フレームワークとしては、PhoneGap、Titaniumが有名だ。独自のクライアント実行環境内で、WEBアプリないしはjavascriptが動作するもの。
モバイル系OS開発環境を統合できるのが売り物だが、WindowsOSをどう取り込むか要検討事項となる。リッチUI、デバイス連携は、開発フレームワーク次第だ。
また、当然ながらサーバ側とクライアント側の開発を分ける必要がある。
総じて、企業アプリケーションのプラットフォームとしてみた場合、メリットは限定的だ。可もなく不可もないというところか。

ミドルウエア型
サーバ・クライアント双方に搭載するモジュールが、通信処理を監視しクライアントOS・機種の差異を吸収する。特定言語(例えば、サーバ:JSP・Servlet、クライアント:HTML + JavaScript)による開発をサポートするとともに、通信セキュリティ・キャッシュによる通信安定化などの機能を付加する。
ミドルウエア製品選択によるが、うまくすれば、Windowsも含めた多OS対応、スケーラビリティやセキュリティ面のメリット、開発・運用両面の低コスト化を計ることができるだろう。
ただし、ミドルウエア自体が開発環境を含まない多くの場合、やはりサーバ側とクライアント側の開発を分ける必要がある。

長所
  • 複数のOSに対応できること
  • セキュリティ対策
短所
  • 開発・運用コストの懸念(サーバ・クライアントの別開発)

4タイプに共通するクライアント・サーバ分断構造
さて、こうして並べてみると、4タイプのシステム構成が似通ったものであることに気づかれたのではないかと思う。
つまり、どれも、サーバ処理・クライアント処理を別のプログラムが担い、クライアントからのリクエストに対してサーバがデータそのものないしデータを含んだ画面を返すという構造になっている(「プログラム分断モデル」と呼ぼう)。
各タイプを特徴づけているのは、クライアントの実行環境、ミドルウエア介在の有無であり、モデルの全体構造からみると局在的な差異であるといえる。
そして、プログラム分断モデルでは、クライアント・サーバの詳細設計・開発を分けざるを得ない。開発・運用コストの観点で、乗り越えられない堰があるといえる。





プログラム分断モデル

では、この堰を乗り越えるにはどうすればよいのか。
クライアント・サーバ間で、都度クライアントが必要なデータとともにプログラムも流通させればよい(「プログラム流通モデル」と呼ぼう)。クライアントには、実行環境と、最初のリクエストに必要な情報だけを置けばよい。複数のOS上で動作するプログラムを一括開発・運用できるのだから、プログラム流通モデルのメリットは大きい。あとは、クライアント実行環境の適応OSの種類と機能性次第だ。

プログラム流通モデル

uniPaaSマルチOS開発プラットフォーム
Magic uniPaaSは、企業向け業務アプリケーション開発環境として出発した。CS、WEBに加えて、2006年からはWindowsOS向けリッチクライアント・インターネット・アプリケーション(RIA)開発機能を実装。以降、RIAクライアントの対応OSを、WIndowsMobile、Blackberryに拡張してきた。AndoridおよびiOS対応版リリースを2012年7月に予定している。
RIAアプリケーションとは、画面にhtmlを用いないWEBアプリケーション(右の画面例を参照)。クライアント側に実行モジュール(uniPaaS RIAではクライアントエンジンと呼ぶ)が必要。これにより、リッチな(操作性・表現力・画面遷移性に優れた)ユーザ・インタフェースを実現する。

uniPaaS RIA = プログラム流通モデル
uniPaaS RIAの基本構成は、プログラム流通モデルそのものだ。


開発環境一元化が開発・運用コストを構造的に抑える
前段末尾で述べたとおり、プログラム流通モデルのメリットは、開発環境一元化が構造的に、つまり仕組みとして、開発・運用コストを抑える担保になっていることだ。
uniPaaS開発環境でプログラミングする際、開発者は、サーバ処理・クライアント処理を一元的に一括記述する。もちろん、クライアント特有の処理を指定することもできるが、ほとんどの処理について、どちらでおこなわれるかを意識する必要はなく、 開発結果を一括してサーバに置けばよい。サーバ処理・クライアント処理は、uniPaaSによって自動的に識別し分割される。
また、デプロイメント(クライアントへのプログラム配備)も自動化されている。各クライアント側のプログラム起動都度、プログラムのリビジョンがチェックされ、更新されていれば処理単位にクライアント実行プログラムが配布される。開発者・管理者は、常に最新の実行プログラムをサーバに置いておけばよく、デプロイメントを意識する必要がない。

セキュリティも一元管理
これも、プログラム流通モデルによるメリット。uniPaaSは、クライアント・サーバの両方に遍在する。したがって、クライアントおよび通信経路にあるデータは、全てuniPaaSの「内部処理」データであって、暗号化され、廃棄管理されている。したがって、クライアントおよび通信セキュリティ面での安心度は高い。

企業システムとの連携のあれこれ
  • マッシュアップ
uniPaaSのフォーム機能は、ブラウザ・コントロールをもち、htmlページをフォームの一部に表示することができる。マッシュアップは非常に簡単だ。
  • 基幹系システムとの連携
uniPaaS自体、Active Directory連携など、企業システム連携のための基本機能をもつ。ただし、複数のシステム・サービス間のインテグレーションを考える場合は、姉妹製品jBOLTを使うのがよいだろう。裏方でそれ自体では目立たないが、Salesforce CRMのチャッター機能を生かして、SAP ERPの受注機能と連携させるムービーなどをご覧いただければ、その真価をお分かりいただけるだろう。

スケーラビリティを担保するブローカの存在
企業システムとしてのスケーラビリティはどうだろうか。
  • uniPaaSは、同一プログラムのサーバ実行処理を多重化するブローカ機能を実装する。これにより、処理負荷・求められる可用性に応じた構成が可能になっている。
  • サーバエンジンはOSプロセスとして動作し、複数のスレッドを立てて処理する。
  • ブローカは、サーバエンジン毎のスレッド処理状況を監視しており、クライアントからのリクエストを各エンジン~スレッドに割り振る。また、エンジンが反応しない場合は、再起動を命じる。
  • ブローカは、複数のサーバエンジンを管理できる(マルチインスタンス構成)。これにより可用性を高めることができる。 
  • また、ブローカに、複数のハードウエア上の複数のサーバエンジンを管理させることもできる(マルチサーバ構成)。可用性に加えレスポンス向上を期待できる。
  • より高い可用性が求められるミッションクリティカルなアプリケーションの場合、代替プローカを設定することで多重化できる。勿論、ホットスタンバイも可能。
  • もちろん、ロードバランサを前面におくことでWEBサーバを多重化し、可用性向上・レスポンス向上を図ることも可能。


サーバ・クライアント間にわたる一連の処理は個々にコンテキストIDで管理され、ブローカはコンテキストIDを認識してサーバに処理を割り振る。コンテキストの下に、プログラム処理ステイタス・メモリデータ・パラメータ・DBテーブルのカーソルなどが保持されることで、WEBセッションに比し高度な多重処理を実現している。

エンジンが種々のクライアントOS上でネイティブに動作する
uniPaaSのRIA実行環境では、クライアントOS毎に異なる種類のエンジンが用意されている。uniPaaS実行エンジンは、Windowsクライアントでは.NET CLR上で、AndroidOSではJ2SE上で、また、 iOSのアプリケーションフレームワーク上で動作するネイティブ・アプリケーションである。

ただし、ネイティブエンジンの、特にOS依存の機能充実はロードマップ上のネックでもある。uniPaaS RIA / AndoridおよびiOS対応版のデバイス機能連携の実装は2013年になる予定だ。
開発観点からは、実行プログラム、および、それを生成する開発環境が、特定の言語に依存しない点を、ネイティブ動作を支える技術要素として付記しておきたい。その開発環境は、標準処理フローをビルトインした、生産性の高い開発フレームワークをもつが、その詳細説明は頁数の関係から、別の機会に譲りたい。
まとめると、次のようになろうか。
長所
  • 開発・運用コストを抑え、セキュリティを高める仕組みを、構造的にもっていること
  • 企業システムとしてのスケーラビリティ・連携機能をもつこと
  • 複数のOSに対応できること
短所
  • 直近のAndroidOS, iOSデバイス連携にしばし時間がかかること

以上、マルチOS上でスケーラブルな企業アプリケーションを開発するプラットフォームとして、uniPaaSのRIAに構造的なアドバンテージがあることを述べてきた。オンライン・トレーニング環境開発者向け支援ドキュメント群も充実している。関心をお持ちの方は、ぜひお問い合わせいただきたい。


0 件のコメント:

コメントを投稿

Copyright 2011, Magic Software Japan.