SAPが開発者プラットフォームの名称を変更し、S/4HANAにバンドル

Table of Contents

SAPが開発者プラットフォームの名称を変更し、S/4HANAにバンドル

TechEd Global ERP 大手の SAP は、開発者プラットフォームを新しい名前でリニューアルし、現世代のインメモリ アプリケーション プラットフォームである S/4HANA にバンドルしました。

今週、ネバダ州ラスベガスで開催されたドイツのソフトウェア大手の開発者カンファレンス「TechEd」で講演した最高技術責任者のユルゲン・ミューラー氏は、Embedded Steampunk の代替品を発表しました。これは、開発者がベンダーの ABAP 言語で構築できるようにする SAP S/4HANA Cloud ABAP Environment としても知られるツールです。

魅力的なモデルが小道具を使ってポーズをとる

SAPのEmbedded Steampunkは、最新のシステム以外ではほとんど役に立ちません。

続きを読む

同社は昨年、SAP のリフトシフトおよびトランスフォーム パートナー プランである RISE with SAP 上の選ばれた顧客向けに、昨年 8 月に一般提供を開始した S/4HANA Cloud 2108 エディションとともにプラットフォームをリリースしました。

SAPは現在、これをS/4HANA CloudとS/4HANAオンプレミスにバンドルしています。「Steampunkの素晴らしい体験をすべてABAP Cloudに組み込みました」とミュラー氏は述べています。

ABAPクラウドは、S/4HANAスタック内で直接、S/4HANA向けの最先端の安定したクラウド対応ABAP拡張機能を提供するように設計されています。つまり、パブリックSAP APIを使用してS/4HANAのデータと機能にアクセスできるということです。

「これは、オブジェクトへのパブリックSAP拡張ポイントの使用を意味しますが、SAPオブジェクトへの変更は許可されなくなります。つまり、開発者はIDEで強力なツールサポートを得られるということです」とミューラー氏は述べた。

開発者は引き続き ABAP RESTful アプリケーション プログラミング モデルを使用できますが、2003 年に開始された Web プログラミング ツールである Dynpro または Web Dynpro のサポートは終了すると同氏は付け加えました。

「ABAP オブジェクトを ABAP Cloud に切り替えると、コンパイラがルールを順守するのに役立ちます」と彼は言いました。

SAPユーザーは長年にわたりS/4HANAへの移行に苦労してきました。以前のエディション(最新版はECC 6.0)で長年かけて構築してきたカスタマイズを新しい環境に引き継ぐことができないためです。SA​​Pの表現を借りれば、「クリーンなコア」から始め、変更は新しい環境で「拡張機能」として追加していく必要があります。

ABAP Cloud は「顧客がはるかに簡単な方法でクリーンなコアにアクセスできるようになるため、非常に魅力的です」と Mueller 氏は語りました。

しかし開発者らは、製品をS/4HANAにバンドルし、名前を変更した以外、ABAP Cloudに新しい点はほとんどないと述べています。

「昨年、S/4HANA Cloud上で開発を可能にするEmbedded Steampunkの提供が発表されましたが、誰も気に留めませんでした。ただのオタク向け製品だったのです。今年はABAP Cloudという名称になり、今では誰もが熱狂しています」と、ドイツに拠点を置くソフトウェア開発・コンサルティング会社J&S-Softの開発アーキテクト、ソーレン・シュレーゲル氏は述べた。

しかし、この製品を S/4HANA のバージョンにバンドルすると、このテクノロジーを利用する新たなユーザーが現れることになり、彼らは以前のバージョンの SAP ですでに行った変更を再現する正当性を証明する際に、同じ課題に直面する可能性があります。

SAP は、S/4HANA に移行するメリットをユーザーに納得してもらうのに苦労してきました。これは、多くのユーザーが、既に持っている機能とほぼ同じ機能を得るために、莫大なプロジェクト コストを支払うことになるのではないかと感じているためです。

「過去40年間、SAPの(改良に)過剰な投資をしてきた企業と仕事をしてきました。SAPが現在ABAP Cloudで行っていることはすべて、顧客がすぐにその恩恵を受けるわけではありません。おそらくリフト&シフトで移行することになるからです。新しいアプリケーションの場合、S/4に移行すれば、問題なく最新リリースに移行できるため、これは素晴らしい技術です。しかし、今日から始めたとしても、その恩恵を受けるまでには2年、あるいは5年かかるかもしれません」とシュレーゲル氏は述べた。

SAPは、JavaおよびJavaScript開発者向けに新しいクラウドアプリケーションプログラミング(CAP)モデルもリリースしました。このモデルには、エンタープライズグレードのサービスやアプリケーションを構築するためのライブラリとツールが含まれています。

堅実な技術ではあったものの、SAP以外の分野では認知度が低いという問題がありました。SAP以外の分野では、開発者はコアアプリケーションに接続するサービスを構築する際に使用するツールを自由に選択できるからです。ドイツを拠点とするソフトウェア開発者兼コンサルタントのトビアス・ホフマン氏は、SAP CAPを、開発者がビジネスアプリを開発できる設計システムであるSAP Fioriと比較しました。

  • SAPは、コーディングを必要としないビジネスタイプ向けにERPプラットフォームにローコードをさらに導入
  • ServiceNowの社長がSAPの台頭を狙う企業攻撃に乗り出す
  • ラリー・エリソンはオラクルの第一世代クラウドを潰すために社内で闘った
  • SAPユーザーは地平線に散らばった雲を見る

「問題は、SAP が快適な領域から抜け出して、SAP の世界の外の開発者コミュニティのサポートを得るために実際に戦わなければならないことです。CAP が可能性を秘めているのはまさにこの点です。しかし、Fiori を見ればわかります。Fiori は非常に優れていますが、SAP の世界以外では誰も採用していません」と同氏は述べた。

コンステレーション・リサーチの副社長兼主席アナリスト、ホルガー・ミューラー氏は、SAP は中核製品と開発ツールをクラウドに移行しているが、オンプレミスのままで高度にカスタマイズされたシステムを持つインストールベースを説得する必要がある、と述べた。

「カスタマイズやカスタムコードが不要なクラウド『標準』への移行は企業にとって大きな課題であり、SAPにとってこの移行をスムーズかつ容易にすることが鍵となるだろう」とミュラー氏は述べた。

「SAPは、顧客が多くのカスタマイズに多大なノウハウと時間を費やしているため、カスタムコードに対する姿勢をある程度緩和する必要があるでしょう。実質的には、SAPは既存顧客の移行にかかる労力を、SAPをゼロから再導入する場合、あるいはSAPにとってより困難な、競合他社からクラウドERPを入手する場合よりも軽減する必要があります」と彼は述べた。®

Discover More