はじめに
本記事は「SAP Side by Side開発の基本的なことのまとめ」の1項目の説明をなります。全体を把握した方はまずはそちらをご確認下さい。
また、本記事は概要把握や個人とトライアル利用の参考として、まとめたものなので、プロジェクトでの利用の際は、SAP社への問合せの実施や正式情報であるHelp Portalを活用して下さい。
今回のテーマは基幹システム業界でトレンドワードとなっている｢Composability｣です。
2022年のTechEdのKeynoteセッションでも｢Composability｣というキーワードが語られていましたし、なんといっても｢ガートナー社｣が｢Composable ERP｣というコンセプト提唱した影響が大きく、お客さんのIT系の部門のマネジメントの方からも聞かれることの多いテーマです。
なお、｢Composability｣に関しては、各種いろいろな解釈がありますし、概念的で曖昧なもののため、私自身の解釈として捉えて頂ければと思います。
一言で言うと
基幹システムを機能毎に分割し、機能間連携をしながら全体の基幹システムを構成することと個人的には理解しております。
対比の表現として｢Monolithic（枚岩の、頑丈な）｣という表現があります。元来、ERPはすべての機能がつまっており、それらが余計なことを考えずに連携していることが利点だったのですが、｢Composability｣ではそれらをバラバラにして疎結合にするイメージです。
SAP社の製品でイメージしてもらうと、各業務機能をS/4HANAやSAP CommerceやAriba、Concur等が構成し、それをBTPを介して、APIでのリアルタイムデータ連係および、DWHへのデータが蓄積されるようなアーキテクチャとなります。SAP社の理想像とするようなシステム構成を実装できれば、｢Composability｣を実現しているといえるでしょう。
ただし、理想はそうでそうでもあっても、ERP部分はガチガチアドオンされ、各種システムともバッチ連係といった現実も多くあるため、基幹システムに｢Composability｣をと各所で叫ばれています。
IT業界にある機能分解の思想
バラバラにすれば、柔軟性がアップするというという思想は、IT業界においても他にも存在しています。
2000年代に出現した｢SOA (Service Oriented Architecture)｣であり、現在の開発のトレンドとなっている｢マイクロサービス化｣です。個人的にはこれらはすべて同じ思想に基づいており、対象としている粒度が違うだけだと考えております。個別のシステム機能（SAPでいうと汎用モジュールのレベル）での共通化共有化することが｢マイクロサービス化｣、業務機能（SAPでいうとトランザクションレベル）での共通化共有化することが｢SOA (Service Oriented Architecture)｣、業務機能（SAPでいうとモジュール）での共通化共有化すること｢Composable ERP｣とイメージして頂くことがわかり易いと思います。
これらの単語を理解している方は、それらをレベルや視点を変えて、言い換えていると捉えて頂くのが良いと思います。（だれかが定義した訳ではなく、私の解釈です）
｢Composability｣を求めるメリット
これは｢なぜ「Side by Side開発」を実施するのか？｣説明させて頂いた、｢Side by SIde開発の利点｣にかなり近いものがあります。
ポイントは｢要求されるものの変化（複雑化）｣と｢速度の変化｣です。
従来の基幹システムは、お金とモノの動き（在庫、販売、購買）などの動きをデジタルに捉え、企業のインフラとして働くことが求められていました。それらが工数をかけずに、安定に連動することが価値とされていました。
そこに近年になり変化が訪れます。データが単なる活動のログではなく、企業活動の付加価値の源泉として捉えられることになる変化です。在庫の状況から需要を予測を実施し販売戦略の立案に活かすことや、顧客の受注状況を分析して営業戦略に活かすことを想像して頂くとわかり易いと思います。
このような使い方を前提とすると、データの用途が広がり（多くの要件から必要とされることになり）、持つべき項目も可変的になります。これが｢要求されるものの変化（複雑化）｣です。それと共に必要なタイミングも多様化するため、結果として｢速度の変化｣が伴います。（よりリアルタイム性が求められることとなります）
このような要求を実現しようとすると、機能は一元集約され、疎結合なほうが理にかなっているという結論に致します。顧客情報を管理するのに、各システムに顧客マスタがあるのではなく、一元集約されたシステムが要求に応じて、データを渡す方が理にかなっているということをイメージして頂くとわかり易いと思います。
ベンダーロックインから解放というメリット
また、ガートナー社などが、強く主張しているメリットに、ベンダーロックインからの解放があります。｢Monolithic（枚岩の、頑丈な）｣なアーキテクチャを採用した場合は、必然的にそのベンダーにロックインされることになります。しかし、前述のように要件の柔軟性や複雑製に対応するためには、1つのベンダーに縛られることなく、最適な機能や条件を有したベンダーの製品を選ぶことの方が適しているということは理解頂けると思います。この観点において｢Composability｣がある基幹システムにしておくことは大きな意味を持ちます。
｢Composability｣を求めることの難しさ
基幹システムに土地勘がある人ならば、この理論はその通りであるが、実際問題難しいという感覚を持つと思います。
それを要素として分割すると｢設計・構築の難易度の向上｣と｢不確定性の上昇｣だと考えています。
必要な単位に機能を分割することはそんなに簡単なことではないですし、分割後の機能に対しても、汎用性を考えた設計を考慮すると単体の設計の難易度が上がります。
また、当たり前のことですが、｢自由度の向上は不確定性の上昇｣を意味します。個別にアプリケーションを動かし連係するということは、それだけエラーハンドリング等も複雑になりますし、開発管理のルールの徹底も必要になります。
｢マイクロサービス化｣に関してはこれらを実現するための手法やツールが開発され、基幹以外の領域では主流となりつつありますが、｢SOA (Service Oriented Architecture)｣は思ったほどに浸透しなかった（特に日本においては）ため、時を経て、｢Composability｣というかたちで、再挑戦といったところでしょうか。
｢Side by Side開発｣と｢Composability｣
｢なぜ「Side by Side開発」を実施するのか？｣にて、｢Side by Side開発のメリット｣を説明した際に、混乱を招く可能性があったため、あえて言及しなかったのですが、｢Side by Side開発｣の一番壮大なメリットが｢マイクロサービス化｣であり｢Composabilityの向上｣です。
前述の記事では｢S/4HANA｣および｢SAP製品の拡張｣を前提として、メリットを記載しましたが、そうではなく、最終的には企業全体のいろいろなシステムから｢Side by Side開発｣された機能が呼び出されることが、SAP社の見据える姿です。基幹システムの経験のある方なら理解頂けると思うのですが、各システムで同じような機能を実装していることは多く、それらを統一して外出し、共通的に有効活用し｢Composability｣を実現することが、｢Side by Side開発｣の理想像となります。
まとめ
｢Composability｣の本質は、個別機能化による、柔軟性の向上であるということは理解頂けたかと思います。実際問題、これを実現するのはそれなりの難しさを伴うのですが、皆さんもシステム構築を検討する際は、全体共通化の視点がトレンドとして重要視されることを意識して頂ければと思います。