モバイルアプリのアーキテクチャ上の特徴

モバイルアプリのアーキテクチャは従来のWebのシステムとは何が違うのでしょうか。

  1. モバイルはクライアント・サーバーモデルである。
    Webシステムはサーバー側にUIや業務ロジックを持ち、その結果生成されたHTMLをブラウザが取得して表示しますが、モバイルアプリは端末内にインストールされ、APIを経由してサーバーと協調して動作します。
  2. モバイルアプリは社外で使用されるため、社内で使用されるシステムよりもセキュアである必要がある
  3. モバイルアプリは数を沢山作る
    Webの100画面もあるようなシステムではなく、10画面から数十画面程度の小さなアプリケーションを沢山作る傾向があります。
  4. AppleやGoogleを始めとする外部のサービスと連携する

あるべきアーキテクチャ

この章ではモバイルアプリそのものではなく、モバイルアプリを組み込んだ企業システムのあるべきアーキテクチャについて扱います。

このような特徴を考慮し、モバイルアプリを使用する場合のリファレンス・アーキテクチャを作成しています。

リファレンス・アーキテクチャ

  • AppleのAPNS、GoogleのGCMと連携するための共通コンポーネントを用意し、各アプリはそれを利用する
  • 社内のActive Directoryなどと連携した共通のユーザー管理
  • モバイルアプリ向けのに既存システムのインターフェイスを公開する基盤を用意し、モバイルアプリは既存システムのシステム構成には依存させない。インターフェイス基盤で社外からのアクセスに対して横串でセキュリティをかける
  • モバイル端末を管理するためのMDM(Mobile Device Management)製品

AppPotの論理アーキテクチャー

AppPotは一般的なスマートデバイスのリファレンス・アーキテクチャのうち、MDM以外の機能を提供しています。

AppPotアーキテクチャ

AppPotは共通機能を提供するWeb API、AppPotの制御情報やアプリのデータを格納するデータベース、そして管理画面から構成されます。

複数のアプリを共通のプラットフォームで管理するコンセプトとなっているため、複数のアプリを運用したとしてもAppPotは同じものを利用できます。

開発プロセス

一般的なモバイルの開発では以下のようなタスクがあります。

  1. 要件定義
  2. モバイルアプリのUIやサーバー側のAPIのインターフェイス定義、データベース設計
  3. モバイルアプリの設計・開発・テスト
  4. サーバー側の内部設計
  5. 非機能要件の定義とインフラの見積もり
  6. 非機能要件に応じたインフラの調達
  7. インフラの設計・構築

AppPotを利用することで、サーバー側のインフラの調達、サーバーアプリの設計・開発が不要です。また、認証などの共通機能を設計開発する必要がありません。

開発プロセスの違い



特にモバイルを使用するようなシーンでは、ビジネスの変化が早いため、その変化にITが素早く、柔軟に対応できることはシステム構築のコスト削減以上に大きな価値があります。