Blog

アーキテクチャを確立することは、当然のことながら、ほとんどの企業にとって神経を痛めるプロセスです。インフラストラクチャとソリューションアーキテクチャ全体で技術的な決定を下し、デジタルランドスケープの将来に影響を与えます。テクノロジーとソフトウェアが急速に進化しているため、誤った決定がデジタルの無人の土地に真っ向から着地する可能性があることを十分に理解しています。

何年もの間、競技場は比較的安定していた。市場は、「すべてを1つの屋根の下で」提供するコンテンツ管理プラットフォームでいっぱいでした。コンテンツ管理、eコマース、オンラインマーケティングのいずれを求めていても、通常は、これらすべての機能などを提供するプラットフォームのコレクションを候補リストに入れることができます。それはすべて、単一の製品を選択することでした。単一の決定ですが、大きな決定です。

ただし、近年、テクノロジーが新しい予期しない道に向かって進んでいるため、マイクロサービスアーキテクチャが実行可能な代替手段として浮上しています。従来のモデルの認識されている弱点に挑戦するこの新しいアーキテクチャタイプは、単一のCMSではなく製品のコレクションに依存して、デジタルランドスケープの基盤となる機能を提供します。たとえば、Kentico KontentなどのContent-as-a-Serviceプロバイダーがコンテンツの作成と配信を処理し、ユーザー認証または承認、eコマース、連絡先管理、パーソナライズ、最適化テストを処理するために個別の製品が導入されます。必然的に）Software-as-a-Serviceモデルで動作します。機能の分離により、企業はニーズに合った製品にアクセスでき、スケーラビリティと柔軟性をサポートし、最新のDevOpsプロセスのおかげで市場投入までの時間を短縮し、正しく設計されていれば投資を合理化します。

私たちが話す多くの人にとって、メリットは見逃せないほど良さそうに聞こえ、マイクロサービスモデル（サービスとしてのコンテンツを含む）への関心が高まっています。しかし、それが良い音であるからといって、それがあなたに適しているとは限りません。コンサルタントおよびストラテジストとして、一歩下がって全体像を見ることが重要です。

プロジェクトタイプの愚かさ

従来のCMSとマイクロサービスという2つの非常に異なるオプションに直面した場合、最も一般的な誤解は、各オプションが特定のタイプのプロジェクトを優先するというものです。真実と違うことがあってはならない。プロジェクトタイプを使用して、従来のCMSまたはContent-as-a-Service（CaaS）プロバイダーのどちらを採用するかを決定しようとすると、問題が発生することがよくあります。

簡単な答えはないのが現実です。あなたとあなたのビジネスのための正しいルートを決定することはいくつかの要因に依存します、そしてそれらすべてはあなたに最良の推薦を提供するために注意深く考慮される必要があります：

• 機能/プロジェクト
• テクニカル
• インフラ
• データ
• 人員
• 所有コスト

推奨事項の作成

理解しておくべき重要なことは、一人でこのレビューを実施できる可能性は低いということです。最良の結果を得るには、アーキテクト、SaaSエキスパート、DevOps、トレーナーから専門知識を取り入れた、多分野にわたるチームが必要になることがよくあります。これは、この推奨事項の作成を支援するために、戦略的な配信パートナー（デジタルエージェンシーなど）に頼ることを意味する場合があります。セクターに関する彼らの経験と知識は不可欠です。チームを配置すると、各要素を調査できます。

機能/プロジェクト

すべての要因の中で、これはしばしば最も難しい場合があります。ほとんどの企業やデジタルエージェンシーは、反復型開発に誇りを持っているアジャイルモデルにシフトしています。ここでは、プロジェクトの要件を満たすために必要な機能を予測することで、少し問題を解決します。

簡単にするために、機能をグループ化できます（たとえば、コンテンツ、ウィジェット、eコマース、フォーム、パーソナライズ）。あなたの目的は、「すべてが1つの屋根の下にある」従来のCMSが、他の一連の製品と連携して機能するCaaS製品（純粋にコンテンツの作成、管理、配信に焦点を当てている）よりも価値があるかどうかを理解することです。大変な注文です。正確な機能は完全には定義されていない可能性が高く、アジャイル開発では常に状況が変化します。これは、必要な前提条件を備えた非常に高レベルのビューです。

テクニカル

従来のCMSとCaaS製品はどちらも、フロントエンド（ユーザーに表示されるもの）とバックエンド（コンテンツ管理とビジネスロジックが存在する場所）の分離に向かっています。もちろん、従来のCMSがMVCモデルを利用していることを前提としています。ただし、これらは2つの異なるアーキテクチャモデルであり、それぞれが進行中の開発と保守に影響を及ぼします。

「技術的」とは多くのことを意味する可能性があり、もう少し具体的にすることが重要です。理想的な世界では、すべての角度をカバーしますが、現実には、最も重要な領域または最も価値の高い領域に焦点を合わせることがしばしば求められます。次のリストは、時間と労力を費やす場所の良い出発点です。

