ヘッドレスコマースの汚い秘密：一部のベンダーが意図的に言っていないこと

ヘッドレスコマースソリューションの汚い秘密：一部のベンダーが（意図的に）あなたに大きな時間を費やす可能性があると言っていないこと。

ヘッドレスコマース、または単に「ヘッドレス」は、現在のB2C世界の最愛の人です。 Googleトレンドによると、ヘッドレスコマースの検索リクエストは2020年の初めから指数関数的に増加しています。eコマースの観点からは、その理由は簡単にわかります。

パンデミックの間、消費者は家に閉じこもり、ソーシャルメディアのフィードにつながれてきました。 直接販売のブランドは、Instagram、TikTok、Facebookなどのメディアを利用して、対象となるオーディエンスに直接商品を届けることができます。 ヘッドレスコマースソリューションは簡単です。

ヘッドレスアーキテクチャは、優れた柔軟性を提供します。 フロントエンドとバックエンドの分離（およびAPIの可用性）により、新しいチャネルにコマースを展開したい組織にとって、ヘッドレスをサポートするプラットフォームでそれを行うのははるかに簡単です。

ヘッドレスコマースソリューションは、フロントエンドとバックエンドが別々に展開されるため、俊敏性も向上します。 敏捷性がビジネスの大きな差別化要因になっているため、ヘッドレスへの関心が高まっています。

ヘッドレスコマースソリューション：誇大広告を切り抜ける

しかし、ヘッドレスコマースとは正確には何ですか？ テクノロジーやマーケティングの世界ではよくあることですが、最新の光沢のある流行語にとらわれて、数年前のビッグデータや人工知能/機械学習を振り返り、できるだけ多くの会話に取り入れていく傾向があります。 。

しかし、人々が物事を実際に定義できない場合、その物事の周りの水はかなり濁る傾向があります。 それはまさにヘッドレスコマースで起こっていることです。

マーケターに苦労することはできません。 水を濁しているのは彼らだけではありません。 多くのベンダーが、ヘッドレス、クラウド、API、およびマイクロサービスを統合することにより、意図的またはその他の方法でミックスに追加しています。 彼らには議題があるので、これらの間の境界線を曖昧にすることは彼らの利益になります。 そして明確にするために、それらのどれも同じではありません。

簡単に言えば、ヘッドレスコマースとは次のことを意味します。

1. フロントエンド/ストアフロント/グラスはコマースエンジン（つまり、バックエンド）から切り離されています。
2. 分離されているため、API呼び出しを介した価格設定やプロモーションなどのバックエンド機能を消費します。
3. したがって、定義上、コマースプラットフォームがヘッドレス展開をサポートできるようにするには、コマースバックエンド機能のAPIカバレッジが必要です。

飛び込んで、ヘッドレスとは何か（そしてヘッドレスではないもの）、それがどこから来たのか、そしてそれが誰のためにあるのかを詳しく見てみましょう。

ヘッドレスコマースは新しいものではありません

用語自体はここ数年で勢いを増し始めたばかりかもしれませんが、ヘッドレスの概念はそれほど新しいものではありません。 上記のように、これはAPIファーストのアプローチであり、フロントエンド/プレゼンテーション層/ガラスがコアから分離されています（APIを使用）。

たとえば、SAP（および以前のHybris）では、10年以上にわたってRestful APIレイヤー（Omni-Commerce connect）を介してコマース機能を有効にしてきました。 SAP Commerce（オンプレミスおよびクラウド）を実行している3500以上の顧客の約半数は、サードパーティのCMSまたは特注の分離されたストアフロントを使用してヘッドレス方式で実行しています。

重要なのは、話題に騙されないことです。 ヘッドレスが登場したばかりではありません。

純粋なヘッドレスコマースソリューションはすべての人に適しているわけではありません

ヘッドレスは、他のすべての場合と同様に、すべての人に適しているわけではありません。 手始めに、それは複雑です。 開発者は、複数のコードベースにまたがるスキルの深さと幅を持っている必要があります。

しかし、それだけではありません。 特注のプレゼンテーション層/ストアフロントは、フロントエンドのフレームワークとライブラリ（Angular / React / Vueなど）を使用して、または最低限でもパートナーソリューションを介して完全にゼロから構築する必要があるため、ITの成熟度と開発能力が必要です。 これらのカスタムフロントエンドは通常、ベンダーがサポートしていません。

さらに、特注のフロントエンドは通常、ITの助けを借りずにフロントエンドを設計および更新するビジネス実務家の能力を制限します。 それがあなたのビジネスにとって重要な考慮事項である場合、ヘッドレスのみのコマースソリューションはあなたに適していないかもしれません。

