« マイクロサービスで周辺アプリと連係する | トップページ | 機能タイプ&テーブルポジションで効率アップ »

2016.01.07

マイクロサービスと基幹システムの本質

 「マイクロサービス(microservices)」が注目されている。社内外のさまざまなシステムが提供するREST APIのような操作手段を組み合わせて、新たなしくみをアジャイルに開発・保守してゆく。そんな開発スタイルのことをいう。

 もともとはネット系企業で普及した手法であるが、それ以外の企業にとっても参考になる。前回記事で、基幹システムが効果的なAPIを提供することで「周辺システム」の開発が合理化されると説明した。これを社内システム全体に適用した手法が、マイクロサービスである。ネット系企業でなくても「周辺システム」はいろいろあるので、いくらでも応用できる。ただし、当然ながら万能ではなく使いどころがある。

 基幹システムから見た「周辺システム」と書いたが、それらは今風に言い換えるとSoE(Systems of Engagement)、ようするに顧客との関係強化をはかるためのシステム群である。いっぽう基幹システムはSoR(Systems of Records)に分類され、これには「会計システム」や「人事・給与システム」が含まれる。

 さて、SoEのターゲットとしては、ネット企業に売上をもたらす「一般消費者」や「広告主」として説明されることが多いが、これに「従業員」、「経営者」、「取引先」、あるいは「製造マシン」といった主体を含めてもいいのではないか。そのように考えることで、これまで基幹システムと呼ばれていたモジュールにはSoRとSoEの異質な性格が混在していたことに思い至るからだ。これらを区別し切り離すことで、SoRとしての基幹システムの本質が明確になる(次図)。

▼ SoRとSoEの関係
20160103_2

 上図右端の「PC用GUI制御アプリ(e)」の位置づけに注目してほしい。基幹システムが果たす役割として、データベースを操作するためにフォームや帳票の制御アプリを従業員に提供する、というものがある。それらを制御するモジュールが、この図では、APIを介す形で「PC用GUI制御アプリ(e)」として外出しされているのだ。

 そのモジュールは、EC用WEB制御アプリ(a)やEDI用制御アプリ(b)等と同様に、SoEの一種とみなせる。従業員が利用するSoEとしては他にスマホのネイティブアプリ(c)のようなモジュールもあり得るわけで、事務担当者向けのPC用GUI制御アプリ(e)だけを特別扱いする理由はないからだ。実際にはeを含めた形で実装されるのがふつうなのだが、業務システムをSoRとして見れば、それが含まれる必要はないのである。

 このように考えると、SoRというものは「データベース」と「業務ロジック」、そして「周辺システムに対して提供されるさまざまなAPI」を基本要素とするモジュールとしてモデル化できる。これらの要素が連係して動作しながら、膨大で複雑なデータの整合性が維持されさえすれば、SoRとしての役割をまっとうできる。

 このモデルを応用したアーキテクチャも想定できる。eのようなモジュールを切り出せるのなら、たとえば受注・出荷管理のためのデータベースや制御アプリをSoEとして外出ししてしまう形態もアリかもしれない。特定顧客向け取引管理専用のSoEを切り出してもいい。そうなると、SoRとしての基幹システム側に残る役割は、マスター管理や残高管理くらいになりそうだ。

 いずれにせよ、SoRの特性として重要なのは、その名のとおり複雑なデータベースを抱えているゆえに「簡単に変化できない」という点である。周辺システム向けのAPI群がアジャイル開発されることがあるにしても、その背後にあるデータベースについては、周到に設計・開発・保守されざるを得ない。それをアジャイルにやれば、データベースは早晩カオスに落ち込んでゆく。他システムが提供するAPIを駆使することでそれを回避できるわけでもない。つまり、SoRそのものについては、マイクロサービス手法は事実上適用しようがないということだ。

 いっぽうSoEは、ターゲットの「変わりやすいワガママ」にすばやく追随することが期待されるし、それが可能である。なぜならSoEは、データベースを伴っていないか、伴っているとしてもシンプルなもので済むからだ。RDBにこだわる必要もないし、開発言語や基盤にこだわる必要もない。

 その種のモジュールこそ、マイクロサービス手法の使いどころである。これまで基幹システムの一部とみなされていたPC用GUI制御アプリ(e)であっても、そのように扱われたほうが都合がいい。年々発展してゆく技術を利用した「モダナイゼーション」も容易になる。ようするに、SoEのような「変わりやすいモジュール」と、SoRのような「変わりにくいモジュール」とは切り分けて扱われるべきであって、当然ながら設計方法論や開発手法も違ってくるだろう。

 ただしここが肝心なのだが、マイクロサービス手法やモダナイゼーションの効果を享受するためには、SoRがSoEに対して端的かつ効果的なAPI群を提供できている必要がある。そのためには、SoRが抱えるデータベース構造がまともでなければいけない。そして、複雑なデータベースの設計が簡単でないことを思えば、企業システム全体の開発を合理化できるかどうかは、SoR設計の巧拙で決まるだろう。

 以上の認識はわれわれに、SoR設計におけるDOA(データ指向アプローチ)の意義をあらためて教えてくれる。「どんなフォームや帳票が必要か」からデータベース構造を構想してはいけない。なぜならそれらは、周辺システム(SoE)における「変わりやすいワガママ」の一環でしかないからだ。

 繰り返そう。「どんなフォームや帳票が必要か」は、SoRと疎結合な関係を持つ多彩な周辺システム(SoE)の仕様でしかない。カジュアルに開発・改変・廃棄される周辺システムの気まぐれな仕様から、SoRのあり方は導けない。出荷実績報告の担当者が利用するスマートデバイス用ネイティブアプリのフォームデザインからも、一般消費者が利用するECサイトのページデザインからも、取引先とのEDI処理仕様からも導けない。SoRのあり方は、周辺システムの要件に依存しない固有の原理にもとづいて決定される。これこそDOAが、30年以上前から主張してきたことなのである。

|

« マイクロサービスで周辺アプリと連係する | トップページ | 機能タイプ&テーブルポジションで効率アップ »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: マイクロサービスと基幹システムの本質:

« マイクロサービスで周辺アプリと連係する | トップページ | 機能タイプ&テーブルポジションで効率アップ »