1. ロードマップ。ロードマップでは、製品自体のロードマップを検討しています。具体的には、これらの製品がどのように適応しようとしているのか。 CaaSの世界では、アプリケーションでコンテンツを消費するために使用するAPIが唯一の懸念事項であるため、これはあまり関連性がなくなります。変更を検討する必要がありますが、影響は少ないと予想できます。ただし、従来のCMSでは、これがはるかに重要になります。 「すべてが1つの屋根の下にある」ソリューションは、技術ソリューションへの依存度を高め、変更（機能の書き直しや管理UIなど）は、予算と技術に大きな影響を与える可能性があります（特に、新しい言語やフレームワークが既存のものの場所）。
2. テクニカルスタック。現在の業界トレンドに注目している場合でも、独自の内部標準を持っている場合でも、この意思決定プロセスでは、技術スタックの選択が重要な考慮事項になります。選択したスタックがサポートされているかどうか、および隠れた課題があるかどうかを判断するには、各オプションを順番に実行する必要があります。たとえば、従来のCMSを考えてみましょう。現在、ほとんどがMVCモデルを運用しています。しかし、私たちが本当に正直であるとすれば、それは決して「純粋なMVC」ではないか、完全な分離がないかのどちらかです。これはあなた自身の開発基準を変えて影響を与える可能性があり、先に進む前に明確な議論が必要です。
3. パフォーマンス。通常、独自のビジネス目標は特定の主要な指標に要約でき、多くの場合、パフォーマンスはそれらの主要な指標（1つではないにしても）にリンクされます。検索エンジンのランキングアルゴリズムの機能強化と追加により、ページの速度とパフォーマンスの重要性が絶えず高まっています。各オプションを順番に選択して、これらのパフォーマンスメトリックを達成するのに役立つかどうか、およびテクノロジによって導入される障害があるかどうかを慎重に検討してください。
4. SEO。パフォーマンスの観点から、SEO要件を慎重に検討する必要があります。ベストプラクティスは、あなたが行うことに組み込まれるべきです。わかりやすいURL、メタデータ、正規URL、エイリアス、リダイレクト、スキーマ、ロボットファイル、ルール、サイトマップは、考慮すべきほんの一握りのことです。製品がSEO標準をサポートしているかどうか、または追加の作業が必要かどうかを理解することが重要です。
5. ビルドと展開。組織自体のデジタル成熟度に応じて、ビルドと展開のプロセス、および分岐とリリースの戦略は、比較的単純なものからきめ細かいレベルの制御までさまざまです。あなたのプロセスは、情報を入手したり、聴衆にすばやく効率的に変更したりするのに役立つため、多くの場合、幅広い成功を収める控えめな貢献者です。各オプションが現在の（および/または望ましい）プロセスにどのように適合するかを理解すると、すぐに推奨オプションが強調されます。
6. より広い風景。ここでは、最初の評価基準（機能/プロジェクト）といくつかの重複がありますが、現在、ネットをより広くキャストしています。より広いデジタル環境を検討することが重要です。現在使用しているシステムとそれらがカバーする機能はすべて、考慮すべき重要な要素です。ここで重要なのは、オプションがこのより広い風景にどのように適合するかを理解することです。機能の重複はありますか？システム間のスムーズな統合を作成できますか？

インフラ

各オプションは、ホスティングインフラストラクチャに独自の影響を及ぼします。複数の国へのサービス提供、既存のシステムへの依存、および主要な統合を考慮すると、これはさらに複雑になる可能性があります。

従来のCMS、特にMVCモデルを使用するCMSでは、フロントエンドだけでなく管理領域とデータベースもサポートできるインフラストラクチャの種類を検討する必要があります。多くの場合、これは、仮想マシンまたはアプリケーションサービスを使用して構築された頑丈なインフラストラクチャを意味する場合があります。

CaaSを使用すると、特にCaaSだけでなく、検索、認証、eコマースなどにもSaaS製品を活用している場合、オプションが大幅に広がります。多くの場合（常にではありませんが）、より軽量なインフラストラクチャを構築できます（たとえば、静的サイトの場合はサーバーレスおよびCDN）。

オプションはさておき、あなたの出発点は、インフラストラクチャに関してあなたにとって重要なもののリストを作成することです。これは、期待するパフォーマンスのレベル、必要な復元力、または組織が必要とする暗号化とセキュリティのレベルである可能性があります。

リストが手元にあれば、各オプションを使用してソリューションを提供するために必要なインフラストラクチャ（リソース、プロセスなど）を計画できます。両方のオプションで同じインフラストラクチャを単純に削除することは可能ですが、各オプションのソリューションを改良して、より明確なビューを自分に与える機会が手元にあります。

リソースとプロセスに加えて、インフラストラクチャとアーキテクチャに関連する他のBAUアクティビティについても考えてください。アップグレード、ホットフィックス、セキュリティパッチなどを考えてください。インフラストラクチャとソフトウェアの両方について考えて、何が関係しているかを把握する必要があります。システムの保守。

