楽水

人々の創造が自由に表現できる舞台づくり

DX アプリケーション

アプリケーションアーキテクチャの設計

投稿日:


変化が激しく、不透明で先行きが予測できない昨今の経営環境を、

  • Volatility(変動性)
  • Uncertainty(不確実性)
  • Complexity(複雑性)
  • Ambiguity(不透明性)

の頭文字をとってVUCA(ブーカ)という言葉で表すことがあります。
それは、SNSやモバイル技術によって人と人がつながる時間や距離が短くなったことで、
個人の欲望や考えが、複雑なネットワークを介してすぐに世界中に広がり、
いつどこで、どんな需要が生まれるか読みづらく、欲求の新陳代謝も激しくなっているからではないでしょうか。
このような時代、環境の変化にアジャイルに対応しながらビジネスを展開していく必要がありますが、複雑化、ブラックボックス化した既存の業務やシステムが足かせとなってスムーズに適応できない会社が多々あるようです。

多くの会社が、
ビジネスの変化が加速し、ビジネスとITが密接化する中、全体の設計図もなく、必要に応じてシステムを導入してきた結果、

  • 大規模で複雑なシステムがサイロのように乱立している
  • 重複して整合していないデータが散在している
  • 個別の業務やシステムは詳しいが全体を理解できる人や資料がない

というカオスで雁字搦めな状況に陥っています。
経済産業省が2018年に出したDXレポート ~ITシステム「2025年の崖」の克服とDXの本格的な展開~ではでは、企業がDXに対応できない現状を、

  • 既存システムが、事業部門ごとに構築されて、全社横断的なデータ活用ができなかったり、過剰なカスタマイズがなされているなどにより、複雑化・ブラックボックス化している
  • 経営者がDXを望んでも、データ活用のために上記のような既存システムの問題を解決し、そのためには業務自体の見直しも求められる中(=経営改革そのもの)、現場サイドの抵抗も大きく、いかにこれを実行するかが課題となっている

と分析した上で、このような状況を改善できない場合、

  • データを活用しきれず、DXを実現できないため、市場の変化に対応して、ビジネス・モデルを柔軟・迅速に変更することができずデジタル競争の敗者になる
  • 多くの技術的負債を抱え、業務基盤その ものの維持・継承が困難になる
  • 保守運用の担い手不在で、サイバーセキュリティや事故・災害によるシステムトラブルやデータ滅失等のリスクの高まる

という状況に陥り、DXが実現できないのみでなく、2025年以降、全体で最大12兆円/年(現在の約3倍)の経済損失が生じる可能性(2025年の崖)と予想しています。
※技術的負債(Technical debt)とは、短期的な観点でシステムを開発し、結果として、長期的に保守費や運用費が高騰している状態のことです。
アプリケーションマネジメントは、既存の基幹システムをマイクロサービスとしてモジュール化することによって、このような問題を解決します。
マイクロサービスとは、ビジネス機能を一つのサービスとして提供したソフトウェア部品のことです。

この例では、画面まわりを処理するフロントエンドアプリケーションが、ビジネスロジックとデータアクセスを制御するマイクロサービスを使う構造になっています。
これによって、新しいフロントエンドアプリケーションを開発するとき、すでに在るマイクロサービスを部品として再利用することができるので、開発の生産性が上がり、企業を変化に強い構造にすることができます。
また、データ構造が変わった場合、関連するマイクロサービスは影響を受けますが、そのマイクロサービスを利用するフロントエンドアプリケーションは一切影響受けないので、高い保守性を実現することができ、企業を変化に強い構造にすることができます。
マイクロサービスという技術を活用して企業全体のアプリケーションをモジュール化(部品化)し一元管理することで、システムの保守性、安全性など品質を向上させ、企業を「変化に強い構造」にすることができます。
さて、アプリケーションマネジメントを導入するためのタスクは次のようになります。

ここでは、この中の

