[はじめに]
執筆者の簡単なプロファイルです
①投稿者はSAPを主軸に置きつつAmazon Web Service、Azureを一応専門にしているコンサルタントです。
②SAPにどっぷりというよりは、SAPはただの便利な伝票貯蓄システムとして捉えて、SAP以外のソリューションを軸にアーキテクチャを考えるのが好きです。
③技術も大事ですが業務やIT投資に対する効果を意識しつつ、技術者の自己満足にならないアーキテクチャを考えることを心がけています。
ITコンサルタント、エンジニアの皆々様は技術に偏りがち（あくまで個人的な考えなのでご了承ください）ですが、自身の思想が反映された上で構成されるものがプロダクトやアーキテクチャと考えています。そのため、普段自分が考えている思想を思うままに書きなぐるような記事となっていますので、他者の思想に不快感・嫌悪感を覚える方はブラウザバックを推奨いたします。
[タイトルについて]
執筆者の考えとタイトルそのままで、「SAP Business Technology Platformって本当に必要なんだっけ？だってこのサービスおまけなのになんで世の中のSAPエンジニア、コンサルタントはそんなに賞賛しているんですか？」という執筆者の想いを示したものです。では、なぜそのような不平不満めいたタイトルになっているのか、次の本文で思いのたけを駄文で綴ります。
[本文]
・本当に必要なんだっけ？
名ばかりではありますがSAPに関わるコンサルタントをやっているので昨今SAP Business Technology Platformという言葉は嫌でも耳にします。基幹システムであるERPがS/4HANAに進化を遂げたことにより、保守期限が5年という比較的短期間のサイクルに変わってしまい、5年に1度のバージョンアップを余儀されなくなりました。（厳密にはS/4HANA2023で大規模なオーバーホールが行われ、SAP社におけるS/4HANAの一旦の完成形となり、S/4HANA2023以降ライフサイクルが7年へと変更されます。）従来のバージョンアップから大幅に短縮化されたライフサイクルの中でのバージョンアップを実現するためには、これまでのような数100規模のアドオンが実装されたモノシリックなERPではなく、コアクリーンという可能な限り標準機能に寄せてS/4HANAのアドオンを削減し、バージョンアップ時における影響を削減しようというコンセプトが広がってきました。とはいえ、業務機能を標準機能だけで実現するのはアドオンありきのERPで業務を進めてきた日本の顧客には厳しく、アドオンはどうしても発生してしまいます。そこで登場するのがSAP Business Technology Platformです。
Webアプリケーションというかクラウドの世界では当たり前である世界観ともいえる外部での拡張＋特異な領域は外部のSaaSに任せて連携するような疎結合アーキテクチャの概念をSAPに持ち込み、コアであるS/4HANAをクリーンな状態で維持する拡張思想を打ち出しました。また、SAP FamilyであるAribaやConcurといったSaaS製品の拡張開発を実現する公開された拡張基盤と謳い、SAPにおいては新しい世界観を持ったソリューションとしてSAP界隈に彗星の如く現れました。
ここで執筆者の疑問が生まれます。「本当に必要なんだっけ？」理由は下記の通りです。
・まずライセンス料が高い
->ライセンスに見合った設備投資費用の削減効果があるのか？
->導入に伴って工数が何か減って売り上げにつながる業務を拡大できたのか？
・Business Technology Platformじゃないといけない理由がない
->親和性云々言いますが、SAPは世界でも極めてメジャーな製品で、3rd PartyプロダクトもSAPに対応するアダプタなど用意してます。十分親和性があると言えるでしょう。
->同様のサービスはAWSにもAzureにあるし、なんならAWSやAzure上のサービスをラッピングして独自のサービスにテイラーしたものがBusiness Technology Platformなのに、なぜあえてBusiness Technology Platformを選択する？AzureでWeb AppをホスティングしてODataを活用したバックエンドロジックを組んだり、Functionsを活用した方が、同一のVNet上に配置されるため、ネットワークセキュリティの観点でもよりセキュアと考える。（当たり前だがコストも安価）
->SAPに捕らわれず、周辺システムの拡張やスクラッチでのアプリケーション開発などもAWS、AzureといったSAP以外のクラウドサービスを活用して実現可能。（技術的にBusiness Technology Platformでも実現できるがコスト、市場のエンジニアの数などを考慮するとSAPに軍配は上がらないと思われる）
->基幹システムの拡張ソリューションの割に災害対策ソリューションが貧弱。工場が1日止まれば損失は数千万円、これがグローバルで活用しているインスタンスなら数億円規模の損失である。にも拘らず貧弱な災害対策ソリューションを提供し続けている。（巷ではAZで十分カバーできると考えている人もいるようだが、一日止まった際の業務インパクトや損失を考えたことがあるかを問い正したくなってしまいます。）
これらの理由からBusiness Technology Platformの利点は少なく、高いライセンス料を支払ってまで導入する価値はないと考えています。（Fiori画面を開発しやすい、ってとこくらいでしょうか）
また、「あくまでおまけでしょ？」という発想も生じます。
大事なのは標準化であり、外部の拡張基盤を使うことではない。とどの詰まり、アドオンを棄却できるよう承認者に重役を置くといった体制整備、キーマンの懐柔と考えています。（まず、外部の拡張基盤を使うくらいなら1件でも多くアドオンを減らしてほしいです。だって所詮拡張基盤だし。）
最後にビジネスの話です。（これはライセンスの話とも重複しますが大事なところなので再掲）
Business Technoogy Platform入れて何か変わりましたかと問いたいです。コスト削減にもならなければ規模の経済への貢献もないと考えています。高いサービス入れるなら類似のサービスを導入して実現すればいいでしょうに、なぜBusiness Technology platformありきで考えるのか執筆者にはわかりかねます。
こういった理由からユーはなにゆえBusiness Technology Platform？という疑念が生じているわけです。
[個人的な意見での総括]
他にも類似したサービス（なんならもっとよいもの）もあるし安価なのになぜその選択肢を選ぶのか？本当に技術だけでなく業務上の要件を考えて比較検討したのか？主観ですがITコンサルタントやエンジニアの皆々様は技術ドリブンで物事を考る傾向にあるように見えますが、私たちの本当の仕事（IT従事者の真髄とでも言うのでしょうか）ってIT投資によるビジネス拡大と考えています。壮大な製品、開発物やアーキテクチャを導入したところでコスト削減、工数削減に伴う業務効率の向上に寄与しなけば本末転倒と考えます。いい開発物（この文章における意味合いは開発者の満足度が高いもので投資対効果などを度外視にしたもの）だけを作りたいなら自分でサーバ買って作ればいいでしょうに、と思いますし、真のITコンサルタントやエンジニアであるならば新しい技術こそ正義、ではなくBusiness Technology Platformでこそ発揮できる価値を提供できるものを考え、提案し、導入していくべきと考えます。
*フェーズによっては作るほかない場合や立場もあると思いますが提案する立場ならなおさらと考えています。
[謝辞]
ここまでお付き合いいただきありがとうございました。