はじめに
本記事は「SAP Side by Side開発の基本的なことまとめ」の1項目の説明をなります。全体を把握した方はまずはそちらをご確認下さい。
また、本記事は概要把握や個人とトライアル利用の参考として、まとめたものなので、プロジェクトでの利用の際は、SAP社への問合せの実施や正式情報であるHelp Portalを活用して下さい。
「Side by Side開発」のアーキテクチャ的な特徴と「In App開発」との違い
この章では、「Side by Side開発」と「In App開発」のアーキテクチャ的な違いに着目しながら、両者の使い分けについて言及していきます。
また、近年盲目的に「パッケージアップグレード負荷の軽減」のために、すべての開発を「Side by Side開発」にといった論調もありますが、個人的にはそれは正しくなく、使い分けが必要と考えているため、そのあたりについても言及したいと思います。
ABAPを振り返る
「Side by Side開発」が推奨される現在では、「ABAP」はネガティブな文脈で語られることもありますが、基幹システムを構築するための言語としては非常に優れた言語です。SAP社のERPシステムがここまで、メジャーになれたことには、ABAPの貢献が大きいと私は考えます。
ABAPは難しく複雑な言語であるものの、スキルを保持しているエンジニアが扱えば、少ない工数で効率的な実装が行える言語でもあります。
もう少しその特徴を理解して頂くためにABAPの大きな特徴である「一括処理高速かつ効率的に処理できる」、「画面とその背後で動く処理を一括して効率的に開発できる」について簡単に言及したいと思います。
一括処理高速かつ効率的に処理できる
プロジェクトのアドオイン一覧のなかで、XXマスタ一括登録やXX伝票一括更新などの、一括処理を扱ったことがある人は多いと思います。
SAPの標準機能に開発思想として一括処理機能が少ないことと、日本人の気質的に効率化をもとめるため、このようなアドオン要件は発生することが非常に多いです。（RPAの登場などで昔よりは少なくなりましたが。）このような一括処理に際して、ABAPは非常に優位性があります。ABAPはS/4HANAの標準テーブルや標準モジュールと基盤で同じ言語で動作します。そのためプログラム的な親和性が高く、ネットワーク的な距離も近いため、基幹システムで要求されるような大量更新に適することになります。
画面とその背後で動く処理を一括して効率的に開発できる
ABAPの主要なプログラム種別である、レポートプログラムでは、画面の開発（フロントエンド開発）と背後で動く処理（バックエンド開発）を一括して同時に開発することが基本です。そのため、1人のエンジニアで効率的に少ない工数で開発が可能です。
ABAPとの根本的な違い
それでは本題である「Side by Side開発」について話を移していきましょう。「Side by Side開発」のベースとなるものは「WEBアプリケーション開発」を支えている技術要素です。
これらは基本的に、「フロントエンド（ユーザインターフェース）」、「バックエンド（ビジネスロジック）」、「DB/API （データアクセス）」で構成されます。
「フロントエンド」はユーザに見えるWEBブラウザ上の見た目を制御する層です。言語としては「HTML5, CSS, JavaScript」で記述されます。
「バックエンド」はフロントエンドからデータをもらい、それを処理し、データベースに格納したり、フロントエンドに返却したりするレイヤーです。言語しては「JavaやJavaScript等」で記述されます。
DBはそれを格納する層です。また、近年は様々は汎用サービスがAPI化されているため、それをもちいてデータアクセスをするパターンも多く想定されます。S/4HANAに対して拡張開発を実施する際は、APIの部分がO-dataのAPIとなります。
そして、各層間の通信はHttpsベースであり、S/4HANAとのやり取りもAPI定義として明確化されるため、それぞれの層の役割分担およびやり取りのルールが明確化され、アップグレード負荷も軽減されるということになります。
ただし、三層構造は別々に存在するため、技術要素も違いますし、設計もある意味個別に実施する必要があります。大きなアプリケーション開発や高度なアプリケーション開発を実施する際には、それぞれの層に個別のエンジニアをアサインするケースも良くあります。
一方、ABAPに戻すとこちらは、2層構造です。また、バックエンドとDBの密結合しており、APIではなく、ABAP内の各種技術要素を用いて更新されることが多いです。
それが「画面とその背後で動く処理を一括して効率的に開発できる」、「一括処理高速かつ効率的に処理できる」という利点を生みますが、ブラックボックス化を招きアップグレードの際の対応を難しくしています。
レイヤー間の通信の問題
もう一つこのテーマを理解するために重要なトピックにレイヤー間の通信があります。
このアーキテクチャでは「フロントエンド」と「バックエンド」、「バックエンド」と「API」の間は、インターネット経由のhttps通信となります。一般的なWEBアプリでは、対話ベースの処理となり、インターネットの回線速度も早いため大きな問題にはなりません。
しかし、基幹システムの開発となると話が少しかわってきます。前にも記述したように、大量データの更新要件が基幹システム開発では多く要求されます。
これら要件を3層にて処理をすると各レイヤー間をhttpsベースで膨大なデータがやり取りされることになります。技術的に不可能ではないのですが、途中で回線が途切れてしまった場合や一部のデータにエラーがあった場合の処理などを想定すると、設計上の考慮も多くなります。また、通信のためのネットワーク系のコストもかさむことになります。
結局どっちが簡単なの？
多くの人が疑問に思うのがこのテーマだと思います。作るアプリのテーマや難易度、それにかかわる人たちスキルなどにもよるのでケースバイケースに総論としてはなってしまうと思います。
個人的な見解としては、各技術に精通したエンジニアを準備して、ゼロからスクラッチ的に構築するのであれば、構築工数ではABAPの方が少なく短期間できると考えています。（ローコード開発などの観点は除く）ただし、エンジニアの単価の視点で、考えるとABAPは高単価のため、総金額となると全く話は別となるので、非常に難しいテーマとなってきます。（釈然としない感じで申し訳ないのですが。。。。）
開発・運用観点での違い
これまではアプリケーションの観点から記述をしてきましたが、最後は運用です
運用の観点からも大きくこと異なります。「In App開発」の場合は基本的には、既存のS/4HANAの開発・運用管理の仕組みを利用します。（詳しく省略しますが、経験者の方は「移送」などでプログラム開発を管理する方法をイメージ頂くと良いと思います。）これらの仕組みはSAPのERPシステムを経験した人には常識であり、非常に洗練された仕組みではあるものの、一般的なITのスタンダードからは外れております。
「Side by Side開発」では、「WEBアプリケーション開発」を支えているOSS（Open Source Software）ベースでの開発・運用管理を要求されます。管理に際しては、1つのツールで一括して管理するのではなく、個別の機能毎にツール（機能）が準備されています。（ソースコードを保管する機能、ソースコードを各環境にデプロイする機能、ランタイムのリソース状況を監視する機能など）また、それらの実行に際して、簡易的な機能はBTP上にも保持している場合が多いですが、保持されていない機能あります。高度なことを要求する場合は、BTPで足りないことも多いです。
よって、「Side by Side開発」を選択する場合は、これらの仕組みを受入て、学習し、環境を準備する必要があるということを忘れてはいけません。
BTPではおそらく意図的に準備していない
この話を聞いて「BTP機能不足では？」と思った方もいると思います。私は意図的に準備していないと考えています。
なぜなら、このあたりの仕組みは、WEB開発や他のモダンなスクラッチ開発では必須のツールであり、各企業は持っていて当然という前提があるからです。（わざわざ、SAP社が提供するものを使わなくても、企業共通に持っている仕組みを使って、S/4HANAも他のアプリケーションも一括で管理した方が効率的だよね。という思想です。）
グローバルレベルではそうなのかも知れませんが、日本のIT組織では、モダンなIT開発をしているところは少なく、クライアント企業側も、ベンダー側も、この仕組みを受け入れることがBTP導入の大きなハードルになっている側面もあります。開発・運用に関しては、非常に深い世界で書き出すとキリがないのでここまでにします。
まとめ
「Side by Side開発」と「In App開発」の技術的な違いについて、ご理解頂けたと思います。また、それぞれに特徴があるため、アプリケーション要件・開発・運用要件に適したものを選択することが必要だということを再度認識頂ければと思います。