データ

EU全体のすべてのバリエーションでGDPRが登場して以来、すべての組織でデータがどのように保護、転送、処理されるかについての精査が高まっています。データのプライバシーとセキュリティ（EU全体でほぼ同じ）に関しては、明らかに満たす必要のある基準がありますが、一部の組織では、規制によって「設計によるプライバシー」の理想を追求するきっかけが提供されました。最初に組織がどこに立っているかを理解することが重要であり、そのスタンスは通常、DPOまたは担当のコンプライアンスチームによって定義されます。

それを念頭に置いて、データの配置と使用方法を理解し、データのマッピングを開始できます。理想的には、GDPRに応じて組織が作成した既存のデータマップに基づいて構築します。データマップは、各オプションがデータマップにどのように適合するかを評価する上で重要です。

CaaSプラットフォームの場合、コンテンツに重点を置き、エンドユーザーデータが保存されないため、比較的簡単です。ただし、これにより、データの行き先と、これを処理するためのシステムとプロセスが整っているかどうかという問題が発生します。それをサポートするために必要な作業を検討する必要があります。

従来のCMSの場合、懸念はデータの複製とセキュリティにあります。多くの場合、これらの製品には、実行にデータを必要とする認証およびオンラインマーケティング機能が付属しており、設計が正しくないと、セキュリティ上の懸念が迅速に発生し、データ保護に関して（場合によっては不必要に）責任が高まる可能性があります。時間をかけてこれらのアイテムを注意深くマッピングし、全体像を理解してください。

人員

あなたの人々は重要な考慮事項です。編集者、社内開発チーム、またはビジネスのデジタル成熟度のいずれを検討している場合でも、各オプションがビジネスにどのように適合するかを検討することが不可欠です。これは、トレーニング、エンゲージメント、プロセスの3つの領域に分類できます。

1. どちらのオプションを選択してもトレーニングが必要になる可能性が高く、そのトレーニングは開発とコンテンツ管理の両方にまたがります。コンテンツチームと開発チームが精通しているシステムを理解し、この情報を使用して、各オプションに必要なトレーニングへの投資の可能性を評価できます。言及すべき重要な注意点の1つは、初期トレーニングだけに焦点を当てるのではなく、継続的なサポートも検討することです。
2. ほとんどの企業では、特に不適切に処理された場合、変更はかなり分裂する可能性があります。それを受け入れる人もいれば、自分の役割や仕事の生活への影響を心配する人もいます。どちらのオプションも変化をもたらしますが、変化の程度は異なります。現在の状況をガイドとして使用して、変化の程度を評価し（以前の評価基準から収集した情報を使用して）、チームを維持するためにチームとの関わりに必要な投資のレベルを定義し始めることができます。
3. そして最後に、ビジネスプロセスを検討します。オンラインへの接続がほとんどないものもありますが、通常は、どんなに希薄であっても、何らかの接続があります。そして、これはあなたがしばしば抵抗に遭遇する場所です。各オプションに対して、プロセスが（理想的な世界で、またはまったくの必要性によって）どのように変化するかを慎重に検討してください。

所有コスト

そして最後に、お金。所有コストは重要な考慮事項です。ライセンスから始めます。通常、従来のCMSには1回限りのライセンス料金があり、その後に年間保守料金がかかります。一方、マイクロサービスアーキテクチャには、サインアップしたプランに基づいて製品ごとに個別のサブスクリプションがあります。

ライセンスはほんの始まりに過ぎません。これに加えて、インフラストラクチャのコスト、継続的なアップグレードとホットフィックスのコスト（SaaS製品を使用している場合は通常マイクロサービスアーキテクチャには適用されません）、トレーニングのコスト、および変更のコストを考慮する必要があります。必ずしもすべての答えが得られるとは限らないため、これは難しい場合がありますが、機能と同様に、この最初のパスには高レベルのビューで十分です。

概要

これらの重要な評価基準は、適切なオプションの評価を行う際にすべてを網羅しているわけではありません。十分な時間と予算があれば、これらの評価基準を採用して、ますます多くの詳細に拡張するのは簡単です。ただし、現実の世界では、これらの決定を行うために必要な時間と予算が提供されることはめったになく、多くの場合、必要以上に迅速に決定を下す必要があります。

この記事で概説した評価基準が、ビジネスの継続的なデジタル進化において重要な決定を下すのに役立つ強力な出発点になることを願っています。評価基準は評価の構造を提供しますが、誰もこの評価を実施して単独で推奨することはできないことを覚えておくことが重要です。協調的で多分野にわたるチームは、はるかに大きな成功を収め、より強力なビジネスケースを提供します。

適切なソリューションの選択について詳しく知りたい場合は、 MMTDigitalにご連絡ください。プロセスのガイドと情報提供をお手伝いします。