良いニュース：ベンダーは、100％のAPIカバレッジと、ゼロから構築する必要のない分離されたストアフロントを備えた「ヘッドレスで正面からの」機能を提供します。 このアプローチにより、フロントエンドの開発とプロジェクト全体の納期が短縮されます。

ヘッドレスはマイクロサービスと同等ではありません

冒頭で述べたように、一部のベンダーは、ヘッドレスとマイクロサービスを混同することで意図的に水を濁しています。 記録をまっすぐに立てましょう。

いいえ、マイクロサービスはAPIと同等ではありません。 いいえ（ここでは「外部」の声を使用しようとしています）、マイクロサービスベースのアーキテクチャはヘッドレスの前提条件ではありません（一方、APIは必須です）。

Martin Fowler氏によると、「マイクロサービスアーキテクチャスタイルは、単一のアプリケーションを小さなサービスのスイートとして開発するためのアプローチであり、それぞれが独自のプロセスで実行され、軽量のメカニズム（多くの場合HTTPリソースAPI）と通信します。」

あなたはその権利を読んでいます–マイクロサービスはAPIを介してその機能を公開しているため、補完的であり、互換性のない概念です。 マイクロサービスベースのアーキテクチャを、アプリケーション全体が「1つのコード」で構成されるモノリシックアーキテクチャと比較してください。 現実の世界では、完全にマイクロサービスベースまたは完全にモノリシックなアプリケーションはほとんどありません。 それらは通常、中間のどこかに落ちます。

マイクロサービスは多くのことを実行できますが、コストもかかり（多くのオーバーヘッド）、俊敏性の特効薬ではありません。 各アーキテクチャパターンの長所と短所に立ち入ることなく、マイクロサービスベースのアーキテクチャの主な利点は、大規模な開発組織がソフトウェアを構築できる速度と敏捷性であることに注意してください。 モノリシックアーキテクチャでコードを開発する時間と比較して、オーバーヘッドは小さいです。

したがって、通常は数百人の開発者が取り組んでいるAmazonのようなコマースプラットフォームベンダーにとっては非常に価値があります。 ただし、この種のアーキテクチャはすべての人にとってうまく機能するとは限りません。 これは、ITチョップとそれに対応するコマース開発リソースがない組織には特に適していません。

ガートナーがコンポーザブルビジネスアーキテクチャと呼んでいるものを検討することをお勧めします。 この交換可能なビルディングブロックのモデルにより、顧客の価値観の変化やサプライチェーンや材料の突然の変化などの要因に応じて、ビジネスは必要に応じて再編成できます。 これらのビルディングブロックまたはモジュールは、マイクロサービスだけでなくマクロサービスでもかまいません。

Gartnerによると、このアーキテクチャは、発見によるスピード、モジュール性による俊敏性の向上、オーケストレーションによるリーダーシップの向上、自律性による回復力を提供します。 これは、組織が数日のうちにビジネスモデルを完全に再考し、ピボットする必要があった、または破産するリスクがあるパンデミックの間よりも重要でした。

さて、なぜ一部のベンダーがヘッドレスとマイクロサービスを混同しているのか疑問に思っているのなら、その答えはエンタープライズソフトウェア市場自体と同じくらい古いものです。 新しい光沢のある機能を強調することで、新興ベンダーは、プラットフォームや機能の堅牢性のように不足している機能から焦点をそらすことができます。

コマースプラットフォームを選択する際には、最新のアーキテクチャが間違いなく重要な考慮事項ですが、機能の豊富さやビジネスユーザーに力を与える能力を犠牲にすることはできません。

ヘッドレスはここにとどまる

タッチポイントの数が増え続けるにつれて、ヘッドレスコマースはどこにも行きません。 プラットフォームを選択するときは、今日だけでなく明日も、ビジネスに適用できるすべての機能要件と非機能要件を考慮してください。

今日の仕事をするかもしれないが、将来の成長をサポートしないプラットフォーム（例えば、国際的なローカリゼーション）を選択することは近視眼的であり、将来的にはことわざを蹴るだけになります。

最後に、一部のベンダーが明るく輝くオブジェクトを見てほしいという事実は、他の要件が突然問題にならないという意味ではありません。 製品情報管理、Webコンテンツ管理、注文管理、B2B機能、B2C機能、およびパーソナライズが不可欠です。

一部のベンダーが言っていることにもかかわらず、堅牢な機能とレガシーアーキテクチャを混同するという罠にはまらないでください。