について解説します。
これは、

  1. まず、あるべきアプリケーションの型をつくり(アプリケーションのモデル化
  2. その型をベースに既存のアプリケーションを最適化(統合、分割、追加、削除)し(アプリケーションの最適化)、
  3. 個々のアプリケーションを交換可能な部品として実装する(アプリケーションのモジュール化

ことで変化に強いアプリケーション基盤を構築する流れになります。

アプリケーションアーキテクチャの設計

アプリケーションのモデル化
アプリケーションアーキテクチャを設計することで、あるべきアプリケーションの構造をモデル化します。
アプリケーションアーキテクチャは次の手順で設計します。

  • コンテキストマップの設計
  • アプリケーション統合方式の設計
  • 要件定義
  • 外部設計

コンテキストマップの設計

コンテキストマップ(Context Map)は、ドメイン駆動設計の概念で、個々のアプリケーションのコンテキスト境界間の関係を描いたものです。
詳細は、ドメイン駆動設計・戦略的設計を参照してください。
コンテキストマップは、ビジネスアーキテクチャのバリューストラクチャに基づいて設計します。
次の図は、俺のフレンチのバリューストラクチャをコンテキストマップに展開した例です。

アプリケーション統合方式の設計

次に、上記コンテキストマップを構成する個々のコンテキスト境界を、アプリケーションタイプ(アプリケーションの型)と考え、それらをどのように連携させ統合するか設計します。
アプリケーションタイプを連携するときの代表的な形態には次の2つがあります。

  • リクエスト/レスポンス
    送信側がリクエストを発行し、受信側のレスポンスを待つ形態。
    通常、送信側と受信側の処理は同期しますが、受信側にコールバックを登録することで非同期通信をすることも可能です。
  • イベントドリブン
    送信側に起きたイベントを受信側に通知することで、受信側の処理が駆動される形態。
    送信側は、受信側に処理の指示を出すわけではなく、イベントを通知するだけで、受信側のレスポンスも待ちません。

リクエスト/レスポンスの場合、もし、受信側に不具合が生じた場合、送信側の処理が続行できなくなりますが、イベントドリブンの場合、そのようなことはありません。
なので、イベントドリブンの方が相手に対する依存度が低くなります。
相手のレスポンスの結果がリアルタイムに必要ではない場合、イベントドリブンを選択するほうが効果的だと言えます。
さて、リクエスト/レスポンスの実装技術の例としては、RESTfulなHTTP(REST/HTTP)があります。
また、イベントドリブンの実装技術の例としては待ち行列を使ったメッセージングがあります。
上記コンテキストマップの商品管理と販売、購買の連携を、この2つで行った場合次の図のようになります。

要件定義

次に、すべてのアプリケーションタイプの

  • 機能要件
  • 非機能要件

を定義します。
要件定義については、システム開発プロセス・要件定義を参照してください。

機能要件の定義

アプリケーションタイプの機能をユースケースとして定義します。
次の図は、上記コンテキストマップの販売(アプリケーションタイプ)のユースケースモデルの例です。

非機能要件の定義

次に、アプリケーションタイプの非機能要件を定義します。
次の図は、販売アプリケーションのデータ要件としての概念データモデルの例です。

アプリケーションタイプの概念データモデルは、データアーキテクチャの概念データモデルとして定義されたものから選択します。

外部設計

アプリケーションタイプの外部設計は次のタスクより構成されます。

  • ユースケースの分析
  • APIの設計
ユースケースの分析

コンテキストマップのアプリケーションタイプ同士がどのように相互作用してユースケースを実現するか可視化し、ユースケースの実現性を検証します。
次の図は、上記「商品の注文」ユースケースを上記コンテキストマップのアプリケーションタイプどのように実現するかをシーケンス図で示した例です。

コンテキストマップを構成するアプリケーションタイプである販売と商品管理がREST/HTTPで連携して「商品の注文」ユースケースを実現していることがわかります。

APIの設計

ユースケースを詳細化し結果からアプリケーションタイプに必要なAPIを抽出して、その仕様を定義します。
販売と商品管理の間の「商品の取得」メッセージのように、アプリケーションタイプ間がREST/HTTPで連携する場合、APIの仕様を、URL、HTTPメソッド、リクエストパラメータ、メッセージ、HTTPヘッダー、HTTPステータスコードなどで定義ます。

アプリケーション戦略の策定

アプリケーションの最適化
アプリケーション戦略では、アプリケーションアーキテクチャに従って、既存のアプリケーションを統合、分割、追加、削除することで最適化します。
まず、会社内で☓☓システムと呼ばれている基幹システムをアプリケーションカテゴリ(アプリケーションタイプの分類)として洗い出します。
その上で、現行アプリケーションカテゴリのユースケースを洗い出し詳細化します。
次に、アプリケーションカテゴリを、アプリケーションアーキテクチャの構成要素であるアプリケーションタイプにマッピングします。
最後に、次の観点でアプリケーションカテゴリを最適化します。

  • 複数のアプリケーションカテゴリが一つアプリケーションタイプにマッピングされる場合、ムダが生じているのでアプリケーションカテゴリを統合する
    統合するときは、アプリケーションカテゴリのユースケースが、アプリケーションタイプのユースケースに整合しているか確認します。
  • 一つのアプリケーションカテゴリが複数のアプリケーションタイプにマッピングされる場合、ムリが生じているのでアプリケーションカテゴリを分割する
    分割するときは、アプリケーションカテゴリのユースケースとアプリケーションタイプのユースケースを対応させます。
  • 必要なアプリケーションタイプに対するアプリケーションカテゴリがない場合、アプリケーションカテゴリを追加する
    アプリケーションタイプのユースケースから追加するアプリケーションカテゴリのユースケースを導きます。
  • どのアプリケーションタイプにもマッピングされないアプリケーションカテゴリがある場合、アプリケーションカテゴリの削除(廃止)を検討する


アプリケーション基盤の構築

アプリケーションのモジュール化
ここでは、アプリケーション戦略で最適化された個々のアプリケーションをマイクロサービスとしてモジュール化することで変化に強いシステム基盤を構築します。
次の図は、アプリケーション基盤のイメージです。

これをみると、記録システム(System of Record:SoR)によってアプリケーション基盤が構成されていることがわかります。
記録システム(SoR)は、所謂、基幹系システムで、これらがマイクロサービスとして様々なアプリケーションから利用される形になっています。
さて、マイクロサービスとは、ビジネス機能を一つのサービスとして提供したソフトウェア部品のことです。
マイクロサービスについては、次の書籍が参考になります。


書籍「モノリスからマイクロサービスへ」では、マイクロサービスを、
ビジネスドメインに基づいてモデル化された、独立してデプロイ可能なサービス
と言っています。
つまり、マイクロサービスは、論理的な概念ではなく、物理的なソフトウェアコンポーネントになります。
これをレイア構造で表すと次の図のようになります。

  • 上述したアプリケーションタイプは、ジョブ(職務)を実現するアプリケーションの型。
  • アプリケーションタイプを分類した論理的単位がアプリケーションカテゴリ。
  • アプリケーションカテゴリの実例となる物理的な単位がマイクロサービス。

さて、アプリケーションマネジメントを導入する目的は、
企業のシステムを変化に強い構造にすること
です。
大規模で複雑になり手がつけられなくなった既存システムを、管理可能な小さな機能単位に分けて、それらを疎結合することでシステム全体の生産性(再利用性)や保守性を上げることです。

まるで、絡み合った糸を解していくように既存システムをマイクロサービスに転換(transform)するためにはどうすればよいのでしょうか?
ポイントは、複雑化した既存のシステムの中身を解読するのではなく、あるべきシステムを描いて、それを既存システムに投影するというアプローチです。
アプリケーション戦略で、あるべきアプリケーションタイプに、既存システム(アプリケーションカテゴリ)を次のような手順でマッピンします。

  • ユースケースの洗い出し
    まず、既存システムのユースケースを洗い出します。
  • ユースケースの詳細化
    次に各ユースケースを詳細化します。
    ユースケースの詳細化については、システム開発プロセス・外部設計を参照してください。
  • ユースケースの最適化
    最後に、既存システムのユースケースをアプリケーションタイプのユースケースに合わせて適切なかたちに変更します。

ここで重要なのは、ユースケース(機能要件)を定義することで、既存システムが本来実現すべき機能が明確になることです。
これよって、技術的負債である既存システムの仕様部分がナレッジという知的資産に変換されます。
既存システムが本来実現すべき機能が明確になったら、それをどうマイクロサービスとして実現していくか設計します。
書籍「モノリスからマイクロサービスへ」では、大規模で複雑になり手がつけられなくなった既存システム(書籍では、これをモノリスと読んでいます)をマイクロサービス化する方法として「ストラングラーアプリケーション」パターンを紹介しています。
「ストラングラーアプリケーション」パターンは、既存システムから移行対象の機能を切り出して、段階的にマイクロサービス化していくという手法です。

-DX, アプリケーション

執筆者:

関連記事

【DMBOKで学ぶ】データモデリング

ここでは、リレーショナルスキームのデータモデリングについて以下の観点で説明します。 データモデルとエンティティ データモデルの構成 概念データモデリング 論理データモデリング 物理データモデリング デ …

NoSQLとは何か、わかりやすく解説

少し前からビッグデータという言葉をよく聞きます。 モバイルデバイスが普及することによって、様々な種類のデータを簡単に送受信できるようになりました。 Twitterは1日あたり10テラバイトを超えるデー …

データマネジメント知識体系【DMBOK】とは

5Gが普及すると、ますます、IoTなどにより発生するビッグデータを、AIを活用してビジネスに活かすことが当たり前になってきます。 データは21世紀の石油と言われています。 「稼ぐ力を持つ資産としてのデ …

【DMBOKで学ぶ】データマネジメントの導入方法

皆様は、データドリブン経営という言葉を聞いたことがあるでしょうか。 データドリブン経営とは、稼ぐ力をもつ資産としてのデータを経営に活かすことで経営目的(パーパス)を実現する手法のことです。 マネジメン …

MVC vs MVVM

ここでは、MVCとMVC2の違いについて以下の観点で解説します。 MVCとは何か MVVMとは何か MVC vs MVVM MVCについて詳しく知りたいかたは、 MVCとは【本来の仕組を詳しく解説】 …