fbpx

業務改善

OKRでビジネスパフォーマンスを向上

OKRでビジネスパフォーマンスを向上

今日、多くの高速組織は目標と主要結果(OKR)を使用して、戦略的優先事項をより早く達成しています。OKRは、真の明快さ、より高い目的意識を駆り立て、短期的なアクションを望ましい短期的なビジネス成果に合わせる強力な方法です。リーダーは組織の俊敏性と説明責任を高めたいと考えていますが、透明性、説明責任、透明性を促進するための俊敏なモデルがないことがよくあります。OKRは理想的なソリューションです。

Google、Influitive、IBM、Trendkite、TeraReconなどの企業は、OKRを使用してすばやく優れた結果を達成し、アプリを使用してこのアジャイル管理方法を運用します。OKRは、チームまたは組織が達成しようとしていることに関する定性的な声明を提供し、メトリックで結果を定量化し、結果を達成するための行動計画を推進し、それらの結果に自己反映を組み込みます。

OKRは強力なコミュニケーション手段であり、リーダーと組織の効率を劇的に向上させることができます。急成長している組織であるTrendkiteのCEOであるErik Huddlestonは、ビジネス目標の明確なコミュニケーションが高速での運用には不可欠であると述べています。

  • 目的
    四半期の定性的で刺激的な目標 ―あなたが達成することを熱望するもの。
  • 主な結果
    目的の定量的結果— 成功の様子
  • 行動
    主要な結果を達成するために必要な実行— 何をすべきか。
  • 洞察
    結果と実行からの学習-私たちにできること。

OKRにより、リーダーはより完全かつ効果的にコミュニケーションをとることができます。従来、戦略的なテーマで管理してきたリーダーにとって、主要な結果を定義することは、それらのテーマを人々が焦点を当てることができる重要な成果に変換するのに役立ちます。

指標に基づいて管理するリーダーの場合、目標は目的を提供し、人々が優れた結果に到達するように促す意欲を伝えます。OKRを組織全体に展開することで、ミッションと測定基準を各チームにローカライズできるため、関連性のある実際の到達可能な結果に完全に従事できます。四半期ごとのビジネスレビュー(QBR)を通じて管理するリーダーにとって、OKRは結果のアクセラレータであり、説明的なレポート作成と以前の四半期の結果の読み上げから、規定の定義と現在の四半期の結果の調整にシフトします。

管理方法論として、OKRは高速で効果的です

組織はOKRを使用して次のことを行います。

  1. 各四半期の初めに、組織が達成したいと考えている具体的な目標と定量化可能な結果を根本的に明確にします。望ましい結果を定義するための事前のエネルギーと努力により、実際の結果が大幅に改善されます。
  2. 組織と各チームが達成できる最良の結果を特定し、それらの結果と、より少ない結果をもたらす他のすべてのアクティビティに焦点を合わせて調整します。
  3. 進行状況と主要な結果に対するリスクを継続的に可視化し、組織がアクティブなOKR用SaaSアプリで管理されている場合、リスクを早期に対処し、面倒な運用状況の会議を置き換えることができます。
  4. ミレニアル世代に特に魅力的な、関連する目的、はしごの結果、透明性に基づいて、所有権と説明責任の俊敏なシステムを作成します。誰もが自分の所有物とそれがどのように価値を生み出すかを理解しています。
  5. オペレーショナルエクセレンスを推進し、ビジネスパフォーマンスを段階的に向上させます。一部のリーダーはオペレーショナルエクセレンスOKRを確立していますが、プロセス自体は、可能な限り最高の結果に努力を集中し、高い成果のケイデンスを推進し、各サイクルで学習をキャプチャする回顧を制度化することにより、エクセレンスを促進します。

OKRはどのように機能しますか?

OKRは、カスケードダウンして合体し、再び合体するときに最適に機能します。通常、プロセスは、組織の3〜5の目標を定義する幹部から始まり、それぞれ4〜6の主要な結果があります。次に、各幹部の直属の部下は、3〜5の独自の目標を作成し、4〜6の主要な結果を出して、幹部に次々と到達します。適切に実行されたプロセスはカスケードダウンするだけでなく、組織のOKRで対処または上位に反映する必要のある調整のギャップと運用要素を特定します。

OKRが確立されると、チームはKRに合わせたアクションプランを作成します。これらにより、必要な作業が識別され、四半期全体の主要な結果に確実に焦点が当てられます。チームと組織は、毎週のOKR中心の会話でより良い結果を達成します。営業担当者なら誰でも証明できるように、12週間は飛ぶことになります–わずか3週間の焦点をぼかすことで、チームがすばらしい結果を達成するために費やす時間の25%が無駄になります。

目的と主な結果

次の100日間の目標と主要な結果を確立して調整する

  • 幹部と監督によるOKRに関するワークショップ
  • チームリーダーとその監督のためのOKRワークショップ
  • ワークショップ中のアプリ内のすべてのOKRと関連するワークストリーム→すぐに使用可能

整列した実行

目標と主要な結果を達成するために幹部に努力を集中する

  • KRのために実施されている行動計画
  • リーダーはOKRによって積極的に管理し、透明性を確保
  • マネージャーとチームメンバーはアプリを使用して、調整と集中を維持します

成果と洞察

結果を評価し、OKRをリセットし、運用規律を改善する

  • 結果を予測して評価する-正しい目標は?正しい結果ですか?正しい焦点ですか?
  • 次の四半期のOKRを行う
  • チーム内の回顧は、ベストプラクティスを特定し、結果重視と卓越性を強化します

OKR はそれ自体が目的ではなく、積極的に業績を上げるためのツールです。それらを設定することは、プロセスの終わりではなく、始まりです– それらはあなたの実行とフォーカスと同じくらい良いだけです。リーダーは依然として説明責任を推進する必要があります。方法論とアプリは、責任を負う結果を明確にし、説明責任を促進し、意思決定と行動を促進するためのリアルタイムの事実を提供することで、リーダーの有効性を高めます。

四半期の終わりには、結果を率直かつ臨床的に見る回顧が卓越性の鍵となります。適切な目的があり、適切な主要な結果を設定し、適切な焦点があったかどうかを評価します。非難されるのではなく、学んだことの責任を持ち、次の四半期に向けてリセットします。

OKRに最適なチームは何を設定しますか?

アジャイルな高速チームは、結果と学習率の両方に高い基準を設定しました。高い所有感があり、説明責任は組織全体に行き渡っています。このタイプの組織のリーダーがオペレーショナルエクセレンスの目標を設定すると、すべてのダウンラインチームが、その機能のエクセレンスを体現する真のローカルOKRを開発し、真に所有します。

OKRの何が問題になっていますか?

OKR はすべての組織やチームに適しているわけではなく、さまざまなフレーバーや実装があります。そして、それらがぴったり合っている組織でさえ、それは学習プロセスです。リーダーシップチームと従業員は新しい筋肉を構築する必要があります。すべての新しいことと同様に、OKRの実装には時間、労力、および取り組みが必要であり、第1 四半期には完全ではありません。そうは言っても、回避できる5つの落とし穴があります。

  1. 設定して忘れます。人々はより積極的により良い結果を目指したいのでOKRを採用しますが、四半期ごとの初めにOKRを設定して忘れ、週ごとにそれらのOKRに積極的に向かわない人もいます。プロセスには時間がかかりますが、組織に価値はありません(そして、チームがどれだけ忘れられ、達成されなかったかを見たときに、四半期のマイナスの結果になる可能性があります)。
  2. チェックボックスをオンにします。セットアンドフォーゲットと同様に、一部のチームは、優れた結果を定義するのではなく、OKRを「完了」させることに重点を置いています。誰もがOKRを持っていますが、誰も気にしません。
  3. 検証なし。OKRは、チームリードとチームメンバー間、およびチームリードとアップラインエグゼクティブ間のクリーンハンドシェイクで、全体がパーツの合計であるだけでなく、合計よりも大きくなる可能性があることを確認する必要があります。いったん検証されると、チームは、組織によって認識される巨大な価値を生み出していることを知って、自信を持ってOKRを実行できるはずです。四半期の途中または終わりに断線を見つけることは、時間と善意の両方を浪費します。
  4. アクションとアクションの結果の混同。経営幹部、特に財務および営業の経営幹部は、当然のことながら指標と結果の観点から考えますが、最前線のチームと他の部門のチームは、自分の仕事の結果と結果を定義した経験がない場合があります。結果の定量化は自然な運動ではなく、多くの場合、第1四半期と第2四半期の円滑化が必要です。ヨガの先生と同等の能力が必要になる場合があります。組織が結果を定義して推進する経験を持つと、驚くべきことが実現します。
  5. OKRを埋める。勝つには、あなたとあなたのOKRが同席する必要があります。だれも彼らのOKR を見ることができず、何百ものGoogleドキュメントの中でそれらを見つけることができない場合、彼らはそれらに集中していません。さらに重要なことに、OKRを積極的に推進するには、意思決定を推進し、リスクを軽減し、四半期で可能な限り最高の結果を達成するために、毎週または少なくとも毎月の進捗状況を確認する必要があります。

前進の道:オペレーショナルエクセレンス

この構造化されたアジャイルな管理モデルを使用して、組織を運用の卓越性に近づけます。ビジョンを実行に移す手段を持つだけでなく、結果を測定し、実行に集中し、すばやく学習するための方法とツールが組織にあります。卓越性への最短の道です。

関数OKRの例

エグゼクティブチーム

単位経済を最適化することにより、成長する能力を最大化する

  • $ 310万の正味新規ARR
  • 新規取引のCAC回収期間が10か月から8 か月未満に改善
  • LTVをCACに3.7に改善
  • 粗利益率が74%から79%に移動
  • 合計128万ドルのMRR EOQ

生活のための顧客

  • 平均NPSを8に維持する
  • 四半期に更新する55,000以上のすべての顧客と会う
  • アカウントあたりの平均ユーザー数を45から90に増やす
  • 総収益維持率を83%以上に向上

私たちは、最高の人々が最高の状態で活動できるように引き付け、維持し、可能にします

  • すべてのチームにOKRがあり、主要な結果の85%を達成
  • 80%の人が、私たちの成長と発展を大切にしていると感じています
  • 採用計画の90%を達成し、すべての役割に明確なランププランがある
  • 100%の従業員が360件のレビューを持っています

マーケティング、販売、製品、オンボーディング、計測からカスタマージャーニー全体で価値を統一

  • 高価値の戦略的ユースケースを開発し、すべての機能に組み込む
  • K2を積極的に使用しているT1顧客10人
  • 25のお客様が製品を主要な管理指標に統合
  • 5つのT1顧客の声は、当社の価値差別化要因で公開されています
  • パートナーシップの定義された次のステップまたは計画を備えた3つのT1戦略的パートナーまたは仲間および3つのT2 パートナーとのミーティングから4人のチャンピオンを育成する

CORP DEVおよびBIZ DEV

買収は買収企業の成功を増幅します

  • 従業員のNPSが前年と同じかそれ以上
  • 残念な人的損失はない
  • 従業員の80%が戦略を理解し、それによって動機付けられている
  • スタンドアロンの取引サイクルタイムは、後続の4つの四半期と同じかそれより速い
  • 開発者の速度は、買収前の4分の3の10%以内

xyz 買収のビジネス価値の実現

  • 収益
  • IRR
  • 統合が完了し、カタログで利用可能
  • 1000人の販売者が有効
  • 私たちの紙のエネルギー部門における12の新しいロゴ

ビジネスの戦略的成長アドバイザー

  • 市場でのNPSは9、TRM BUのポートフォリオ分析(彼らは私たちの仕事を愛しています)
  • 10のテクノロジー企業の完全な分析と、ジェームスがAIランドスケープ(ビルド、購入、パートナー)で特定した7つのギャップを埋めるための推奨事項を提供する
  • 成長ビジョンデッキの3つの推奨事項がBUによって採用されている
  • ML または AIドメインの2人の主要プレーヤーの探索的注意に同意し、同意を得る
  • 革新的な相乗効果をもたらす初期の20社を特定する。 それぞれに対処するための高速パスをマッピングする

選択のパートナー、投資家、買収者になる

  • キカスコのカウンターパートとの資金調達を求めておらず、会社が私たちに望んでいる2つの利益を確立しない45の革新企業の仲人
  • シリーズA〜Dの1000社のテクノロジー企業の評判ベースライン調査
  • すべての経営幹部は、トップ100リストにある少なくとも3社と会って、CEOまたは創設者との個人的な関係を構築します。
  • エグゼクティブの「トークトラック」は、これらの企業に提供できる5つ以上の価値ある戦術に支えられています

開発

高品質でスケーラブルなソリューションを提供

  • サーバーリクエストの平均正常応答時間を500ミリ秒未満に維持する
  • 毎月15未満のフィールドで報告されたバグ
  • 100%のアップタイムを維持
  • 量産コードの初期展開に関する重大なバグはありません
  • JIRAでのバグのターンアラウンドタイムは48時間未満

分析力を活用して差別化された製品を作成する

  • 6つのデータサイエンスプロトタイプを特定して実行する
  • 2つの機械学習の機会を評価する
  • チームメンバーの50%がデータ分析スキルトレーニングに参加
  • 3つのデータコード分析実験を実行する

私たちは製品の配送を所有し、毎回学びます

  • レトロの100%のリリース
  • 顧客から報告されたバグ0件
  • 量産コードの最初のデプロイに関する重大なバグはない
  • 本番環境にプッシュされたコードの100%に95%のテストカバレッジがある
  • 将来の支出を削減するために3つの自動化を探索する

私たちは自分たちの成功を祝って毎日学ぶコード忍者です

  • 主要機能の発売を100%祝う
  • 残念な損失ゼロ―忍者は置き去りにされていない!
  • 2人のQA採用
  • 今四半期の3つのソーシャルイベント
  • 2つの技術イベントに参加または主催する

顧客体験

顧客基盤を維持し拡大する

  • 定着率予測70.10
  • 65万ドルのアップグレードクォータ
  • CXは5つのランチをホストし、年末までに顧客と開発者の間で学ぶ(顧客生活の1日)
  • $ 125K更新MRR

優れたものから信じられないほどに私たちを動かすRevOps データと洞察を提供します

  • Rev Opsリクエストの100%が2月15日までにZendeskを使用
  • Revenue Ops SLAを定義して公開する
  • 四半期ごとのツール使用状況レポートの価値調査を提供する
  • 会社全体に見えるリアルタイムのRevOps ワークストリームとプロジェクトの取り込みを提供する

顧客の寿命を延ばす卓越した顧客体験を提供する

  • 新しいアカウントの100%が、週に2回以上、高価値の機能を利用している
  • 顧客の少なくとも50%が差別化された機能を使用
  • 実際の2%以内の保持予測精度
  • NPSが少なくとも6で、アクティブな顧客だけでなくすべての顧客のNPSを測定する
  • 2018年に導入されたコホートのNPS of 8

カスタマーエクスペリエンスチームは最高の状態で運営されています

  • 6人の新規採用者が第1四半期の目標を達成
  • 採用から60日以内に最初のアカウントに搭載された5つの新しいCSM
  • P1チケットの平均初期応答時間を50%削減
  • 今四半期に3つの知識構築セミナーを開催する

マーケティング

営業チームがより多くの取引を開拓、獲得、成約できるようにする

  • 今四半期のパイプライン価値が1,300万ドルの新しいリードを提供する
  • 2つのターゲットチャネルへの2つの統合キャンペーン
  • 3Kインバウンドリード
  • 500個のデモを設定する

優れた販促資料とツールで営業チームに力を与える

  • Webサイトに追加された6つの新しいケーススタディ
  • 4つの購入者ペルソナにメッセージングフレームワークとソリューションの概要を提供する
  • 販売サイクルのすべての段階の販売資料を刷新する
  • 担保の使用が20%増加
  • ホスト2セールスイネーブルメントセッション

私たちのコンテンツは、業界のソートリーダーとしての地位を確立しています

  • 今四半期の5件のブログ投稿
  • ブログの購読者が10%増加
  • ウェブサイトのトラフィックを15%増やす
  • 今四半期に3つのソートリーダーシップイベントを開催する

私たちは会社の市場を動かす情熱的な学習チームです

  • チームの100%が1つの専門能力開発スキルを識別
  • 業界会議に出席しているチームの2人
  • ベストプラクティスを共有するためのメカニズムを確立する

販売

製品とサービスの多様な組み合わせで数を増やします

  • Geronimo製品ラインの米国での予約は1,100万ドル
  • Wombatパイプラインステージ2以降で300万ドル
  • 灯台のアカウントで20ウォンバットがパイロットをコミット
  • Geronimo製品ラインのEMEA予約で900万ドル
  • 四半期ごとにすべての担当者が少なくとも75万ドルを決済

販売へのデータ駆動型アプローチで効率を向上させる

  • 完全なSalesforceカットオーバー
  • SFDCで検証されたすべての機会
  • 4倍のパイプラインカバレッジ比
  • 平均取引サイズは20.5Kから32Kになる
  • 7日以内にMQLを認定する

私たちは無駄のない戦闘機です-武装していて常に勝利しています

  • デモのローテーション、スキップ、アクティビティの目標を体系的に測定
  • 勝率を10%向上させる
  • 新しいロゴARRが$ 310万
  • 250,000ドルの新しいMRR

勝率の向上について戦略的です

  • デモの20%はC-Suite向けです
  • 取引の95%が料金体系に準拠
  • 100%の営業チームが交渉スキルのトレーニングを受ける
  • すべてのセールスチームメンバーは、1か月あたり2時間の1対1の指導を受ける

IT

ビジネスを21世紀に移行し、従業員の生活を楽にします

  • ロサンゼルスの9つの会議室で利用できるタッチプロジェクション
  • ハードウェアとソフトウェアの調達時間を30日から7日に短縮
  • すべてのオフィスでWi-Fiを100%カバー―使えない会議室はない
  • ヘルプデスクの新しいクラウドプロバイダーへの完全な移行

アプリをクラウドに移行することで、ビジネスへの投資能力と俊敏性を向上させます

  • 3つのデータセンターを閉鎖する
  • 12個のアプリをクラウドに移行する
  • データ移行時間を14日に短縮
  • ストレージとインフラストラクチャのコストを450万ドル削減

学習は私たちの情熱と優先事項です

  • ランチと月1回の学習
  • 各チームメンバーは、週に1時間、情熱的なプロジェクトに費やしている
  • 今四半期、全員が1つの新しいテクノロジー、方法論、またはツールキットを特定して学習する
  • 2つの実験プロジェクトに取り組み、結果をチームと共有します

私たちの未来の建築家になる

  • 企業の非PROD環境での3つのブロックチェーンの使用例
  • 非PRODでの4つのチャットボットまたはNLPの使用例
  • チームの60%がコーディング可能
  • 投資決定の100%はデータ駆動型の評価プロセスを通過します

エンタープライズ規模のOKR

多くの企業リーダーは、成長を加速するために、目的と主要結果(OKR)をビジネスサイクルに組み込むことを検討しています。OKR技術は、その可能性を最大限に引き出し、組織に意図、焦点、方向性、および段階的な成功を定義するビジネスの成果を明確にすることで、すべてのチームに画期的な結果をもたらします。

企業と投資家は成長率を主要な価値の推進力として重視しており、OKRは組織内の成長を加速させる驚異的な手段です。ダイナミックな市場では、組織はので、より高速な戦略的優先事項に繰り返す必要があり、それはだ、競争力合わせて、迅速だけでなくそれらを活性化することが不可欠。これは、高出力の推進からより高い成果の推進への組織全体の根本的なシフトです。

OKRマジックの一部は、組織全体のチームの価値創造力を利用することから生じます。MITスローンの調査によると、彼らの戦略的優先順位に関する理解と調整は通常非常に低いとのことです。理解不足は、スロームーバーのステータス、容量の損失、時間の損失、市場機会への対応の遅れに直結します。これらはすべて、より適切に調整され、加速している競合他社が直面するコストよりも高いコストです。

続きを読む

リモート会議を開始するための6つのヒント

2020年末までに、ヘルスケアプロバイダー(HCP)の約70%がデジタルネイティブになります。テクノロジーにより、これらの医師が商品や情報を受け取るための新しい道が開かれ、営業担当者とのミーティングも同様に期待され始めています。

医師の85%は、オンライン会議などの「仮想サービス」を通じて担当者にアクセスすることを望んでいます。柔軟で便利なため、より深い関与の機会を提供します。リモートコールの持続時間は平均で14分ですが、直接参加した会議では6分です。

しかしEUでは、HCPの6%のみが、対面、電子メール、および仮想会議チャネルからの通信を含む真のマルチチャネルエクスペリエンスを体験しています。本記事ではリモート会議・オンライン会議を成功に導く内容を紹介していますが、テレワーク時のセキュリティオンライン会議におけるセキュリティはこちらをご確認ください。

成功の秘訣:リモート会議で担当者に力を与える

最高の顧客エンゲージメント戦略は、対面チャネルと仮想チャネルをブレンドして、HCPの好みに応じて、担当者がHCPと話す場所、時間、頻度をカスタマイズできるようにします。医師の20%が面談を拒否または制限しているため、担当者が見づらい顧客と話し、以前は連絡が取れなかった見込み客にアクセスするには、仮想会議が唯一の方法である可能性があります。

あなたが始めるのに役立つ、私たちはきた成功のためにすぐにあなたの既存の顧客エンゲージメント戦略とスケールに遠隔会議を統合するための6つのヒントを概説します。

1. 顧客とその好みを理解する

適切な戦略を設計するには、名前とメールアドレスだけではなく、正確で完全な顧客データが必要です。完全なデータは、次のような明確で詳細な顧客の状況を提供します。

  • どのくらいの頻度で彼らとコミュニケーションを取っているか
  • 彼らがあなたのアウトリーチ活動にどれだけ迅速に対応するか
  • 彼らが好むチャネル

どのくらいの頻度で、どのチャネルを通じて顧客に到達したいかがわかったら、リモート会議がどのようにして顧客の行動を促進できるかを決定できます。

2. リモート会議の最適な使用例を決定する

顧客の好みと会社のビジネス目標の両方に適合する明確で調整されたユースケースを特定します。いくつかの例は次のとおりです。

  • リモートの詳細化とサンプリング
  • 見知らぬプロバイダーや専門家との関係を確立する
  • 到達が難しいHCPの利用
  • 詳細なフォローアップ
  • 医療従事

3. 変更管理計画を実施します

変化は反復的なプロセスです。プログラムの立ち上げとスケーリングのための強固な基盤を確立すると、成功を確実にするのに役立ちます。

  • パイロットから始める— 少人数の担当者グループでソリューションをテストすることで、組織は洞察をすばやく取得し、機能していないものを修正できます。インスピレーションをお探しですか?デジタル化するためのファイザーの考慮事項を確認してください。
  • 内部マーケティングを通じて認知度を高める— メール、ソーシャル、イントラネットサイトを通じて全社的な発表を行うことで、チームの立ち上げに興奮を覚えます。重要なトレーニングへのリンクとソリューションに関する情報を必ず提供してください。
  • ゆっくりと慎重に拡張します— 新しいツールに適応する時間を顧客に対応するチームに与えます。システムでユーザーをトレーニングした後、新しいテクノロジーをワークフローに統合する方法を学習できるように、月に1回リモートミーティングをホストすることを検討してください。
  • カスタマーエクスペリエンスが最も重要です— 医師も新しいツールの使用方法を学ぶ時間を必要とします。ブラウザやモバイルなど、顧客の経験について担当者をトレーニングし、必要なガイダンスとトラブルシューティングを提供できるようにしてください。

4. デジタル向けにコンテンツを最適化する

  • 既存のコンテンツから始める— 承認されたコンテンツのライブラリを確認します。ほとんどの場合、ほんの少しの調整でコンテンツを再利用できます。
  • モバイルを含むデジタル表示用にコンテンツをカスタマイズします— デジタルチャネル用のコンテンツを作成するときは、コンテンツのサイズ、色、フォント、画像を考慮してください。対照的な色と小さなフォントを使用した複雑な図は、iPadではうまく変換されません。内容はシンプル、明確、簡潔にしてください。その他のヒントについては、デジタルエクスペリエンスを最適化するためのベストプラクティスに関するこのインフォグラフィックをご覧ください。
  • トークトラックを再確認する— 長時間(14分以上)の会議に対応できる十分な発言ポイントを担当者が確保できるようにします。

5. 成功の指標を特定する

組織が将来のリモートエンゲージメントプログラムをどのように進化させ続けることができるかを最もよく理解するには、成功の明確なマーカーを設定します。いくつかの指標は次のとおりです。

  • 会議の数— より多くの会議を確保していますか?
  • 会議の長さ— 会議は長くなりますか?もしそうなら、どのタイプのコンテンツがより長い会議でより良いパフォーマンスを発揮しますか?
  • 見落とされたHCPの数に達しました— 以前に面談でアクセスできなかった顧客または見込み客との電話をスケジュールしましたか?
  • 確立されたフォローアップ会議の数— より多くのフォローアップ会議をスケジュールしていますか?これらの会議のうち、対面会議と仮想会議の数はいくつですか。

6. 顧客からフィードバックを得る

成功のための最も重要なマーカーは、HCPの経験です。顧客がリモート会議から価値を得ているかどうかを確認します。

  • 顧客の調査— 最初の仮想会議の後に顧客に短い調査を送信します。ドロップオフを避けるために、アンケートは短く(最大5分)してください。
  • 直接フィードバックを求める— コールの最後に数分おいて、ツールについて顧客に尋ねます。
  • 顧客データの分析— 会社のCRMを通じて顧客エンゲージメントを監視して、HCPが好むチャネルと、デジタルチャネルを通じて共鳴するコンテンツを把握します。
  • デジタル戦略を頻繁に調整する— ライブと仮想のタッチポイントを適切に組み合わせて顧客を引き付けることは、常に変化するプロセスです。顧客からのフィードバックの安定した流れは、戦略を分析および修正するのに役立ち、顧客に最高のエクスペリエンスを提供し続けることができます。

サブスクリプションの世界で新しい収益基準に引き上げる

サブスクリプションセクター内のビジネスには、新しい考え方、新しいビジネスモデルが必要です。サブスクリプションエコノミーでは、1回限りの独立したトランザクションではなく、長期にわたる定期的な顧客関係に焦点を当てる必要があります。その変化に伴い、新しいデータ要件、価格設定構造、価格請求モデル、会計ニーズなど、新しい課題が数多く発生します。

企業と顧客との関係を適切に測定および追跡することの重要性は、十分に強調することはできません。

この時にヒープASCの形で世界中の企業に求められる耐震変更606 / IFRS 15、「顧客との契約から生じる収益」により、新たに収斂収入ガイダンス財務会計基準審議会(FASB)国際会計基準審議会(IASB)、2017会計年度までに義務付けられる予定です。

今日、すべての企業は、収益を計算する最善の方法を決定する際に課題に直面しています。以下のためにサブスクリプション事業、これらの課題が拡大しています。

サブスクリプションビジネスの新しい標準の「新しい」とは何ですか?

良いニュースは、これらの「新しい」基準の存在により、収益の認識と記録の方法における影響と変化の可能性を評価するために、すべての企業がビジネス慣行と金融システムを徹底的に自己検査する必要があることです。それほど良くないニュースは、このタスクが小さな雑用ではないということです。

以前の業界固有の基準のコレクションでは、収益を認識するために4つの条件を満たす必要がありましたが、新しい収益基準では、トランザクション自体の経済的実体に焦点を当てた原則ベースの会計概念を導入しています。つまり、顧客に請求されているかどうかに関係なく、約束された商品またはサービスが顧客に提供されたら、収益を認識しなければなりません。

定期的な収益があるサブスクリプションビジネスの場合、これらの新しいガイドラインの影響は、特定のビジネスモデルや、販売する製品やサービスの種類によって異なります。

新しい標準では、履行義務(POB)は、契約の領域内の個別の商品またはサービスとして定義されます。これらは、顧客への転送の同じパターンで実質的に同じであり、履行義務が特定の時点で満たされるようにします。

現在のGAAPでは、契約の要素、つまり契約の成果物に独立した価値があるかどうかを識別する必要があります。その要素は、新しいガイダンスの履行義務と同じ場合も、そうでない場合もあります。答えは、認識される収益のタイミングと金額の両方に影響を与える可能性があります。

次に、使用量ベースの価格設定を検討します。既存のガイダンスでは、価格は固定または決定可能である必要があります。会計の各単位に割り当てることができます。顧客が使用量または消費量に基づいて課金される場合、通常は実現されるまで配分されないため、契約全体に収益が記録される可能性があります。新しいガイダンスでは、変動対価を見積もり、取引義務全体に取引価格を割り当てることが求められます。収益は、各履行義務が満たされたときに認識されます。

この特定のトピックは、FASBが可能な説明を検討し続けるため、現時点では多少混乱しています。

サブスクリプションの修正に関しては、現在の基準の修正に関する明確なガイドラインがないのとは対照的に、新しい基準の修正に対する会計処理は本質的に非常に規範的です。

契約を結ぶための費用については違いがあります。今日では、契約を獲得するための特定のコスト(たとえば、販売手数料)を費やすことが一般的ですが、そのようなコストは新しいガイダンスの下で資産化する必要があります。

最後に、1回限りの前払い料金に関する変更を検討してください。販売価格がある場合、通常、そのような収益は最初のサブスクリプションの存続期間にわたって認識されます。ただし、新しいガイダンスでは、顧客が最初のサブスクリプション期間の後にそのような契約を更新するマルチレベルの権利を持っている場合、最初のサブスクリプション契約期間または更新期間、あるいはその両方をはるかに超えてその収益を認識することも必要になる場合があります。

ここで説明するすべてのシナリオでは、多くの変更が会社の財務報告に影響を与える可能性があるため、重要な判断を行う必要があります。

これらの変化にどのように対処するのが最善ですか?

サブスクリプションビジネスに関する新しい基準の潜在的な影響の少なくともいくつかを理解した上で、あなたがたぶん疑問に思うのは、これらの新しい収益基準にどのように取り組むかです。

据え置き収益レポート

  • プラットフォームは、すぐに使用できる据え置き収入レポートを提供します。つまり、顧客は
  • 一定期間の収益認識をスケジュールします。
  • 主に請求書発行やその他のイベントに基づいて収益認識をトリガーします。
  • 繰延収益/獲得収益に関するレポートを作成し、仕訳を作成します。

サブスクリプションモデルを使用する企業は、サブスクリプションのライフサイクルが複数のアップグレード、ダウングレード、およびダウンストリームの収益に影響を与える可能性のあるその他の修正を含む可能性があることを理解しています。優れたSaaSは、これらのすべてのイベントの追跡とアカウンティングのプロセスを、手動による介入を最小限に抑えて自動化します。

優れたSaaSは、収益スケジュールを作成し、請求イベントに基づいて会計期間全体に収益を分配できるようにするオープンデータモデルとAPIを提供します。

サブスクリプションベースのビジネスモデルの収益認識を自動化する包括的な機能セットの一部として、優れたSaaSは、MRRの評価可能な収益分布をグラフ形式と表形式の両方で表示および提示できます。選択したシステムを使用してこれらのエントリをダウンロードおよびインポートできるように、要約ジャーナルエントリの作成プロセスを自動化できます。

RevPro 製品ライン

優れたSaaSは、完全に構成可能であると考えてください。つまり、特定の顧客またはビジネスカテゴリに依存していません。RevPro は、RevRec ルールを管理の観点または割り当ての観点から構成できる完全なフレームワークを提供します。

RevPro がサポートするさまざまな構成のほんの一部には、バンドル取引とバンドル間での割り当て機能、さまざまな方法によるスタンドアロン販売価格(SSP)価格の決定、およびパフォーマンス義務に対する処理の設定と適用が含まれます。

また、RevPro では、契約の修正を追跡する一連のルールを通じて、契約の変更と新しい要素の重要な要素である複数要素の取り決めが可能です。RevProは、ビジネスケースに基づいて、コストを見積もり、コストを調整し、コミッション、ロイヤルティなどに関連する他のコストを処理する機能を提供します。

収益を予測するための新しいガイダンスでの要件は、RevProの予測モジュールによって処理されます。このモジュールは、最先端のルールエンジンを使用して、複数の書籍セットで収益とコストを予測します。

RevPro は、幅広い収益認識状況とオプションをカバーするソリューションを提供します。多くのサブスクリプションモデルを簡略化できますが、他の会社では、会社全体の収益認識プロセスを自動化するための非常に堅牢なソリューションを必要とするさまざまなモデル、複数の製品ライン、部門、および地域があります。RevPro はこの自動化された機能を提供し、複雑な収益状況を正確に認識するために必要な時間を簡素化および削減できます。

5つのステップ—構成済み

  1. 顧客との契約を特定する
  2. 個別の履行義務(POB)を特定する
  3. 取引価格を決定する
  4. 取引価格を割り当てる
  5. 履行義務が満たされたときに収益を認識する

この新しい5段階の収益認識モデルは、現時点では、新しい標準への移行を任されているすべての人によく知られています。RevPro 内の特定の構成のコンテキストで各ステップを調べてみましょう。

契約を特定する

RevPro は、収益契約のグループ化ルールと呼ばれる概念を使用します。これは、取引全体で異なるトランザクションラインを識別するために使用される主要な設定です。RevProのお客様は、これを使用して半径データポイントを識別します。これらのグループ化ルールでは、PO番号に基づいてデータポイントを指定するだけでなく、新しい収益契約を作成するために、着信イベントに基づいてトランザクションラインをグループ化することもできます。基本的に、これは製品内の最初のレベルのグループ化です。

履行義務を特定する

RevPro 内の次のレベルのグループ化は、Performance Obligation(POB)Configurator を使用した履行義務です。これには2つの側面があります。顧客のニーズを特定して、製品の特性が本質的に異なるかどうかを特定し、特定の時点にあるのか、それとも長期にわたってあるのかをシステムに伝えます。

現在のガイドラインではトランザクションラインでの収益の解放が許可されていますが、新しいガイドラインでは比較可能な概念が提供されておらず、POBでの収益の延期と解放が必要です。会計は技術的にはラインレベルで作成されますが、POBレベルでロールアップされるため、そのすべてについてレポートすると、特定のPOBの場合、その日付の特定のPOBの繰延残高または契約債務残高が表示され、その月の収益活動を把握できます。

これらのデータポイントは、開示レポートの観点からは不可欠になります。POB、その処理、およびそれに関連する線は、その特定のPOB 内およびその周りで何が起こっているかを示す360度のビューに含まれています。

履行義務テンプレートを定義すると、収益のトリガー、収益の処理、毎日計算するか、月次の一部または月次の固定スケジュールなどの情報を取得するのに役立ちます。

さらに、RevPro では、コストを収益資産に依存させることも、独立させることもできます。新しいガイダンスの一部として、費用の実務上の便法では、収益サイクルが12か月を下回る場合、費用を資本化する必要はなく、すぐに認識できます。

特定のシナリオをいくつか見てみましょう

シナリオ1:履行義務には、契約の開始時に4行ありますが、1か月後、ソースシステムから新しい行が入ります。グループ化ルールに基づいて、その行は同じPOBに追加されると予想されます。RevProはこの状況をどのように処理しますか?

そのシナリオは、契約のPOBに関連付けられて取得される新しいラインであるか、POB内の既存のラインの変更であるかに関係なく、契約の修正と呼ばれます。RevProには、いくつかの事前定義された契約修正規則が含まれています。

シナリオ2:価格変更が発生し、その価格変更が将来のみの場合、それは本質的に見込みがあると識別できます。内RevPro 、限り適切な割り当て方式をれる将来の変更を処理するために選択され、正確な計算が行われます。

取引価格を決定する

簡単なレベルでは、すべての履行義務の販売価格を合計すると、基本的に取引価格が決まります。ただし、契約開始時の遡及割引やボリューム割引などの変数の可能性を考えると、その時点での取引価格は不明確であるか、または時間とともに変化する可能性があります。

変動対価(VC)は、新しいガイダンスを考慮に入れて、判断に基づいて新しい要件です。基本的に、割引は契約の一部として事前に見積もる必要があります。RevPro 内で、ユーザーがVCタイプを設定し、VCが何であるか、割り当てとアカウンティングへの影響、発生するタイミングと発生しないタイミングを含むデータポイントをキャプチャするVCフレームワークが定義されています。RevPro は、層別化値をアップロードするためのフレームワークを提供します。システムは利用可能な対価を獲得し、アプリケーション全体で会計を実行します。

シナリオ:ボリュームディスカウントの例で、契約の開始時に変動対価が計算されたとしましょう。ボリュームの目標が達成されると、ラインの4分の2が下がると、VCは変更される可能性があります。

RevPro では、VCへの調整は追跡されます。システムはその契約内の特定の時点を確認し、それらのエントリを再予約してGLにポストバックします。

取引価格を割り当てる

新しいガイダンスでは、ベンダー固有の客観的証拠(VSOE)は本質的にスタンドアロンの販売価格(SSP)に置き換えられています。RevPro は、履歴トランザクションを分析し、割り当てに使用するための価格を提示するSSPアナライザーを提供します。過去の取引金額が分析に利用できない場合、RevPro ではユーザーがシステムに価格をアップロードすることもできます。さらに、RevPro は、着信トランザクションラインからの式ベースのアプローチを使用して価格を決定できます。

RevPro がSSPを決定するために使用する3つの方法は、アナライザー、手動アップロード、または式ベースのSSPです。

収益を認識する

契約が定義され、POBが識別され、取引価格が決定され、変動対価とSSPが計算されると、割り当てを実行できます。商品やサービスの提供時に収益を認識できます。

通常のサブスクリプション注文では、収益認識のトリガーポイントは多くの場合、請求書の形式であり、期間の終わり、または単に特定の日付の終わり、または会計期間の終わりに、顧客に請求することができます。会社は収益を認識できます。

RevPro は、ユーザーがトリガーイベントを定義するフレームワークを提供します。特定のイベント、金額、または数量に基づいて収益をリリースするかどうかにかかわらず、ユーザーは収益をリリースするために上流システムからのデータポイントを定義する必要があります。

このようなイベントはPOBテンプレートに関連付けられ、コスト、収益、またはさまざまな考慮事項全体の扱いを決定するため、パフォーマンスの義務が収益契約全体の中心であるという事実を強調します。

API、DevOps、マイクロサービスの世界におけるレガシーの近代化

要約

主な研究課題

  1. 現代のアーキテクチャはどのように見え、どのようにしてイノベーションを可能にしますか?
  2. この最新のアーキテクチャにおけるレガシーシステムとは何ですか?
  3. 新しいデジタル企業をゼロから構築することは、真に近代的な金融機関になる唯一の方法ですか?

金融サービスにおけるデジタルトランスフォーメーションの焦点の多くは、顧客に面した外部チャネルにあり、実際には、実質的なトランスフォーメーションの機会はフロント、ミドル、バックオフィスにまたがっています。変化の激しい期待に対応するため、金融機関は新しいレベルの俊敏性と自動化を実現する必要があります。

マイクロサービス、API、およびDevOpsの組み合わせにより、金融サービス会社はレガシーアーキテクチャを変換し、これらの重要なシステムの制限を分離できます。APIは、従来のバッチベースのオンプレミス統合アプローチと、オムニチャネル配信を支えるクラウド、モバイル、ソーシャルアプリケーションとのリアルタイムデジタル統合との間の橋渡しも作成します。

過去10〜20年の間に、サービス指向アーキテクチャー(SOA)とWebサービスを利用するシステム統合テクノロジーは大幅に改善されましたが、コアビジネスオペレーションアプリケーションとビジネスオペレーションプロセスはほとんど変わっていません。モノリシックレガシーシステムは、顧客に付加価値サービスを組み込むための金融機関の取り組みを妨げ続けており、俊敏性とイノベーションの面で課題を提起しています。

主要な銀行および保険組織は、マイクロサービス、DevOps、およびAPIの組み合わせを使用して、より柔軟で俊敏な開発および展開方法を使用する最新のデジタルアーキテクチャに移行しています。

デジタルシフトとイノベーション

テクノロジーの根本的な変化と、急速な消費者の採用、およびユーザビリティに関するスタッフの期待の高まりにより、金融サービスの提供と実装の方法が大幅に変化しました。

物理機関から仮想機関への移行

ほとんどは、デジタルの始まりをWebの台頭と関連づけています。しかし、Web の台頭は、初期のレンガとモルタルから電話への移行に続き、高価な支店と高い通りの存在感が、コールセンターを通じて運用コストを抑えて提供される金融サービスに取って代わりました。多くの重要なブランドがこの変化から1980年代に成長し、現在も営業している大規模な既存企業を形成しています。

Webの台頭とオンラインへの移行により、世界は24時間年中無休のモデルに移行し、セルフサービスとeコマースが王様となりました。多くのレガシーシステムとレガシービジネスモデルは、24時間年中無休ではなく12時間/週6日に近かったため、この移行により、24時間年中無休のサポートを売り込む新規参入者が増加しました。コンタクトセンター機関の新しいバッチでさえ、これらの新しい要件に対応するためにスクランブルをかけなければなりませんでした。

これに対応するために、多くの既存の金融機関は、既存のシステムの隣に隣接するアーキテクチャを構築しました。既存の製品と販売アプローチをサポートしていましたが、24時間365日ではなかったシステムです。

OMNICHANNELとEARLY APIの使用

Webの台頭、そして今やスマートフォンの登場後、Web専用または電話専用の施設というアイデアはニッチな遊びのために予約されました。大規模な金融機関やカスタマーサービスに誇りを持っている金融機関は、Webなどの1つのチャネルで着信要求をサポートする必要があるが、支店や電話でそれらを正常に完了する必要があることに気付きました。新しいチャネルごとに新しいテクノロジーのスタックを追加するというコンセプトは、コストが非常に高くなるだけでなく、顧客のニーズも満たしませんでした。

成熟が発生し、SOAは、さまざまなチャネルが消費できる既存のシステムからサービスを公開する手段と見なされました。ここでの目標は、複数のチャネルを正常にサポートし、それらのチャネル間で一貫性を持たせることでした。

初期のSOA APIはソースから直接生成されることが多いシステムを目的とする手段でした。

このパターンでは、エンゲージメントのシステムを可能にするために、SOAサービスが記録システムの前に構築されていることがわかります。この場合、統合レイヤーは、チャネルで可能な限り多くを有効にするために利用可能なものを十分に使用します。

金融機関はこれまで以上に複雑なチャネルを実現しています

新しいチャネルの種類と複雑さの増加に伴い、APIは費用対効果の高い導入に不可欠です。以下は日本のみずほ銀行の2つの例です。

みずほ銀行の絵文字の使用は珍しいですが、小売業界全体および金融サービスにおけるAIを利用したチャットボットの増加は並外れています。

API-FIRST

現在の変化は、APIレイヤーの品質が価値の主な推進力であると観察しています。現代の金融機関を構築することの副産物であるどころか、APIはイノベーションを可能にし、より広いエコシステムへの参加を可能にし、コストと配信のタイムスケールの両方を削減する資産です。APIファーストの設計哲学により、API自体に重点が置かれ、企業全体で共有される資産となります。

APIは単一のレイヤーとして表現されています。一部の企業では、パブリックAPIは単一のAPIゲートウェイを通じて単一のレイヤーとして提供されています。マイクロサービスアーキテクチャでは、このAPIは多くの個別のアプリケーションとして実装でき、集中型の実装を必要とせずにマイクロサービスメッシュとして動作する可能性があります。

それがどのように実装または実現されるかに関係なく、適切に設計されたAPIにより、内部システムとサードパーティ組織の両方が金融機関内からサービスを活用できます。さらに、金融機関はパートナーからの商品を提供し、その提供物を独自のチャネルに織り込むことができます。これにより可能になる機会については、次のセクションで詳しく説明します。

ここでは、Intesa San Paoloがパートナーをフロントエンドでアーキテクチャに組み込み、サードパーティがバックエンドでトランザクションサービスを提供しています。

イノベーションを可能にする

一部の人々はフィンテックスが最終的に銀行を陳腐化させると信じていますが、現在の現実は、銀行とフィンテック企業がイノベーションのための協力的パートナーシップに入り、銀行が革新的な製品、新技術、スタートアップ文化にアクセスできるようにし、フィンテック企業が資金調達、規制、専門知識と顧客へのリーチにアクセスできるようにしていることです。fintechsを有効にする銀行、およびfintechsを有効にする銀行のプレス発表は引き続き見られます。この傾向は、保険業界およびインシュアテック企業との関係においても広く見られます。

これらのAPIパートナーシップの多くは、レガシーテクノロジーに組み込まれた顧客データとサービスに依存しています。銀行とフィンテック企業、保険会社、保険会社は、API を連携させて活用することでそれぞれの強みを活用し、各エンティティが単独で行うよりもはるかに顧客体験を向上させます。

モジュラーファイナンシャルサービス

マイクロサービス、DevOps、Open APIを活用する場合、金融機関は、パラダイムシフトを実行して、デジタル金融サービス企業に変身する必要があります。マイクロサービス、DevOps、Open APIは、それ自体が目的ではなく、モジュール化の手段です。これらのテクノロジーと開発アプローチを活用することで、金融機関はパラダイムシフトを実行して、モノリシックな統合金融サービスではなく、モジュラー金融サービスのプロバイダーに変身することができます。

主な研究課題1

現代のアーキテクチャはどのように見え、どのようにしてイノベーションを可能にしますか?

ますます最新のアーキテクチャまたはデジタルアーキテクチャがAPIとマイクロサービスを備え、DevOpsに見られるような大幅な自動化を活用しています。

レガシーシステムの変革

レガシーチャレンジ

歴史的に、金融サービスの人々がレガシーについて話したとき、40年前のアプリケーションを実行しているメインフレームのイメージが思い浮かびました。実際、金融サービス会社のIT部門の古い警備員の多くは、コンピュータにプログラムを入れる手段としてパンチカードをまだ覚えています。

この新しいITレシピの構成要素と、従来のITアプローチと比較した相対的な利点を示しています。

この状況では、デジタルテクノロジーの新しい定義がはるかに高速であるため、レガシーシステムは俊敏性、市場投入までの速度、および製品の流通方法の柔軟性の点で金融機関を無効にするように認識されています。

つまり、レガシーシステムは遅くなりませんでした。代わりに、変更の速度、品質、コストの面で基準が引き上げられました。

セレントのレポート、2018年4月にコアバンキングトランスフォーメーションのモデルバンク賞を受賞:ザイオンズ銀行、2018年4月、ザイオンズ銀行は次のように課題を表明しました:

  • コスト:回避策の数が多いため、レガシーシステムを維持すると、最新のコアバンキングシステムを実行するよりもコストが高くなります。そのままにしておくように構築されたシステムを開くリスクはさらに多いため、統合作業はコストがかかります。
  • 柔軟性:大規模なメインフレームベースのレガシープラットフォームは、安定性と速度のために構築され、最終的には数百万のトランザクションをバッチで処理します。それらは変更されるように作られていませんでした。新規および変更の銀行機能には、継続的な開発が必要です。レガシーコアの上にモダンで柔軟なカスタマーエクスペリエンスを開発することは非常に困難であり、さらに難しくなるだけです。
  • 開発者の才能:これらのコアプラットフォームの一部に最初に取り組んだ開発者の多くは、キャリア(または人生)の終わりにいます。新しいITプロフェッショナルは、JavaやC#などの言語で記述されたより近代的なアーキテクチャに惹かれています。若い開発者は、銀行システムの相互接続性の広さを理解するのに苦労することが多く、その多くは十分に文書化されていません。これは、プロジェクトを実行する能力を妨げ、あるストリングを引っ張ると別のストリングを解く可能性があるため、大きなリスクをもたらします。(リアルタイムのアカウンティングとコンポーネント化されたアーキテクチャーを備えた)最新のコアに切り替えることは、今日オンストリームで登場するIT人材の仕事を豊かにするものと見なされています。
  • デジタル顧客に対応する能力:ハイテク企業は、デジタルで可能なことを先導しています。顧客は最新のデジタルエクスペリエンスを期待しており、レガシーコアシステムはそれを提供するために挑戦されてきました。リアルタイム、クラウドの準備、コンポーネント化、およびオープン性に関する機能が欠けているコアシステムは、今日の競争に追いつくのがより困難で費用がかかることに気づきます。そして、その課題はより困難になるだけです。

National Australia Bankの近代化から6か月後の結果は、実現可能な俊敏性と市場投入までの速度の向上の好例です。

Waterfall Vs. アジャイルと DevOps

歴史的に、IT変更プロジェクトとプログラムは、大規模なエンジニアリングの提供を連想させるウォーターフォールスタイルで頻繁に提供されていました。焦点は、要件を事前に定義してから、成果物全体の設計にありました。次に、これが構築され、徐々に強化されたテストフェーズを経て、構築されたものが要求されたものであることを証明します。

アジャイル手法と現在のDevOpsは、要求、テスト、および配信の間の時間を短縮し、複数のより短い配信で配信し、このプロセスを可能な限り自動化することを目指しています。継続的インテグレーションがビルドおよび統合テストアクティビティの自動化にどのように役立ち、次に継続的デリバリー、そしてデプロイメントが自動化の量をどのように増加させるかを示しています。

オンプレミスモノリスとクラウド内のマイクロサービス

DevOpsのOps側では、IT 変更の速度を向上させる可能性がさらに広がります。従来、ソリューションの展開では、マシンを注文し、オペレーティングシステムをセットアップし、パッチを適用し、セキュリティのために強化する必要がありましたが、それはアプリケーションを稼働させてビジネスを行う前でした。

インフラストラクチャのコミッショニングに非常にコストがかかる場合、それが高度に利用されていることを確認します。さらに、インフラストラクチャを不必要に委託しません。したがって、Web規模のアーキテクチャでさえ、限られた数のマシンで実行されました。

現在、マシンはクラウドから要求され、自動的に構成され、ネットワーク内の他のマシンに数か月ではなく数分でリンクできます。

DevOpsとAgileはIT業界にとって新しいものではありませんが、金融サービス業界の一部は、それらを取り上げるのに時間がかかりました。これらのアプローチから期待できるメリットについて実際の状況を説明するために、アーリーアダプターのHiscox がCelent Model Insurer 2015で報告した内容を以下に示します。

  • プロジェクトを予定どおりに予算内で提供します。これは、Hiscoxにとってこの規模のプロジェクトで初めてのことです。
  • このプラットフォームにより、Hiscoxは、通常の10週間のウォーターフォール配信モデルから2週間の反復サイクルに移行できるようになりました。
  • 最初の数週間(稼働後)の欠陥の数を最小限に抑えます。その数はHiscoxの予想をはるかに下回っていました。
  • 修正と製品構成の変更をより迅速に実稼働環境に提供します。DevOpsを通じて導入されたツールのおかげで、リリースは6分(平均)かかりますが、以前のテクノロジースタックでは3時間かかります。稼働前の1週間で、Hiscoxは47のリリースを実行しましたが、これは従来のデプロイメントツールでは不可能でした。
  • 発売以来、Hiscoxは9つの環境全体で週平均26回(平均)展開しています。各自動デプロイの平均コスト削減は、週あたり約7,000ポンドに相当します。これは、年間約37 万ポンドの節約に相当します。
  • 一貫性、時間の節約、手動エラーの調査、時間の節約による新しいスタッフのトレーニングの追加の利点により、コストを回避できました。ピーク時には、チームは1日に19回の展開を実行しました。

アプリケーションを独自のインフラストラクチャに数分でデプロイできる世界では、ソフトウェアアーキテクトは、コンポーネントのサイズと、インフラストラクチャの他のコンポーネントとは別にデプロイする方法を再考することができます。さらに、サーバーは使い捨てになります—サーバーが誤動作し始めたら、それを破棄して新しいサーバーを起動します。ハッキングされた、またはバグのあるサーバーを「救出」する必要はありません。

この環境では、APIは多くの独立したアプリケーションによって提供され、独自のサーバー上で実行され、自動的にテストされ、自動的に保守され、必要に応じて自動的にスケーリングされます。

マイクロサービスの作成とデプロイ

マイクロサービスは、レガシーシステムを最新化するための一般的な選択肢です。Microservicesのアーキテクチャは、小さな離散、そして個別に展開可能なサービス―いくつかのケースでは、各サービスはAPI、いくつかのロジックまたはを持つ独自のmicroapplicationあるアプリケーションコード、およびデータの提供に注力します。

したがって、この名前は多くの小さなサービスの集まりであることに由来しています。個別のサービスを使用すると、加速されたツールセットを使用する類似のマルチスキルチームが、APIを駆動する一連のマイクロサービスをサポートできます。セレントのレポート「Honey、I Shrunk the Services:Microservices in Insurance」(2017年12月)で詳しく説明されているように、APIの存在にはマイクロサービスアーキテクチャは必要ありません。ただし、一般的なマイクロサービスアーキテクチャは、より広範なAPIにまとめられたAPIの提供に重点を置いています。

エラスティックインフラストラクチャ内のマシンに迅速に展開できる小さなコンポーネントを使用すると、高度にスケーラブルで適応性のあるインフラストラクチャが可能になります。マイクロサービスは、「顧客名の取得」、「内部転送の作成」、「クレジットラインの増加のリクエスト」などのAPIを介してアクセスできる一般的なビジネス機能を提供します。マイクロサービス主導のアプローチにより、サービスの再利用が可能になり、統合コストと複雑さが軽減されます。

マイクロサービスの構造

マイクロサービスをさらに詳しく調べて、その複雑さを確認する場合、多くのマイクロサービスを構築することは、その複雑さのどれだけが自動化できるかを観察するまで、圧倒される可能性があります。

自動化とツールを一貫して使用してマイクロサービスを構築することにより、各サービスのセキュリティ保護、ロギングを使用した各サービスの監視と維持、およびパフォーマンス、フォールトトレランスに必要なキャッシングの使用、または脆弱なレガシーシステムの保護などのベストプラクティスを標準化して導入することが可能です。

マイクロサービスアーキテクチャは、マイクロサービスのビルド作業の大部分を自動化することによってのみ機能します。

レガシートレードオフ

レガシーモダナイゼーションに対する1つの答えは、すべてのレガシーシステムを取り除き、高度に自動化された高速なマイクロサービスで置き換えることです。これは賞賛に値する目標ですが、ほとんどのレガシーシステムは何万人もの労力を費やしており、複雑なルールを具体化し、複雑なデータが含まれていることがよくあります。それらを交換し、それらが提供するすべての機能を構築することは、重要な作業です。

ほとんどのレガシーシステムには、強力な機能がいくつかあります。

  • 機能する
    多くの場合、レガシーシステムは現在のビジネスとプロセスをサポートしています。
  • 安定している
    レガシーシステムは、多くのバグが修正されるほど十分に長く存在しています。年齢とともに安定します。
  • 安い
    多くの場合、レガシーシステムにはライセンス料がまったくないか、わずかです。さらに、彼らが実行するインフラストラクチャはよく理解され、最適化され、低コストで実行されます。

閉鎖するためにレガシーシステムを置き換えることは、ビジネスケースがないため、悪い投資になる可能性があります。

API指向のマイクロサービスアーキテクチャに移行することには大きなメリットがありますが、金融機関のほとんどのソフトウェアは古く、そのように構築されていないというのが単純な事実です。これらのシステムは、いくつかの点で制限がありますが、依然として価値があります。金融サービス業界は、テクノロジーを移動することには理にかなった実践的なアプローチを必要とし、そうでない場合にはレガシー資産を活用する必要があります。

以下では、金融機関および金融機関に対するソフトウェアベンダーがインフラストラクチャを最新化するために取っているいくつかのアプローチについて説明します。

主な研究課題2

この近代的なアーキテクチャのレガシーシステムとは何ですか?

レガシーは、COBOLやアセンブラーなどの特定のテクノロジー、またはシステムの時代(20 歳)であると認識されていました。今日、レガシーシステムの特徴は、変更するには遅すぎることです。

レガシーシステムとは、テクノロジーや年齢に関係なく、企業を無効にするシステムです。

新しいレガシーモダン化

目的に合った複数の記録システムがある場合は、それらを移行しないのが理にかなっています。上記のレガシー定義を採用した場合、製品システム1からNまでが無効になっていない場合、その前にAPIを構築できれば、引き続き使用するのが妥当です。ほとんどのレガシーシステムには、それらをサポートする、または回避策として機能するための周囲のシステムセットがあります。

これらの周囲のシステムは、実行と維持にコストがかかる可能性があり、レガシーシステムの影響が軽減されるため、効率を改善するための絶対的な目標となります。一方で、これらのシステムは、最初に段階的な移行アプローチを可能にするかもしれませんが、時間をかけてこれらの周囲のシステムはオフにすることができます。金融機関は、自動化ツールによってサポートされている場合、APIビルド時間を数週間から数分に短縮すると報告しています。

この技術的負債の運用コストを掘り下げるには、データがアーキテクチャを通過するときにデータが通過する変換の数を分析するだけです。レガシーSOA コンポーネント、そして最終的にはCOBOLプログラムを呼び出す異種のマイクロサービスセットを示しています。次の表は、暗号化と復号化の手順を含め、情報が変換されるたびに表示されます。

マイクロサービスの使用は当然、高度に通信可能なアーキテクチャに傾いていますが、多くの呼び出しを活用する不必要に深いアーキテクチャのコストに注意する必要があります。実用性だけでなく、もはや付加価値のないミドルウェアシステムに取り組む勇気も必要です。

デジタルへの実践的な道筋

大きな課題は、APIの実装を周囲のアプリケーションから隠すことです。これが実現できれば、レガシーシステムから新しいシステムへのモダナイゼーションが大幅に容易になります。

歴史的に、エンタープライズアプリケーション統合(EAI)スイートを使用した初期のSOA試行と、エンタープライズサービスバス(ESB)を使用した後期は、多くの場合、レガシーシステムへのコネクタの生成を許可していましたが、これらのプロトAPI は、基になるシステムの問題を直接APIに明らかにしました。APIファーストのコンセプトは、これに対する直接の反応であり、APIの設計を実装よりも上に配置します。

その後、最新のデジタルチームがAPIを設計し、必要なAPIを満たすためにマイクロサービスコードの大部分を生成する場合があります。APIを実現または実行するためにレガシーシステムへのアクセスが必要な場合でも、システム所有者は自動化ツールを使用してレガシーシステムへのアクセスを許可するコードを生成できます。場合によっては、これはマイクロサービスとして作成されることがあります。

その結果、内部APIと目的のAPIの間のマッピングが必要になる場合があります。複雑さに応じて、これが構成されたり、別のマイクロサービスとしてコード化されたりする場合があります。

多くのマイクロサービスとAPI管理プラットフォームは、新しいプログラミング言語、アプリケーション、およびユースケースに重点を置いています。これらのプラットフォームのいずれかを使用してレガシーシステムデータにアクセスするには、基盤となるデータ構造とプログラミング言語(多くの場合COBOL)を理解し、マイクロサービスと付随するAPI を手動でコーディングする必要があります。レガシーシステムへの統合の近代化の課題と重要性を認識し、いくつかのベンダーがメインフレーム接続の有効化ソリューションを提供しています。表1を参照してください。

レガシーシステムのマイクロサービスとAPIイネーブラーの成功は、自動化、標準化、テスト、およびレガシーシステムコネクタに対するベンダーのアプローチに大きく依存します。理想的には、ソリューションは基礎となるアプリケーションを自動的に分析して、開発者がWeb サービス、マイクロサービス、またはREST API に変換するために選択できる最新のコードを作成する必要があります。ビルド済みのコネクタとテンプレート(CICSやDB2など)は、開発者がこれらのWebサービス、マイクロサービス、APIを使用して新しいソリューションを構築したり、既存のソリューションを強化したりするのに役立ちます。

レガシーの緩和

レガシーは、テクノロジーの年齢や特定のタイプのテクノロジーによって定義されるのではなく、より単純で、より二元的な判断です。

このテクノロジーは、金融機関がその目標と目的を達成することを可能にしますか?

金融サービスの目標は、業界外の経験と変化によって書き換えられています。他の業界では、スピード、俊敏性、スタッフ、パートナー、顧客の人間的経験の面で、期待を根本的に高めています。目標の投稿は変化し、古いテクノロジー、古い方法、開発者によるハンドコーディングの使用—これらすべてが今では遅すぎ、レガシーにもなりすぎています。

しかし、上で見たように、金融機関は適応しており、新しい方法を採用しており、レガシー近代化への新しい道をすでに開いています。この先駆者は、新しい技術、テクノロジー、および機会を採用することにより、必要に応じて近代化するだけでなく、レガシーシステムの俊敏性と速度を再発見することもできました。

レガシーの影響を軽減および制限する実用的なアプローチにより、レガシーシステムを再び有効にすることができます。可能な場合、レガシーシステムが過負荷になり、十分に速くなり、新しい基準を達成できる場合、それらは組織がその目的を達成するのを支援する役割を果たすことができます。

マイクロサービスアーキテクチャへの参加者としてのレガシーシステム

近い将来、多くの既存の組織がアーキテクチャをターゲットにして、複数のレガシーシステムがマイクロサービスと共存して、複数のクライアントによって消費されるAPIを提供するようにします。

APIを実装の前のファサードとして活用することで、APIが主要な成果物となり、その下の実装をシフトできる世界に移動できます。表2は、マイクロサービスアプローチにより、新しいAPIやAPIの変更を従来のアプローチよりも簡単に提供できるシナリオを示しています。

進むべき道

レガシーは低速ではなく、デジタルアプローチほど高速ではありません。速度が遅くても、役に立たないというわけではありません。レガシーシステムは、多くの場合保存する価値があり、再実装にコストがかかるルール、データ、および製品を具体化します。

フィンテックなどの新興企業はデジタルビルドを全面的に支持していますが、これは多くの大規模金融機関が課すことのできない贅沢です。

このレポートでは、セレントはレガシーを活用してデジタル化し、大きくてゆっくりとした象のダンスを作る方法があることを示しました。実用的なアプローチが可能であり、マイクロサービス、API、およびDevOpsの使用から見た自動化と速度の恩恵を受けることができます。

主な研究課題3

新しいデジタル企業をゼロから構築することは、真に近代的なデジタル企業になる唯一の方法ですか?

重要な変更により、システムを高速化し、市場投入までの時間を短縮できます。

以前はレガシーと見なされていたシステムは、レガシーではなくなるように改善できます。

実用的なレガシー近代化戦略に着手する人のためのいくつかの最後のヒントを以下に示します。

  • レガシーは存続でき、自動化は交渉不可能です。
    最新のDevOpsプラクティスと高速自動化ツールを活用することが、俊敏性を実現する唯一の方法です。レガシーの方法とツールがレガシーシステムに残っていると、企業は引き続き無効になります。
  • 調整はスピードの敵です。
    統合テクノロジーの多くのレイヤーとそれらを管理するための複数のチームがあると、俊敏性が損なわれます。DevOpsは、設計、構築、展開、およびテストのアクティビティを自動化または合理化することを目指していました。これまで、すべてが別々のチームでした。同じことをする機会のためにあなたの遺産を周回するシステムを見てください。これらは自動化する必要があるか、完全に削除することを検討してください。
  • 最初にレガシーに取り組むことなく、新しい収益源を開くことができます。
    セレントは、レガシーシステムと共存しながら、新製品を提供し、古い製品を再パッケージし、新しいサービスに参入する組織の例を観察しています。

このレポートの短いバージョンは、「テクノロジーの変化が速くなっているため、ペースを維持するために迅速に移動する必要がある」と解釈されるかもしれません。ここでは、これらのテクノロジーを利用するためのいくつかのルートを提示しました。レガシーシステムの価値を失うことのないルートもあります。

もちろん、挑戦は始めることです。

このレポートは役に立ちましたか?今後の研究トピックに関するコメント、質問、提案はinfo@celent.comに送信してください。

セレントの専門知識の活用

このレポートに価値があると思われる場合は、カスタム分析と調査のためにセレントに依頼することを検討してください。このレポートの作成中に得た経験と知識により、戦略の作成、改善、または実行を効率化できます。

金融機関へのサポート

従来のモダナイゼーションに関連して私たちがサポートする典型的なプロジェクトには、次のものがあります。

ベンダーの短いリストと選択。私たちはあなたとあなたのビジネスに固有の発見を行い、あなたのユニークなニーズをよりよく理解します。次に、選択したベンダーにカスタムRFIを作成して管理し、迅速かつ正確なベンダー選択を支援します。

ビジネス慣行の評価。私たちは、特にレガシーの近代化、開発ツール、および方法論において、ビジネスプロセスの評価に時間を費やしています。市場に関する知識に基づいて、潜在的なプロセスまたはテクノロジーの制約を特定し、業界のベストプラクティスの実装に役立つ明確な洞察を提供します。

ITおよびビジネス戦略の作成。私たちはあなたの経営陣、あなたの第一線のビジネスとITスタッフ、そしてあなたの顧客からの視点を収集します。次に、現在の位置、制度的能力、およびテクノロジーを目標に対して分析します。必要に応じて、短期および長期のニーズに対応するためのテクノロジーおよびビジネス計画の再構築を支援します。

ベンダーへのサポート

私たちはあなたがあなたの製品とサービスの提供を洗練するのを助けるサービスを提供します。例は次のとおりです。

  • 製品およびサービス戦略の評価
    機能、テクノロジー、サービスの観点から、市場での地位を評価するお手伝いをします。私たちの戦略ワークショップは、適切な顧客をターゲットにし、彼らのニーズにあなたの提供物をマッピングするのに役立ちます。
  • 市場のメッセージと販促のレビュー
    潜在的なクライアントとの豊富な経験に基づいて、私たちはあなたのマーケティングおよび販売資料を評価します-あなたのウェブサイトとあらゆる担保を含みます。

レガシーシステムから最新のマイクロサービスへのデジタルジャーニーを加速

前書き

この本の答えは次のとおりです。「複雑さとレイヤーを追加しない方法で、モノリシックレガシーテクノロジーからの革新的なデジタルサービスの配信をどのように加速しますか?」つまり、ITはどのようにしてビジネスの要求に応えることができるのでしょうか。

その質問に答えるために、アプリケーションプログラミングインターフェイス(API)とマイクロサービスに関する最新のテクノロジとアプローチについて説明し、それらが他の組織でどのように機能したかについての多くの例を示します(第8章)。他の一般的なメインフレームプロジェクトより50%高速な新しい支払い処理システムを銀行または、最終的にオンライン価格見積り比較エンジンで競争できる保険会社のように、提供しました。

私たちの議論はいくぶん技術的ですが、ITとビジネスの両方の対象者のためにこれらの概念を明確にし、わかりやすく説明するために注意深く書かれています。私たちの目標は、これらのトピックに関する有意義な会話を促進し、共通の目標と理解に基づいてこれらのグループ間の架け橋を築くことです。

革新と市場投入までの時間は常に重要ですが、ミレニアル世代の市場は新たな緊急性をもたらします。彼らはデジタル的にせっかちです。彼らは伝統的な銀行プロセスを受け入れません。彼らは支店を訪問せず、フォームに記入し、数日待ってメールをチェックしません。しかし、世界の多くの地域にある多くの銀行では、これはまだオンボーディングプロセスです。モバイルデバイスを介してデジタルバンキングサービスを提供できない場合、ミレニアル世代は競合他社からアプリをダウンロードし、すぐに利用します。

テクノロジーに対する需要は、テクノロジーの機能と同じ規模で拡大します。テクノロジーが速くなると、消費者は物事を早く求めます。その結果、ほとんどの組織はより速い革新を必要とするビジネスリーダーを見つけますが、技術リーダーは依然として多くの同じ技術的課題に直面しています。

最近の「モダンマイクロサービス」は、レガシーシステム統合の基本的な側面です。これは、レイヤーの削減とバイパスについてです。これは、記録システムに迅速にアクセスし、不要な中間層を回避することについてです。それは、数十年前にサービス指向アーキテクチャー(SOA)が私たちにもたらしてくれることを期待していたことの実現です。そして、それは私たちがそれらのレガシーバックエンドシステムを最初に構築したときに想定したものです。要するに、最新のマイクロサービスは、適切な場所に適切なタイミングでいるという独自の位置にいる適切なアプローチです。

ただし、最近では、マイクロサービスに関して多くの混乱が生じているようです。よくある質問には、「APIとの違い」や「ちょっと待って、なぜこのベンダーの定義はこれとここでは違うのですか?」といった基本的なものがあります。真実は、混乱しやすいです。マイクロサービスは長年にわたって大きく変化しており、ベンダーはさまざまな方法でマイクロサービスを参照しています。それで、それらは何ですか、あなたが気にする必要がありますか、そしてもしそうなら、何ができますか?

まず、「レガシーシステム」、「レガシーモノリス」、「アプリケーションモノリス」について詳しく説明します。これらのレガシー環境の正確な定義は、ビジネス価値を提供する過去に開発されたシステムです。彼らはされた時点で利用可能な最善の技術を使用して構築されたが、多くの場合、今日の統合要件とビジネスニーズを満たしていません。これらは、緊密に結合されたビジネスロジックの複雑なサイロと見なされ、現代のDevOpsリソースがこれらのビジネスシステムに簡単にアクセスできるように、削減と解明のために多数の抽象化レイヤーが必要です。

典型的なアプリケーションのモノリス(チャプター1)とは異なり、マイクロサービスは特定のビジネス機能に焦点を当てた独立して配置された小さなサービスです。マイクロサービススタイルで記述されたプログラムは、理解、開発、テストが容易なため人気があります。個々のサービスで構成されるアプリケーションを開発することは、異なるチームが並行して作業できることを意味します。これにより、関連するマイクロサービスのコレクションを迅速かつ簡単にリリースできます。

「しかし、ちょっと待ってください。ESB やSOAがそうするはずではないのですか?」はい、そして多くの場合、彼らは成功しました。残念ながら、レガシーシステム、ESB、またはSOAを備えたほとんどのIT部門は、この増え続けるグローバル化およびデジタル化された世界で、必要に応じて俊敏性を発揮するのに苦労しています。多くの点で、マイクロサービスはSOAの利点を提供すると同時に、多くの欠点を排除します(第2章)。

マイクロサービスは、継続的な開発と提供をサポートするアジャイルプロセスとうまく連携します。これらの側面は、頻繁なデータとプログラムの更新が必要なビジネスで必要です(第3章)。それらはDevOpsに自然に適合します。

元のユースケースでは、マイクロサービスはモジュール性を新しいレベルに押し上げる取り組みでした。彼らは主に舞台裏のコンポーネントとして動作しました。今日の最新のマイクロサービスは、顧客向けの高度に統合されたサービスであり、以前は不可能だったアプリケーション機能の組み合わせを作成するために使用されます。主に、APIコントラクトの機能を利用して、さまざまなバックエンドシステムとインターフェイスします。最も重要なのは、最新のマイクロサービスが既存の複雑さのレイヤーをバイパスし、以前のアプローチ(第6 章)よりはるかに速く実装できることです。

この本は、最新のテクノロジーでレガシーデータを迅速かつ効率的に活用する方法としてマイクロサービスを検討している組織のIT、DevOps、またはビジネスリーダーを対象としています。デジタルの旅は、IT効率、サイクルの高速化、スケーラビリティの向上、競争力のある差別化につながりますように。

第一章:アプリケーションモノリスからマイクロサービスへ

組織がビジネスおよび競争上の要求を満たすのに十分な速度でイノベーションを起こすことができない場合は、アプリケーションのモノリスに対するマイクロサービスのアプローチを検討してください。「アプリケーションのモノリスとは何ですか?」と自問している場合、あなたはたぶん今それを実行しています。

通常、IT部門はアプリケーション(通常は単一のコアアプリケーションまたは複数の関連アプリケーション)を開発し、すべての要素を1つのシステムに結合します。

たとえば、機能は1つの大きなアプリケーションに混在しています。顧客情報、支払いトランザクション、レポートやセキュリティなどの追加機能を含む支払いアプリケーションがあるかもしれません。このアプローチには利点がある場合があり、一部のアプリケーションはこの方法で開発する方が簡単です。一方、モノリスは多くの非効率性とコードの使いやすさの課題を引き起こします。

スローリリース–速度の敵

このモノリシックなアプローチは過去に機能した可能性がありますが、世界は変化しました。ほとんどの組織には多数の開発チームがあり、すべてがリリース前にコードを作成、更新、およびテストしようとしています。

かつては年に1〜2回生産を開始することが当たり前でしたが、今日のペースの速い世界経済ではほとんどのビジネスに役立たなくなっています。より速いリリースサイクルが必要な場合、企業は無駄のないアジャイルアプローチに依存していますが、アプリケーションのモノリスはそのような速度の敵です。

共有コードとデータの問題

共有コードや共有データなどのソフトウェアカップリングがある場合、アプリケーションはモノリシックになる可能性があります。

共有コードは、中央のルーチンデータがアプリケーションを通じて多くのモジュールによって共有されることを意味します。たとえば、クレジットカード会社には、クレジットカードの数字の有効性をチェックする中央数字検証ルーチンがあります。すべてがカード番号が有効であることを確認する必要があるため、アプリケーションのほぼすべてのモジュールが、このルーチンを使用できます(承認プロセス、アラートシステム、顧客の声明など)。したがって、この中央ルーチンに変更を加えると、アプリケーションのすべての機能に変更が加えられます。このモジュールで問題が発生した場合、アプリケーションは失敗します。

共有データも同様の問題を引き起こします。たとえば、顧客情報はモノリシックアプリケーションの多くのコンポーネントで使用されます。コードとデータの両方を共有すると、非常に強い結合になります。1つのコードベースまたは1つのデータベースを維持する方が簡単ですが、変更を加えて管理することは困難です。

変更は予測不可能である可能性があるため、コード変更が本番環境に移行するのに十分安定していることを確認するために、企業は大規模で時間のかかるテスト(多くの場合数か月かかる)を必要とします。実際、これは非常に大きな懸念事項であり、組織によっては余波に関心があるため、バグの修正を回避する場合があります。

この相互接続された「カードの家」が、ほとんどの組織がレガシーシステムでのイノベーションを困難にしている理由です。

スケーラビリティなし

スケーラビリティを向上させるために、企業はモノリスをさまざまなサーバーイメージまたはプラットフォームで実行される主要なアプリケーションコンポーネントに分割しようとしました。ただし、多くのアプリケーションはコードやデータと非常に結合しているため、簡単に最新化することはできません。アプリケーション機能の1つのコンポーネントを1か所に配置し、別の機能を別の場所に配置することはできません。これにより、スケーラビリティが制限されます。

スケーリングの問題、俊敏性の欠如、長いリリースサイクル、革新の遅れ、複雑な変更、リスク管理は、すべてモノリスのよく知られた課題です。

マイクロサービスとは何ですか?

マイクロサービスは、10年以上前のアプリケーションアーキテクチャスタイルであり、関心と採用は急速に高まっています。

マイクロサービスのアイデアは、サービス指向アーキテクチャー(SOA)の経験から生まれました。SOAとは異なり、マイクロサービスは、範囲が狭く、非常に効率的なプロトコルを使用して通信する独立したサービスのコレクションとしてアプリケーションを構築します。本質的に要約すると、マイクロサービスは、ビジネス機能をモノリスから切り離すための正式なアーキテクチャスタイルです。アプリケーションもカプセル化する場合
マイクロサービスのプログラミングインターフェイス(API)では、モノリシックデザインの多くの落とし穴を回避できます。

たとえば、データとプロセスは、アプリケーションのモノリスで利用されている顧客情報やクレジットカードの検証プロセスなど、現在の記録システムに閉じ込められることがよくあります。マイクロサービスには、機能が意図的に制限されたAPIが含まれています。たとえば、支払いシステムはマイクロサービス内には存在しません。代わりに、支払いシステムはマイクロサービスのメッシュで構成されます。1つは顧客の詳細を取得するため、もう1つは送金するためなどです。各サービスは疎結合されているため、1つのサービスが停止した場合でもアプリケーション全体が機能し、さまざまなサーバーやクラウドにさまざまなサービスが存在したり、さまざまなコンポーネントを個別にスケーリングしたりできます。

解散は時々必要です

アプリケーションをさまざまな小さなマイクロサービスに分割すると、モジュール性が向上し、アプリケーションの理解、開発、テストが容易になります。また、小規模な自律チームがサービスを独立して開発および展開できるようにすることで、並行開発も可能になります。最後に、マイクロサービスは、継続的な配信と展開をサポートする継続的な改善を通じて個々のサービスの機能を出現させることができます。

マイクロサービスがレガシーアプリケーションの開発をスピードアップ

マイクロサービスの主な利点は、開発の速度だけではなく、開発の同時実行性です。開発者は、同じアプリケーションの異なる部分を同時に処理できます。これは、レガシーアプリケーションを扱う企業に多大なメリットをもたらします。

現代のアプリケーション開発はスピーディーなペースを要求しますが、レガシーアプリケーションでの作業は通常遅くて面倒です。マイクロサービスはその負担を取り除きます。レガシーアプリケーションをデータストアと見なし、API内にアプリケーションロジック(ビジネス関数)をカプセル化する場合、マイクロサービスを介してビジネス関数を公開することが可能です。このようにして、REST APIが理解できる形式でレガシーアプリケーションのCOBOL出力を使用することができます。

開発者は、レガシーアプリケーションに関連する機能を表す他のマイクロサービスを作成し、レガシーコードを記述または変更せずに、それらをレガシーアプリケーションに接続できます。このようにして、1つの開発チームがレガシーアプリケーションに新機能を迅速に追加する作業を行い、別のチームがレガシーコードベースの保守に取り組むことが可能です。その間、どちらのチームも、他のチームの要求に基づいてコミュニケーションしたり、作業を遅くしたりする必要はありません。マイクロサービスは、レガシーアプリケーションを含むプロジェクトの迅速な開発を可能にします。

マイクロサービスの監視

マイクロサービス時代の前は、開発者が何百ものAPIを備えた単一のモノリスを作成し、それらのAPIを単一のコンテナーで実行することが一般的でした。これの欠点は上記で説明されています。単一のコンポーネントがダウンした場合、アプリケーション全体が従います。一方、これの欠点の1つ(非常に暗い)は、アプリケーションがすべて1か所にあるため、アプリケーションの状態を比較的簡単に監視できることです。

現代のマイクロサービスの時代では、何百ものサービスで構成されるアプリケーションを作成することが可能です。これらのサービスの一部は、同じサーバーまたは同じクラウドにない場合があります。

結果のアプリケーションは非常にフォールトトレラントになりますが、そのアプローチに切り替える前にマイクロサービスを監視する方法を尋ねる価値があります。並行して実行されている何百ものマイクロサービスの分析と監視を行う機能を備えたソフトウェアベンダーまたはソリューションプロバイダーを見つけることを検討してください。

これらの利点を念頭に置いて、主要な業界アナリストが組織にマイクロサービスを詳しく検討するように提案しているのは当然のことです。Forresterは、マイクロサービスはソリューションアーキテクチャの将来において重要な役割を果たすと書いており、ソフトウェアの高速配信、運用の回復力とスケーラビリティの向上、ソリューションの保守性の向上を主な利点として強調しています。Gartnerは、マイクロサービスアーキテクチャがこれまでにない俊敏性とスケーラビリティを実現することを示しています。

第二章:マイクロサービスとサービス指向アーキテクチャー(SOA)

モノリシックアプリケーションと比較したマイクロサービスアーキテクチャの利点について説明するとき、なぜ最初からこのアプローチを採用しなかったのか疑問に思われるでしょう。結局のところ、今日の世界のエンタープライズアプリケーションの90%以上がモノリシックです。

それらが作成された時点では、モノリシックデザインは、テクノロジーとビジネスのニーズを満たすために利用できる最善のアプローチにすぎませんでした。ただし、ビジネスニーズが進化し、俊敏性を高める必要性が高まるにつれ、開発者とITチームは、これらのモノリシックアーキテクチャから解放されることを求められています。

結果として生じるアプローチは、少なくとも近年では、サービス指向アーキテクチャー(SOA)でした。ただし、SOAは多くの問題を解決しましたが、すべてを解決することはできませんでした。「マイクロサービス」という用語は、SOA用語のサブセットです。

SOA統合の課題

SOAイニシアチブの約束は、コアビジネス機能の範囲を拡大すると同時に、モノリスとともに増加する内部費用と複雑さを削減することでした。SOAは、モノリスのコア機能をシンプルオブジェクトアクセスプロトコル(SOAP)eXtensible Markup Language(XML)などのプロトコルを使用してWeb サービスに分割することで、これらの目標を達成します。

SOAPは、ユニバーサルアプリケーション通信用に構築されました。これはXMLに基づいているため、SOAPで設計されたSOAは理論的には不可知論的な統合レイヤーを作成するために使用できます。これらのプロトコルは、さまざまな独自のシステムをつなぎ合わせるのに苦労するのではなく、さまざまなオペレーティングシステムでモノリスを開いて、それらが連携できるようにします。

不可知論的な統合レイヤーにより、システム管理者はモノリスの一部をエンタープライズサービスバス(ESB)に接続して、俊敏なプラグアンドプレイSOA を実現できます。場合によっては、このアプローチは成功しました。世界には、いまだに価値を提供するいわゆる「レガシーSOA」がたくさんあります。ただし、これらの場合、SOAが提供する価値は、主に開発者を支援する舞台裏のサーバー間通信にあります。顧客への対応、そして急速に変化する顧客への対応に関しては、SOAが常に対応できるとは限りません。

問題は、ESB が宛先に到達するためのサービス統合を実現するメッセージを監視することです。この通信は、SOAベンダーが約束したほど単純ではありません。

たとえば、コアバンキングアプリケーションとのSOA統合アプローチを考えてみましょう。これには、メインフレーム上のコアアプリケーションからブランチオフィスサーバーに送信されるメッセージが含まれます。ビジネスロジックがメッセージが1 営業日のみに関連すると述べている場合、管理者は1日が経過したときにメッセージをキューに移動するか、ログに記録するか、無視するかを決定する必要があります。これは、SOAのコアバンキングアプリケーションの一般的なシナリオですが、どれだけうまく機能するのでしょうか。

この例(およびその他の例)では、ESBは、メッセージの送信先について正しい決定を行うために、営業日が経過したかどうかを知る必要があります。つまり、統合にはアルゴリズムが必要です。たとえそれが単純なアルゴリズムであっても、ESB はモノリスと外部統合の間でメッセージを送信するための普遍的なルールに単純に依存することはできません。

管理者がモノリス統合に新しいビジネスロジックを導入すると、不可知論的なサービスレイヤーであるはずのものが新しいアプリケーションレイヤーに変わり、複雑さが増します。モノリスを単に新しいデジタルサービスに統合する代わりに、企業はメインフレームと追加されたすべての新しい統合スタックを含む、より大きなモノリスになってしまいます。SOAの約束にもかかわらず、統合の問題により、メンテナンスに費やされる時間が増加し、コードとソフトウェアの複雑さが増し、モノリシックアプリケーションの継続的な成長(排除ではない)が発生します。効果的な統合の最初のルールは、「スマートエンドポイントとダムパイプ」です。ロジックとレイヤーをサービスレイヤーに組み込むと、そのルールに違反し、全体的な複雑さが増し、ポートフォリオに別のレガシーアプリケーションが追加されます。

SOAアプローチを最適化しようとすると、モノリスが大きくなるだけです。マイクロサービスアーキテクチャで新しいアプローチを取ることは、SOAの本来の約束を実現するのに役立ちます。

マイクロサービスによるSOAの改善

20年間、CIOは統合への従来のアプローチを採用することにより、モノリシックからの移行を試みてきました。これらの統合スタックはすべて、レガシーシステムに結合されてしまい、ITチームの仕事が増え、組織の俊敏性が低下します。

SOAの統合ステップは、ビジネスロジックを含めることを意図したものではありません。ビジネスロジックをこのアプローチに強制しようとすると、回避策と余分な労力がかかり、理想的ではない結果が得られるだけです。

ここで重要な要素は、悪影響を与えずにマイクロサービスを組み込む方法です。幸い、マイクロサービスアーキテクチャは、新しい原則を導入することでSOAから作成できます。

これらの原則の1つは、コンテキストマッピングです。既存のSOAを置き換える場合、チームは新しいマイクロサービスのサイズと範囲を考慮し、適切なコンテキスト境界を適用する必要があります。たとえば、デジタルサービスとの広範な統合を通常求めていたSOAは、運用を簡素化するために、より小さなドメインに分割する必要があります。

もう1つの主要な原則は、シェアードナッシングアーキテクチャの考え方です。SOAの統合が多すぎると、依存関係が広がって、技術スタックが複雑になります。マイクロサービスは、これらのサービス間の依存関係を回避します。既存のSOAからマイクロサービスへの移行を検討している場合は、依存関係のリストを確認し、スタンドアロン機能に取り組むことが重要です。

最終的には、ITスタックをマイクロサービスにシフトするようにモノリスをリファクタリングすることが目標です。適切なアプローチをとれば、SOA内でマイクロサービスとAPIの両方を最大限に活用できます。

第3章:マイクロサービスとAPI

SOAとマイクロサービスを区別する方法についてはすでに説明しましたが、APIとマイクロサービスを区別することはまったく別の問題です。企業は「マイクロサービスによって、より価値のある製品を作成できるようになるのか」という疑問を投げかけています。また、マイクロサービスアプローチを実行する前にAPIを習得する必要があるかどうかも尋ねています。おそらくそれは最良の質問ではありません。CEOとテクノロジーバイヤーはどちらも、マイクロサービスとAPIの用語を同じ意味で使用します。ただし、その違いは単なる学術的な問題ではありません。

マイクロサービスとAPIの違いは、デジタル時代への参加を計画し始めている企業にとって重要です。API を公開せずにマイクロサービスを実装でき、マイクロサービスを使用せずにAPIを作成できます。選択したオプションは、ビジネスのニーズに大きく依存します。

そこで、APIとマイクロサービスの相違点と類似点を明確にしてみましょう。マイクロサービスアーキテクチャの背後にある基本的な概念は、アプリケーションを多数の小さなサービスに分割することです。これらの各サービスには通常、独自のサービスがあります。

  • 特徴的なビジネス関連の責任
  • 実行プロセス
  • データベース
  • バージョン管理
  • API
  • UI(ユーザーインターフェイス)

マイクロサービスは明確に定義されたAPIを公開する必要があります。

マイクロサービスはソリューションを構築したい方法ですが、APIは消費者に見えるものであり、マイクロサービスアーキテクチャがなくてもAPIを公開できることに留意してください。

従うべき経験則は、サービスを小さく保ち、大きなサービスを構築するのではなく、小さなサービスをたくさん用意することです。次に、マイクロサービスはREST(Representational State Transfer)、メッセージキュー、またはその他の方法を使用して相互に通信できるため、RESTはマイクロサービスのトピックと直交(独立)していることを理解する必要があります。

APIの合理化されたアーキテクチャであるマイクロサービス

開発者の観点から見ると、マイクロサービスは、APIと作成するアプリケーションのパフォーマンス、つまり価値を向上させるアプローチです。基本的に、APIはまだ単なる契約であることに注意してください。APIは特定の入力を受け取り、特定の出力を配信します。APIがマイクロサービスアーキテクチャで構築されているかどうかに応じて、その出力は特定の方法で到着します。マイクロサービスは、APIに一連のルールを課して、APIをよりシンプルに、よりモジュール化し、より機能的にします。

1つの関数と多くの関数

標準APIは、いくつかの方法で動作するように構築されている場合があります。たとえば、顧客の電話番号などの1種類の入力を受け入れ、顧客のIDと住所を返す場合があります。同じAPIにカスタマーIDを与えると、クレジットカードと電話番号が返される場合があり、取得する他の情報に応じてさらに異なる出力が表示されます。

マイクロサービスは、APIが返すことができる情報の種類を厳密に制限します。マイクロサービスAPIは、入力に応じて1つまたは2つの情報のみを返します。別のマイクロサービスが他のものを処理します。この理由は、マイクロサービスがデータストアに関連する方法にあります。

1つのデータストアと多数のデータストア

通常のAPIが非常に多くの種類のデータを返すためには、それを実装するコンポーネントが多くの異なるデータストアに接続する必要がある場合があります。これは、APIが開発プロセスの速度を低下させ始める可能性がある場所です。これらの接続されたデータストアの1つが更新されると、返される情報が変更される場合があり、その逆の場合もあります。複数のAPIが同じデータストアに接続されている場合、変更は両方に影響します。

マイクロサービスは1種類または2種類のデータのみを返すため、それらを単一のデータストアにのみ接続することをお勧めします。このようにして、開発チームは変更を本番環境にプッシュする前に、単一のAPIをテストするだけで済みます。これにより、職域を超えた紛争が解消され、取り組みの重複が防止されます。

単純な通信と複雑なパイプ

情報が取得されると、APIはそれを使用して何かを行う必要があります。これは、情報をエンドユーザーに送信するだけの場合もありますが、多くの場合、別の自動化システムに引き渡されることを意味します。通常のアプリケーションでは、APIは、基になるアプリケーションロジックによって決定された任意のデータストアまたは他のAPIを呼び出すことができます。これは必然的に、アプリケーションをより緊密に結び付け、モジュール化を減らし、モノリシックにします。

マイクロサービスアーキテクチャでは、特定のAPIに関連付けられたアプリケーションロジックは、他のAPIのみを呼び出すことができます。この簡略化された通信により、マイクロサービスが変更または削除されたときにアプリケーションが壊れることを防ぎます。この追加された柔軟性により、開発プロセスがさらに簡素化および合理化されます。

通常のAPI実装はそれ自体でサポートされます。任意のコマンドを受け入れ、任意のデータベースに接続し、他のアプリケーションまたはサービスを呼び出すことができます。ただし、このように見える柔軟性により、実際にはアプリケーションがモノリシックになり、柔軟性が低下し、操作が困難になる可能性があります。対照的に、マイクロサービスは、一連のルールとコンポーネントでAPIをカプセル化し、最終的にアプリケーションをモノリシック制約から解放します。

要約すると、企業は単にAPI を持っているだけではAPIを特に革新的または先進的な組織にしないことに気づき始めています。APIの作成と実装に4か月かかる場合、開発に固有の速度はありません。マイクロサービスは会話を変えます。マイクロサービスフレームワークのシンプルなAPIは、実績のあるテクノロジーを使用して1日で作成できます。

要件に応じて、現在マイクロサービスを採用している企業は、巨大な先発者を抱えています。
従来のAPIに依存する企業よりも優れています。マイクロサービスの採用者は、より本質的な価値を持つアプリケーションを構築し、競合他社よりも速く機能を追加できるようになります。つまり、マイクロサービスをまだ検討していない場合は、すぐに変更できるように準備しました。

第四章:解剖学Microservicesアーキテクチャ

マイクロサービスは、API自体、アプリケーションロジックユニット、データストアの3つの部分を組み込んだ特定の方法で構築されます。マイクロサービスアーキテクチャでは、このブループリント内でいくつかのバリエーションを考慮しながら、次の原則を遵守します。

マイクロサービスの構造:API

すべてのマイクロサービスにはAPIが含まれていますが、そのAPIは特定の方法で作成する必要があります。マイクロサービスアーキテクチャは非常に限定的で特定のタスクを優先するため、組み込みAPIは通常、パブリックコントラクトを表す1つの役割のみを持ちます。たとえば、エージェントデスクトップの契約には、顧客IDが指定されたときに顧客の名前、電話番号、住所を提供するAPIが含まれる場合があります。

一部のAPIの役割は拡張されている可能性があります。たとえば、顧客が自分のIDを忘れたため、エージェントは代わりに顧客の電話番号を提供することでIDを取得できます。ただし、これをはるかに超えると、通常は悪い習慣になります。

さらに、API自体は、新しい関数が与えられたときに過去の関数を保持する必要があります。つまり、開発チームはAPIの機能を改善することを決定するかもしれませんが、それらを置き換えることはできません。そうしないと、ワークフローが壊れたり、カスケードエラーが発生する可能性があります。

マイクロサービスの構造:アプリケーションロジック

マイクロサービスでは、アプリケーションまたはビジネスロジックコンポーネントにより、APIにある程度のインテリジェンスが追加されます。たとえば、マイクロサービス上に構築されたeコマースプラットフォームを想像してみてください。顧客は「注文する」をクリックします。これは、注文を作成する顧客が有効なアカウント、請求情報、および住所を持っていることを確認する1つのマイクロサービスに信号を送ります。これが完了すると、マイクロサービスは一定量の情報を渡す必要があります。

  • アプリケーションは顧客を検証できましたか?
  • いいえの場合、なぜですか?
  • はいの場合、次のマイクロサービスを順番に呼び出して注文を作成します。

マイクロサービスの構造:データストア

マイクロサービスアーキテクチャのベストプラクティスでは、マイクロサービスがデータを共有することはありません。マイクロサービスはそのデータストアをカプセル化し、他のAPIがそのデータストアを直接呼び出すことはありません。これにより、開発者は他のマイクロサービスに影響を与えることなくデータストアに変更を加えることができ、開発とテストのプロセスが大幅にスピードアップします。

マイクロサービスでのデータストレージのもう1つの基本的なルールは、マイクロサービス自体の使用例に最も適したデータベースを使用することです。これにより、たとえば、開発者は同じアプリケーション内でSQLデータベースとNoSQLデータベースの両方を使用でき、ACID (原子性、一貫性、分離、持続性)トランザクションやリレーショナルデータベースの他の肯定的な側面を放棄することなく、NoSQLの利点を維持できます。これはAPI側でミラーリングされ、アプリケーション言語とAPIを機能と効率の適切なブレンドを追加する言語で作成できるようにするポリグロットプログラミングが可能です。

マイクロサービスはミニアプリケーションのようなもの

要約すると、マイクロサービスは、eコマースなどのWebアプリケーションで一般的に使用される3層クライアント/サーバーアーキテクチャ(プレゼンテーションレイヤー、ビジネスレイヤー、データレイヤー)の側面を組み込んだものと考えることができます。

  • プレゼンテーション層-3層アーキテクチャーで通信をフレーム化するために使用されるメカニズムです。マイクロサービスパラダイムにおけるAPIは、通信のメカニズムを定義するコントラクトです。
  • ビジネス層-3層アーキテクチャーとマイクロサービスアーキテクチャー内で同じように機能します。それは一緒に仕事や活動の開始と終了を調整し、他のサービスとの通信を管理しています。
  • データレイヤー- 情報(データ)のパッケージ化とビジネスレイヤーのロジックへの公開を管理し、ビジネスレイヤーのロジックはAPI(プレゼンテーションコントラクト)に渡されます。

3層アプリケーションには水平分離のレイヤーが含まれていますが、マイクロサービスは垂直分割線を追加し、プレゼンテーションロジックレイヤーを通じてのみ他のマイクロサービスに公開します。これは、マイクロサービスとモノリシックアプリケーションの主な解剖学的違いです。残りのアプリケーションから自分自身を閉じることにより、マイクロサービスを1つのチームが全期間にわたって管理できるようになり、ビジネスロジックの置き忘れ、重複した作業、その他のマイナスの可能性を排除できます。

第5章:マイクロサービスのベストプラクティス

マイクロサービスのアプローチは進化して、数年前よりもはるかに単純になりました。最新のマイクロサービスは、接続性とメッセージパッシングに専念するモジュールの代わりに、これまでよりも簡単に作成でき、スタンドアロンで使用したり、APIを使用してアプリケーションに組み合わせたりできるデータアプリケーションです。彼らは重要なデータとプロセスを、アクセスする記録システムを破壊することなく新しい方法で利用できるようにします。

最新のマイクロサービスに投資するときは、簡単なスケーリング、迅速なリリースサイクル、単純な変更、俊敏性の向上、イノベーションの迅速化、リスクの低減を期待する必要があります。これらの動機は、マイクロサービスの次の7つのルールの背後にあります。

  1. 可能な場合はレイヤーをバイパスする
  2. パブリックAPIのみにアクセスする
  3. 仕事に適したツールを使用する
  4. すべてのレベルを保護する
  5. 良い市民でありながら、優れた警察を持っている
  6. テクノロジーだけではない
  7. すべてを自動化する

ルール1:可能な場合はレイヤーをバイパスする

多くの読者は、統合マイクロサービスを作成するのが複雑であると認識したり、直接体験したりすることがあります。これまでのマイクロサービスの作成では、既存のアーキテクチャの複雑なレイヤーをナビゲートする必要がありましたが、最新のマイクロサービスはこれらのアーキテクチャをバイパスして、メインフレーム、ミッドレンジシステム、データベースなどのモノリシックレガシーシステムに直接接続します。

一部のソフトウェアは、システムに接続する最適な方法を決定できるように、レガシーシステムのロジックを使用します。そして、実行時に、その情報が自動的にレガシーシステムと接続するために事前に構築されたコネクタを使用し、できるだけ多くの層としてバイパス(ルールナンバー3を参照- ポリグロットバックエンド)。

マイクロサービスは、COBOLやRPGなどの特別なプログラミングスキルや基盤となるシステムへの侵襲的な変更を行うことなく、非常に迅速かつ複雑に作成することができます。

マイクロサービスの価値は、最初に作成しなければ達成できないため、この点を過大評価することはできません。私たちの経験では、組織がレガシーモノリスにマイクロサービスまたはAPIを採用する場合の最大のハードルは、作成の時間と労力です。

ルール2:パブリックAPIのみにアクセスする

パブリックAPIを使用して新しいビジネスアプリケーションを提供することで、ソフトウェアの作成方法と市場への提供方法が根本的に変化します。RESTまたはSOAPで構築されたパブリックAPIは、そのアクセスを管理するコントラクトを持っているため、ルールは、マイクロサービスのコントラクトとのみ対話する必要があるということです。マイクロサービスを結合または結合するには、モジュール式の側面を維持するために特定の方法で使用する必要があるため、これは重要です。サービスコントラクトを使用すると、サービスのデータベースまたはメッセージキューを直接読み取ることによって発生する可能性がある問題を回避できます。コントラクトをバイパスすると、サービスの物理属性に依存するため、マイクロサービスのコードが変更されると問題が発生する可能性があります。

マイクロサービスはどのように変化し、進化しますか?マイクロサービスを変更して成長させるプロセスがあります。これはコントラクトのバージョンを通じて処理されるため、組織では、あるバージョンのコントラクトを使用するアプリケーションをいくつか持つことができますが、他のアプリケーションは別のコントラクトを使用します。

たとえば、たとえば、マイクロサービスはアプリケーションを機能コンポーネントに分割し、他のマイクロサービスと組み合わせて外部APIを作成できます。このような「機能ネットワーク」を作成することにより、マイクロサービスのこれらの組み合わせはSDKを利用して、メインフレームのようなレガシーシステムにアクセスします。これらのマイクロサービスは、新しいビジネスアプリケーションを作成するために使用されます。彼らが使用する新しいコントラクトはメインフレーム上ではなく、メインフレームにアクセスするマイクロサービス自体の内部にあります。

関数ネットワークがあると、新しいビジネスロジックの変更、拡張、追加が簡単になります。最新のマイクロサービスは、レガシーシステムの上に保護と抽象化のレイヤーを作成します。同時に、レガシーアプリケーションを変更することなく、ユーザーに多くの柔軟性と俊敏性を提供します。

ルール3:ジョブに適したツールを使用する

多くの組織が、サポートされている製品とテクノロジーの統合されたコレクションを開発することにより、仕事に最適なツールのアプローチを採用し始めています。これには、特定のニーズに対処するために使用する必要のある1つのメインツールがある「使用する必要がある」リストが含まれる場合があります。

承認された代替ソリューションのリストである「利用可能なリスト」もあります。プログラマーは、SQLデータベース、シーケンシャルファイルシステム、またはインメモリデータシステムなど、ニーズに最適なツールまたは製品を選択できます。これはポリグロット持続性として知られています(図4)。

プログラミング言語で正しい選択を行うことは、正しいデータ管理オプションを選択することと同じくらい重要です。タスクを完了するために最適な言語を選択することは、ポリグロットプログラミングと呼ばれます。組織が特定のプログラミング言語にコミットしたからといって、プログラマーが契約を使用してマイクロサービスを適切に呼び出す限り、プログラマーがその言語ですべての手順を実行しなければならないという意味ではありません。たとえば、一部のアプリケーションでは、Javaが会社の標準であっても、Cまたはjavascriptが最良の選択である場合があります。

ポリグロットバックエンドは、ポリグロットアーキテクチャの3つの要素を完成させます。これにより、マイクロサービスは、開発中のアプリケーションのニーズに応じて、マイクロサービス内の1つ以上のバックエンドに柔軟にアクセスできます(ルール番号1で説明)。ポリグロットバックエンドは統合レイヤーの形をとっていませんが、マイクロサービスを洗浄しない純粋なマイクロサービスの実装です。つまり、実際にマイクロサービスの特性に適合しない製品をマイクロサービスとして販売する習慣です。

ルール4:すべてのレベルを保護する

マイクロサービスは別個の実行可能なユニットであるため、モノリシックアプリケーションのすべてのコンポーネントで共有されるセキュリティフレームワークの利点の一部を享受しません。多くの場合、共有セキュリティメカニズムがないため、開発者は、ファイアウォールの役割を果たしながら多くの機能を提供するAPIゲートウェイ1の背後でマイクロサービスを実行することにより、この不足を補います。所謂ゼロトラストセキュリティネットワークはこれらの考えをリプレイスするものです。

より具体的にゼロトラストネットワークの構成が気になる方は、
他のホワイトペーパーもご覧ください。今だけ無料で公開しています。

APIゲートウェイが実装されている場合、多くの組織は、APIゲートウェイの背後にあるすべてが安全であると想定しています。サイバー脅威がゲートウェイに侵入すると、それを攻撃する追加のセキュリティメカニズムはありません。マイクロサービスには、1つのセキュリティ層に限定されない詳細な防御が必要です。マイクロサービス間の通信は、暗号化されたSSLを使用して保護する必要があります。2oAuth3は、ユーザーIDとアクセス制御に使用する必要があります。JSON.4を適切に処理することが重要です。このプロトコルはXMLに取って代わるものですが、弱いデータ型指定機能を備えています。JSONにはデータ検証に役立つ機能が制限されています。つまり、JSONには脆弱性があり、マイクロサービスのロジックで対処する必要があります。

もう1つの安全なオールレベル戦略は、通常は安全ではないため、マイクロサービスをパブリックネットワーク上で実行することを決して許可しないことです。さらに、プログラマーは、すべての重要なイベントのログ記録、自動監視の埋め込み、必要に応じたアラートの生成など、特定のガイドラインを採用する必要があります。プログラマーは、セキュリティ、開発、およびシステム管理ソリューションの観点からホイールを再発明する必要はありません。代わりに、信頼できるツールとフレームワークを使い慣れているはずです。例は次のとおりです。

  • Apache Log4j-Javaで記述された高速で信頼性が高く柔軟なロギングフレームワーク
  • Auth-REST API、ウェブ、モバイル、デスクトップアプリケーションの安全な認証を可能にするオープンプロトコル
  • EhCache –広く使用されているオープンソースのJava分散キャッシュエンジン
  • Angular-Webアプリケーション用のオープンソース開発プラットフォーム
  • Freemarker-オープンソースのJavaベースのテンプレートエンジン。テンプレートは構造化された形式で、Freemarkerによって作成され、エンティティーを生成するときにプログラマーがデータを入力します。

ファイアウォール、SSL、JSON、パブリックネットワークの使用、ロギング、モニタリング、アラートなど、他のセキュリティ上の考慮事項に加えて、一部のベンダーには、インサービスセキュリティと呼ばれる機能があります。これにより、LDAPおよびoAuth認証に基づいて構築されることにより、アプリケーション内のすべてのマイクロサービスに別の安全なレイヤーが追加されます。その層は、セキュリティレベルに従って特定のAPIフィールドへのアクセスを制限することにより、データ構造のセキュリティを提供します。セキュリティレベルに応じてデータ値へのアクセスを制限することにより、データコンテンツのセキュリティを追加します。

ルール5:善良な市民でありながら、優れた警察を持つ

マイクロサービスエコシステムの良き市民であることは、別のマイクロサービスのコントラクトを使用する新しいマイクロサービスを作成するときに、そのマイクロサービスの現在の使用状況に注意する必要があることを意味します。そのマイクロサービスをサポートするチームにアプローチして、計画とニーズを伝える必要があります。広範囲に使用する場合は、SLA5に影響を与える可能性があり、プールデータサイズの増加やキャッシュの有効化6などの手順を実行する必要があります。

あなたは善良な市民である必要がありますが、優れたポリシングツールも必要です。SLAを測定し、ログとトレースを収集し、手に負えないワークロードを調整する必要があります。また、内部の指標(「関与したサービスとその応答時間はどれくらいか」)とユーザーエクスペリエンスの指標(「クリックからデータまでの時間」)の両方を収集することも重要です。

マイクロサービスがメインフレームアプリケーションおよびデータとインターフェイスする場合、モノリスを保護するためのアクションを実行する必要があります。各マイクロサービスはログを保持し、トレース機能を提供するだけでなく、最も頻繁に使用されるデータをメモリに保持することで検索のパフォーマンスを向上させるキャッシュメカニズムもあります。ホストに送信される要求が多すぎる場合、一部のソフトウェアはモノリスへのアクセスを明確に抑制できます。スロットル機能により、単一のクライアントが時間単位ごとにアプリケーションAPIに送信できるリクエストの数を制限できます。

ルール6:テクノロジーだけではない

マイクロサービスを開発する前に、チームの編成を検討してください。マイクロサービスは、各チームがいくつもの異なるスキルを持ち、これらのチームが可能な限り自給自足であるクロスファンクショナルチーム8として組織化すると繁栄します。Martin Fowler氏は、「サイロ化された機能チームはサイロ化されたアプリケーションアーキテクチャにつながる」と述べています。クロスファンクショナルチームは、作成および管理している機能を中心に編成されているため、マイクロサービスAPIとの連携が良好です。

マイクロサービスAPIを開発する前に、チームのスキルセットを検討してください。Javaはチームで重要なスキルですが、他の言語やミドルウェアのスキルも必要です。たとえば、一部のツールはJavaでマイクロサービスを自動的に生成し、JavaスキルはマイクロサービスAPIの標準出力を変更する場合にのみ必要です。驚くべきことに、レガシーアプリケーションとデータアクセスは自動的に処理されるため、マイクロサービス実装チームにレガシースキルを含める必要はありません。つまり、部門を超えたチームの数はレガシースキルを持つ人々の数に限定されず、労働力プールははるかに大きくなります。

開発へのアジャイルアプローチ9は、マイクロサービスに自然に適合します。部門横断的なチームは、マイクロサービスの結果であるパブリックAPIを迅速に作成できます。DevOps10は、開発者とサポート技術者の両方が同じ部門横断的なチームに属しているため、マイクロサービスにも適しています。また、1つのチームに所属することで、一般的なツールや手順の使用を妨げる組織の障壁が取り払われます。

ルール7:すべてを自動化する

自動化は、ITの品質を向上させ、リスクを低減するための実証済みの方法です。Gartner11は、自動化は次のITフロンティアであると書いています。マイクロサービスの開発中に、必要なテストを手動で繰り返すことはコストと時間がかかるため、テストは自動化の良い候補です。自動化されたソフトウェアテストは、繰り返しテストを実行する時間を数日から数時間に短縮し、より包括的で一貫した結果を提供できます。

自動化は、はるかに堅牢なIT環境と、リスクの低い方法でソフトウェアを変更する大きな機会につながります。一部のマイクロサービスベンダーは、他のベンダーよりも本質的に自動化されています。たとえば、一部のベンダーは、デプロイ可能なユニット(実際のマイクロサービス自体)を標準のJavaエンティティにすることを可能にしています。それらについて独自のものは何もありません。それらは、経験豊富なJavaプログラマーが作成するものとまったく同じです。

さらに、これらのタイプのマイクロサービスでは、JenkinsやMavenなどのソリューションを使用できます。Jenkins を使用すると、継続的インテグレーションと継続的デリバリーステップを利用して、ソフトウェア開発プロセスの多くの部分を自動化できます。Mavenを使用すると、プロジェクトのビルド、レポート、およびドキュメントを管理できます。JenkinsとMavenは単なる例です。マイクロサービスベンダーまたはツールを選択するときは、独自の展開、テスト、またはバージョン管理ソリューションが不要なソリューションを探します。ベストプラクティスのベストソースソリューションを使用することをお勧めします。

テクノロジーがテストされるため、標準のテクノロジースタックを使用することが重要です。セキュリティと高いパフォーマンスを確保するために適切に設定する方法については、専門知識とドキュメントが豊富に用意されています。特定の開発状況では、より高速またはより堅牢なデータベースが必要になる場合があります。または、特定の種類のハードウェア、オペレーティングシステム、およびサーバーソフトウェアについて、契約上の要件または規制上の要件がある場合があります。これらのケースはまれであり、ほとんどのマイクロサービスは標準のテクノロジースタックで適切に機能します。

この章のベストプラクティスは常識的な尺度ですが、IT組織の文化的および技術的な変更が必要なものもあります。「パブリックAPIにのみアクセス」および「すべてのレベルを保護」は、データリソースを保護するための慎重な対策に重点を置いています。「仕事に適したツールを使用する」と「これはテクノロジーだけではない」と考えられる場合、組織の変更が影響を与える必要があります。「良き市民でありながら、優れた警察を備えている」と「すべてを自動化する」ことは、ITの手順に従うことで実装が簡単な組織とテクノロジーの組み合わせに焦点を当てています。

第6章:マイクロサービスのコスト/メリット

マイクロサービスがレガシーアプリケーションをデジタルジャーニーのスピードバンプではなく、資産としていかに有効に活用できるかに焦点を当てています。そのため、マイクロサービスはIT組織とビジネス組織の両方にメリットをもたらします。

マイクロサービス戦略の利点にもかかわらず、マイクロサービスアーキテクチャの採用は、比較的新しいソフトウェア分野の採用と類似しているため、それを追求することについて冷静に考えることが重要です。マイクロサービスを構築してデプロイする場合は、適切な環境とスタッフが必要です。これは決して広範なリストや驚くべきリストではありませんが、ここでは、マイクロサービスを検討するときに考慮すべきいくつかのことを、新しいテクノロジーや方法論と同様に説明します。

マイクロサービスアーキテクチャの開発

マイクロサービスプロジェクトのコストと価値の決定は、他のプロジェクトと大きく異なりませんが、考慮すべき固有の要素があります。たとえば、ここでは、発生する可能性のある「開始」費用のほんの一部を示します。

  1. 人件費:すべての開発者がマイクロサービスアーキテクチャに精通しているわけではありません。
  2. 組織経費:マイクロサービスアーキテクチャは、小規模で機能横断的なチームによって管理された場合に最高のパフォーマンスを発揮します。
  3. ツール:コンテナ化およびその他のサポート技術。

経験則–どこから始めているかによっては、「はじめに」のコストが予算の問題になる可能性がありますが、下流のメリットは大きくなります。マイクロサービスアーキテクチャを採用すると、大量のビジネスおよび技術的価値を返すことにより、これらのコストを迅速に賄うことができます。

保守性と継続的な運用コスト

価値生成の最初の部分は、メンテナンスの利点という形で提供されます。グリーンフィールド開発とは対照的に、アプリケーションのモノリスを実行することから始めると仮定しましょう。これらのアプリケーションは連動する依存関係から構築されているため、メンテナンスには時間がかかります。

たとえば、モノリシックアプリケーションで障害が発生したとします。ログインマネージャーが失敗します。アプリケーションの他のすべての部分はログインマネージャーでハングアップするため、ダウンすると、すべてダウンします。このように動作するアプリケーションでますます多くの顧客をサポートすることは困難であり、フェイルオーバーサービスやインスタンス化などの回避策はありますが、高価になる傾向があります。

アプリケーションのモノリスのテスト、更新、保守にかかる時間は、保守が従来のIT予算の大部分を占めることを意味します。ガートナーのヘルスケアIT予算のサンプルでは、予算支出の70%1が単にビジネスを運営しており、2017年には73%に増加しています。これにより、イノベーションのための余力はほとんどありません。

経験則–アプリケーションの依存関係が少なく、シンプルなAPIを備えたマイクロサービスアーキテクチャは、アプリケーションのメンテナンスに費やす時間と費用を即座に削減します。アプリケーション保守費用の節約は、数年以内に「開始」コストをカバーするのに十分以上であることが証明されています。

品質とスピードの融合

モノリシックアプリケーションに固有の依存関係(スピードバンプ)は、イノベーションを阻害します。アプリケーションのモノリスは、スピードを重視する新しい開発手法(AgileやDevOpsなど)でうまく機能しない傾向があります。アプリケーションの一部に加えられた更新は他の部分に反映されるため、すべての更新は徹底的にテストする必要があります。

この問題を軽減するように設計された自動テストツールがありますが、モノリスの障害を軽減するように設計されたソリューションと同様に、高価で拡張が困難です。

一方、マイクロサービスを使用すると、開発者は品質を犠牲にすることなく開発の速度を上げることができます。これにより、競争上の優位性が生まれます。マイクロサービス戦略をまだ採用していない人よりも速くアプリケーションを洗練させることができます。外部の顧客やベンダーはこれらのアプリケーションへの忠誠を築き、内部のエンドユーザーはより生産的になります。

品質

これがどのように機能するかです。DevOps、アジャイル、およびその他の最新の開発プラクティスは、自動テストに大きく依存しています。アイデアは、開発者またはQA担当者が数回クリックするだけで複数のテスト環境をセットアップできるようにし、自動テストプログラム(Jenkinsなど)がほとんどの作業を処理できるようにすることです。正しく行われると、マイクロサービスはレガシーアプリケーションに変更を加える必要がなくなり、それにより、モノリシックアプリケーションテストの時間とコストがかかる練習の必要性が制限されます。

マイクロサービスは、よりクリーンなテストプロセスを実現します。シンプルに構築されているため、コードを確認するのが簡単です。その結果、単体テストの実行も簡単になります。当然のことながら、マイクロサービスは小さくシンプルであり、すばやく簡単に記述できるため、テストも同様に簡単です。

速度

速度の価値は組織ごとに異なりますが、1年あたりの配信サービスが90%増加するメリットや、5週間ごとに20の新しいサービスを押し出すことができるメリットを容易に理解できます。

経験則:開発のスピード+開発の品質=競争上の優位性。例えば:

  • 保険会社がマイクロサービスを利用して大規模な保険見積もり比較エンジンで競争するとき、あなたは何百万もの買い物客が使用する急成長しているデジタルチャネルの一部です。
  • マイクロサービスの結果としてモバイル請求とモバイル預金を提供できる銀行は、生涯にわたって価値を提供し、預金に数百万を追加できる若い世代の新しい銀行顧客を獲得できるようになりました。

歩いてから走る

マイクロサービスアーキテクチャがすぐに価値をもたらすことができる差し迫った、説得力のあるビジネスユースケースであなたと協力するパートナーを見つけてください。「何が可能か」を想像する能力を与える、リスクの低い概念実証の成功基準を定義し、データポイントは、デジタルジャーニーを開始するために必要な可能性とコスト/価値のベンチマークを自信を持って評価するために必要です。

第7章:マイクロサービスを使い始めるためのヒント

考慮すべき主なことは、「銀の弾丸」のシナリオに飛び込むことを避けることです-すべてに対して1つの答えやアプローチはありません。マイクロサービス戦略には、無数のオプションと代替案があります。最初に、解決しようとしているビジネス上の問題、市場の動向、クライアントがどのようにやり取りしたいか、運用上の問題、サポート上の問題への影響などを評価する必要があります。

このウォークスルーに基づいて、デジタルトランスフォーメーションへの最善のアプローチが進化的または革新的であることに気付く場合があります。どちらのトラックでも、社内リソース/開発、オープンソーステクノロジー、サービスプロバイダー、およびテクノロジーベンダーの組み合わせが必要になる可能性が高いです。

マイクロサービスプロジェクト、または実際にソフトウェア開発プロジェクトを開始することは、最初にそれをどのように達成すべきかについての詳細な計画を立てずに行うことはお勧めできません。ただし、マイクロサービスは、他の形式のソフトウェアアーキテクチャよりも開発基準からの大きな逸脱を表す場合があります。これは、マイクロサービスの開発は、新しいプログラミングフレームワークを学ぶことだけを意味するのではなく、組織内の開発の機能単位を根本的に再編成することを意味します。

2つの主要なマイクロサービスの焦点領域について説明しましょう。1つ目は基本的なものであり、組織内のマイクロサービスの基盤を構築する方法です。2つ目は手順です。これは、特定のマイクロサービスをゼロから作成、構築、実装するために企業が見つけた最良の方法です。これらの青写真が手元にあれば、企業はマイクロサービスアプローチを図面から現実のものにする可能性が非常に高くなります。

始める前に:Microservicesの前提条件

調査によると、定着したレガシーアーキテクチャを最新のデジタルインフラストラクチャに置き換えようとする企業の多くは、通常、長期間にわたって多額の費用を費やした後で失敗することがわかっています。一方、マイクロサービスは正反対であり、迅速、安価、そして成功するはずです。ただし、成功を保証するには、企業はいくつかの前提条件を満たす必要があります。

最初の前提条件:技術の有効化

組織にとっての重要な課題の1つは、1980年代に構築されたレガシーソフトウェアインフラストラクチャからの出力を、最新の携帯電話モデルが理解できる入力に変換することです。マイクロサービスはこのプロセスを促進するのに役立ちますが、このパズルの鍵の1つは、レガシーバックエンドをモバイルおよびブラウザーベースのユーザーがより利用しやすくすると、すでに機密性の高いインフラストラクチャのワークロードが増加することを理解することです。

別の質問は、将来に関係しています。マイクロサービス–およびそれらをサポートするテクノロジー–は静的ではありません。マイクロサービスインフラストラクチャを作成することは、ミッションクリープを回避しながら、情報技術の継続的な傾向を予測することを意味します。言い換えれば、開発者はアップグレード可能なマイクロサービスアーキテクチャを作成する必要がありますが、複雑なミドルウェアスタックの必然性を回避するものでもあります。

2番目の前提条件:標準ベースのアプローチ

すべてのマイクロサービスが共通の標準セットで設計されるべきであるという考えは、すべてのマイクロサービスが将来を見据えるべきであるという考えと密接に関連しています。多くのサードパーティ開発者(マイクロサービスアーキテクチャの作成に一般的に採用されています)はこのアプローチを重視せず、その結果、レガシーインフラストラクチャのプログラミングの現実を知らないフレームワークを作成しています。マイクロサービスに標準が適用されていない場合、それらを追加のアプリケーションで再利用および維持することは、不可能ではないにしても困難になります。

3番目の前提条件:速度を考慮したギアリング

開発チームがマイクロサービスをすばやく作成するのは簡単ですが、簡単であることは、マイクロサービス自体ではなく、主にチームに依存しています。マイクロサービスを迅速に作成できるチームは、適切なテクノロジーと適切な一連の標準を備えている必要がありますが、それだけではありません。

コンウェイの法則によると、組織は組織の構造を支援するソフトウェアを作成します。マイクロサービスは個別であり、独立してデプロイできるため、マイクロサービスを作成する組織は、トップダウンからゆるい組織で独立したプロジェクトに取り組むことができる小さなチームで構成される必要があります。したがって、マイクロサービスアーキテクチャは、アジャイルまたはDevOpsフレームワークを補完します。

アジャイル、DevOps、マイクロサービス

2016年の時点で、約66%の企業がすでにアジャイルを使用していますが、アジャイルの使用は、業界ごとの包括的なものにはほど遠いものです。レガシーハードウェアとソフトウェアに定期的に取り組む組織は、アジャイルの迅速なペースをレガシーシステムの開発の遅い現実に適応させることが困難になることがよくあります。

  • JPモルガンチェース(世界で10番目に大きい銀行)は、2015年にアジャイルの採用を開始したばかりです。
  • 多くの医療組織は、依然としてアジャイルをウォーターフォールに相当すると見なしています。
  • 大規模な政府機関は、レガシーハードウェアにアジャイル方式を採用するという概念に取り組んでいます。

理論上アジャイルを使用している組織の多くは、実際にはアジャイルを実際には使用していない可能性があります。アジャイルは、組織が高い変化率を達成する能力として簡単に定義されます。組織が4か月に1回だけリリースを展開する場合、それらは実際にはアジャイルではありません。

マイクロサービスを追加すると、組織がアジャイルを完全に実現するのに役立ちます。マイクロサービスは小さく柔軟に設計されているため、アジャイルチームがマイクロサービスプロジェクトに取り掛かると、全体的な速度が向上します。これは、開発組織を毎月のリリースケイデンスから毎週のリリースケイデンスに移すのに十分です。言い換えると、組織を、名前だけではなく、実際にアジャイルを実現するものに変換します。

組織がレガシーベースのアプリケーションでスケールと速度を達成できるようにするマイクロサービス/ APIソフトウェアベンダーは、DevOpsイネーブラーと見なすことができます。

前提条件が満たされた後のマイクロサービスの実現

組織がはるかに速い開発サイクルをサポートできる技術的および構造的な前提条件を満たしたら、本格的なマイクロサービスの作成を開始します。これは3フェーズのプロセスです。マイクロサービスの必要性を発見し、マイクロサービスを作成して、本番環境に導入します。

ステージ1:発見

この場合の「発見」とは、ドキュメントを意味します。開発者がマイクロサービスの基礎となる詳細なロジックをテキストドキュメントで明確にし、その目的、動作方法、抜け穴がないかどうかを説明するまで、作業は始まりません。

一例として、患者と医師が検査結果を調べたいときに病院の記録をクエリするマイクロサービスを想像してみてください。発見文書には以下が含まれます。

  • ユーザー:この場合、自分の記録を調べたい患者と同じことをしたい医師。
  • 説明:このアプリケーションを使用すると、ユーザーは病院の記録を検索できます。そのためには、Webポータル、レコードライブラリ、メインフレームなど、多くのシステムを結び付ける必要があります。
  • シーケンス:ユーザーはWebポータル経由で認証し、レコードページに移動してレコードを選択します。これにより、マイクロサービスがトリガーされ、顧客に応答が返されます。
  • 前提条件:ユーザーは、患者または医師として認証され、レコードを表示する権限があり、レコードを表示する必要があります。
  • 事後条件:アプリケーションは、PDFとしてダウンロードされる医療記録を提供します。マイクロサービスがそれを実行できない場合、ユーザーの教育用のエラーコードを提供します。

発見ドキュメントは、マイクロサービス自体の要です。アプリケーションの多くのエラー、不整合、および欠点は、コードとは関係なく、紙にそれらの原因を突き止めることができます。上記の箇条書きのポイントは、実際の発見ドキュメントの最も簡単なスケッチを表しています。実際のバージョンでは、抜け穴がないか徹底的にチェックする必要があります。

ステージ2:ビルド

マイクロサービス開発の「構築」フェーズには、コードの記述とテストの両方が含まれます。その性質上、マイクロサービスは迅速に作成され、迅速にテストされることを意味します。多くの場合、自動テストツールを使用します。マイクロサービスのテストは、一般的にそれを書くよりも複雑です。マイクロサービスを作成したら、少なくとも3つのフェーズのテストが必要です。

  1. 開発とビルド時のテスト
    開発テストは、マイクロサービスの作成中および作成直後に開発者によって実行されます。マイクロサービスの場合、これらは通常、単体テストの形をとります。一方、ビルドタイムテストは、マイクロサービスのさまざまな部分を対象としたさまざまなテストツールを使用して、静的分析の形をとります。
  2. QAテスト
    マイクロサービスのQAテストには、いくつかの領域でのポジティブ/ネガティブテストが含まれます。たとえば、機能があります。アプリケーションは意図したとおりに機能しますか?セキュリティと承認もあります。マイクロサービスを使用できるのは誰ですか。また、権限のないユーザーにどのように反応しますか?最後に、アプリケーションのビジネスロジックに対してテストが実行され、さまざまなユースケースシナリオでアプリケーションのパフォーマンスを測定します。
  3. PTEテスト
    パブリックテスト環境(PTE)テストは、運用環境でのマイクロサービスのパフォーマンスをシミュレートします。重要な質問には、通常のトラフィックでアプリケーションがどのように実行されるか、異常なトラフィック負荷でアプリケーションが適切に実行できるかどうか、およびそのパフォーマンスがSLAにどのように変換されるかが含まれます。

ステージ3:実現する

発見と構築が完了すると、あとはマイクロサービスを運用に移すだけです。これは非常に簡単です。おそらく、discover-build-realizeループの最も簡単なステップです。

マイクロサービスは、その性質上、簡単にデプロイできるように設計されています。

マイクロサービスはミニアプリケーションであるため、チーム間の大規模なコラボレーションなしで設計および運用に使用できます。新しいマイクロサービスを本番環境に導入しても、アプリケーションの別の部分が破壊されるリスクはありません。

したがって、マイクロサービスの実現は、単なる実稼働以上のものです。むしろ、アプリケーションの構築とテストから学んだ教訓を振り返るよう開発者に求めています。これらのレッスンを組み込むことは、継続的な改善の側面です。最初のマイクロサービスの作成は、予想外に簡単なプロセスだったかもしれません。それを構築することからの教訓を組み込むことは、2番目のマイクロサービスがさらに速く簡単になることを意味します。

すべてをまとめる:小さなことから始め、大きなことを考える

大規模組織内のマイクロサービスエバンジェリストにとっての課題は、基盤を築くこと、組織の変更に取り組むこと、または新しいサービスをプログラミングすることではありません。むしろ、課題は、これらの変更を開始するために、プリンシパルから賛同を得ることです。

単一の個人の観点から見ると、この作業は困難に思えるかもしれませんが、1人でも針を動かすために実行できる多くの具体的な手順があります。

証拠なし–マイクロサービスの概念が機能することの証拠–意思決定者が大規模な制度変更にコミットする方法はありません。したがって、伝道者の仕事は、理想的には成功した小規模なマイクロサービスプロジェクトに取り組むことによって証拠を作成することです。幸いにも、多くのレガシーインフラストラクチャを備えた大規模な組織では、1人または小さなチームが実行可能なマイクロサービスをパイロットする十分な機会があります。

特定の機能を想像してみてください–小さく、便利で、できればミッションクリティカルではないもの–マイクロサービスで拡張すると改善できる可能性があります。上記の設計、構築、および実現プロセスを通じてその機能を実行します。これは、マイクロサービスアプローチのテストケースを表します。それが機能する場合、その実績は足掛かりとして機能します。そこからスケーリングできます。

ほとんどの組織では、マイクロサービスをサポートできる文化を作成し、さらにマイクロサービス自体を作成することは反復的です。最善のアプローチは、小さな成功から始めて、そこから成長することです。出発点は小さく、道のりは長いですが、結果はますます合理化され、焦点が絞られたビジネスユニットとなり、最終的にはデジタル化が進む経済の需要に最終的に応えることができます。

最後に:マイクロサービスベンダーの選択

マイクロサービス戦略へのモノリスには、テクノロジーへの影響、プロセスへの影響、企業文化への影響が含まれます。実際にアジャイルで柔軟であるのに対して、アジャイルで柔軟であると述べるのは簡単です。パートナーになるベンダーを選んでください。自分がどこにいるのか、何を持っているのか、どこに行きたいのかを理解した実績があるベンダーを選びましょう。

ベンダーテクノロジー

すべてのマイクロサービス製品が同等に作成されているわけではなく、マイクロサービスであるという厳しい要件を満たしていない製品もあります。これは、ガートナーが「マイクロサービスウォッシング」と呼んでいるものであり、マイクロサービスの定義に適合しない表面的なマイクロサービスラベルが付いた製品を販売する行為です。

ごく最近まで、SOAとESBは顧客向けアプリケーションの主要な統合戦略でした。このアーキテクチャが勢いを失ったため、多くのベンダーはマイクロサービスなどの新しいアーキテクチャに移行する必要性を感じていました。

理論的には、このピボットは理想的なマイクロサービス戦略のように見えるはずです-顧客やパートナーに機能を公開するマイクロサービスのレイヤー、これらの機能をビジネスユニットに接続するレイヤー、ビジネスユニットをレガシーアプリケーションに接続する第3レイヤー(図1)。

しかし実際には、これらの企業は、自社製品の基礎となるSOAアーキテクチャを取り除く方法をまったく理解していませんでした。結果は通常、マイクロサービスラッパーによってカプセル化されたESBのようになります。

たとえば、顧客情報をAPIとして公開するマイクロサービスを想像してみてください。コンプライアンスルールにより、APIはすべての顧客データを送信する必要がありますが、一部のエージェントのみに送信する必要があります。このマイクロサービスにはESBが含まれています。ESBが顧客データの要求を受信すると、メインフレームに直接連絡しません。最初に、要求しているエージェントがそのデータの受信を許可されているかどうかをチェックする別のマイクロサービスに連絡する必要があります。

これは、マイクロサービスの優れたアーキテクチャ設計原則に違反しています。その統合により、依存関係の多層が生成され、基本的にモノリスが作成されます。1つの部分が壊れると、サービス全体が停止します。

APIは、シンプルでインテリジェント、かつ最新の方法でレガシーメインフレームに接続する必要があります。

その結果、開発者はレガシーソースコード(例:COBOL)を学習または変更する必要なく使用できるツールになります。長い統合期間やレガシーコードを心配する代わりに、開発者はAPIを作成し、堅牢な新機能をわずか数時間で実装できます。これは、増加する顧客の需要を満たすのに十分な速さです。

第8章:マイクロサービスとAPIのビジネスへの影響

マイクロサービスとAPIのメリットはIT部門だけにとどまらず、組織のビジネス側を会話にもっと関与させることが重要です。

要するに、イノベーションをより速く行う必要があるにもかかわらず、組織の「レガシーシステム」が原因でプロジェクトが「複雑で、費用がかかり、時間がかかる」とITチームが言う場合、マイクロサービスが答えになるかもしれません。

レガシーシステムの皮肉は、世界で最も古く、最も成功している企業に影響を与える傾向があることです。IBM、UNISYS、HP、Digital、Siemens、Honeywell、Tandem、Stratusなどの従来のモノリスは、1950年代に事業運営にプラスの影響を与え始めました。VSAM、IDMS、IMS、DB2、Oracle、ADABASなどのデータストレージとアクセス方法は、COBOL、アセンブラー、Fortran、ADS、PRG、およびNaturalで記述されたミッションアプリケーションおよびビジネスクリティカルアプリケーションを通じてデータへの迅速なアクセスを保存および促進する機能において革新的であることが証明されました。

したがって、従来のモノリスでイノベーションを加速する方法を見つけない限り、業界内の「最先端」に留まることが最も困難なのは、最も確立された企業、つまり大きなブランドです。一部の組織は現状に慣れており、革新的なデジタルチャネルとアプリケーションのバックログを減らして配信を高速化することは不可能だとさえ考えていません。

レガシーシステムがあり、モバイルまたはWebを介して提供されるデジタルサービスに大きく依存している顧客や見込み客に対応する必要がある場合、古いテクノロジーと現代の需要の間のギャップを埋める方法を見つける必要があります。

私たちはあまり宣伝するつもりはありませんが、私たちが長年にわたって個人的に関わってきたビジネスユースケースについて、最も自信を持って話すことができます。

私たちの仕事の最も驚くべき側面の1つは、世界最大の組織でさえ、自社開発、ミドルウェアテクノロジー、またはSOA / ESBイニシアチブを使用してレガシーシステムの課題を解決できなかったことです。これらすべての投資は、当時は優れた選択でしたが、数百人、数百万ドル、数年を費やしても、新しい「デジタルエコノミー」の要求に対応できないことがよくあります。

組織のビジネス側は、テクノロジーがどのように機能するかについて少し気にする必要はありません。競争力があり、機敏であり、新しいまたは強化された収益チャネルを構築したいだけです。組織のIT側は、システムへのアクセスと活用の複雑さを軽減することに関心を持っています。これら2つの目標の交差点のどこかで、「最新のマイクロサービス」が会話の一部になります。

多くの場合、マイクロサービスへのアプローチにより、マイクロサービスの作成が数週間から数分または数時間に短縮され、プロジェクトの展開が数か月から数週間に短縮されます。

マイクロサービスはレガシーシステムを備えたあらゆるビジネスにメリットをもたらしますが、ここではいくつかの例を取り上げました。

最新の合理化されたHRポータル

通信会社のBezeqは、.NETで開発されたHRポータルの時代を目の当たりにし始めていました。休暇のリクエストや経費報告書から旅行の承認や会議室の予約まで、何千人もの従業員が使用するポータルは、最新のインターフェースや機能を提供しなくなり、新しい機能の開発には長い時間がかかり、複数の開発チームが関与していました。

お客様のオンボーディングを3倍高速化

数百億ドル規模の管理下にあるメキシコの主要な投資諮問グループは、顧客のオンボーディングプロセスを適応させて、変化する顧客の期待に応えたいと考えていました。課題は、このような顧客セルフサービスなどの機能取り入れたすべての政府に準拠しながら、モバイルアクセスを規制。計画は、新しいAPIテクノロジーで強化された既存のSAP CRM バックエンドを活用することでした。

単純なAPIの作成には15分かかりましたが、より複雑なトランザクションの実装には1週間もかかりませんでした。

マイクロサービスを月単位ではなく日単位でクラウドで提供

オランダを本拠とするプレミアバンクは、顧客がより速く、より簡単に、よりスマートに銀行を運営できるように、新しいテクノロジーを採用するという継続的な使命を帯びていました。FinTechの新興企業と提携して、オープンバンキング、人工知能、ブロックチェーン、循環経済などの分野をすべて、PSD2コンプライアンスに関する活動と組み合わせて調査しています。

この銀行は、ほぼすべてのIT活動を3つのベンダーにアウトソーシングしました。1つはアプリケーション開発、もう1つはアプリケーションのサポートとメンテナンス、およびITインフラストラクチャです。外部委託の労働力は、外部の開発者が数百人で構成大陸、およびITの人々です。つまり、新しいソフトウェア、サービス、さらにはマイクロサービスベースのAPIをリリースするのに最大3か月を要し、変更や新機能の導入にはコストと時間がかかりました。

内部スタッフの効率の向上

以前:保険会社はほとんどのサービスを近代化することができましたが、自動車保険のサービスはレガシーアプリケーションとして残されていました。その結果、エージェントはWebブラウザーと時代遅れの「グリーンスクリーン」を切り替えることを余儀なくされ、生産性と応答性に影響を与えました。

後で:この保険会社は、AS / 400の請求管理システムから、主要な自動車保険のWebアプリケーション内の特定の請求に関連するすべてのレポートを提示するサービスを公開することができました。最初の概念実証はわずか5日で完了しました。生産モードでは、保険代理店は最大30%の時間節約を実現できました。

銀行のイノベーションを50%加速

以前:革新的な「FinTech対応」銀行になりたいと思っていたにもかかわらず、ラテンアメリカの大手銀行は、合併後のレガシーシステムが2か国に広がっており、地域の銀行の中で最も高い運用コストの一部に苦しんでいました。COBOLを使用したメインフレームプログラミングはコロンビアで行われ、Java プログラミングはパナマで行われ、インフラストラクチャはサードパーティのグローバルシステムインテグレーターによって維持されていました。過度の複雑さにより、新しいメインフレームベースの製品とサービスの市場投入までの時間が遅れ、多くの場合、展開に6か月以上かかることがありました。彼らの最優先事項の1つは、商業クライアント向けの支払い処理サービスでした。

後で:銀行の「デジタルジャーニー」は、マイクロサービス対応のAPI統合および管理ソフトウェアに基づいています。最初のプロジェクトには、わずか4〜9週間で4人のJava開発者による12の新しいAPIのトレーニング、作成、およびデプロイメントが含まれていました。新しい支払い処理サービスの展開にかかった合計時間は90日で、通常のメインフレームプロジェクトより50%高速でした。銀行は、プロジェクトの途中でIBM BlueMixからAmazon Lambda にも切り替えたことを考慮して、これらの時間枠を例外的に検討しました。さらに、サービスは以前にマイクロサービスなしで構築されたものよりも約20〜30%速く実行され、DevOpsストレステストは、Lambdaが一緒になって60,000の同時リクエストを処理することで目標をはるかに超えていると結論付けました。

銀行が2週間で6つのグローバルAPIを作成

以前:デジタル、グローバルサービスに対するグローバル銀行のトップ10の需要は、新しいアプリケーションと顧客体験を構築するために必要な100以上の基本APIのバックログにつながりました。

APIゲートウェイとオーケストレーション用の人気のある製品を使用して、200人近くの開発者が1 年以上にわたってプロジェクトに取り組んできました。この製品は、AS / 400およびメインフレームプラットフォームで実行されているレガシー(コア)アプリケーションに特化しておらず、人気にもかかわらず、銀行のニーズに対応することができませんでした。

具体的には、この製品はRPG プログラムを公開するAPIを生成できず、既存のAPIを管理および公開することしかできませんでした。したがって、銀行の開発者は、機能を公開するためにRPGで追加のAS / 400コードを作成する必要がありました。他の場合では、既存のコードを変更する必要がありました。これは、何年もの間、配置され、試行され、テストされてきたアプリケーションの侵襲的慣行です。新しい機能をコーディングするだけでなく、テストと地域の認証とカスタマイズにかなりの時間を費やし、事態をさらに遅らせました。皮肉なことに、開発時間を短縮し、労力を削減するはずのツールが、追加の手作業を作成することになりました。

APIプロジェクトを成功させるためのもう1つの重要な要件は、グローバルAPIの作成でした。国、地域、または基盤となる技術環境に関係なく、同じエンドユーザーエクスペリエンスを備えた統合API です。ビジネスの観点から、これには、構築され、一貫してグローバルな方法で一貫してロールアウトできる新しい製品とサービスの単一の開始点として機能できる共通のロジックと機能の抽出が必要になります。

その結果、わずか2週間で6つの主要なグローバルAPIが作成され、新しいアプローチにより、銀行はモバイルWebまたはクラウドの「オムニチャネル」イノベーションを加速し、いつでもどこでも顧客にサービスを提供できるようになりました。さらに、シンプルさと自動化により、APIは7倍のパフォーマンス向上を実現しました。

これらはほんの一部の業界のいくつかの例であり、他にもたくさんあります。世界中の確立された組織がデジタル経済の成長とミレニアル世代の影響力の増大とデジタルへの焦りに直面している今、マイクロサービスとAPIを検討する絶好の機会はかつてありませんでした。

選択したベンダーやアプローチに関係なく、デジタル化の旅がIT効率、サイクルの高速化、スケーラビリティの向上、競争力のある差別化につながる可能性があります。

 

レガシーな構成もセキュアにできる!ゼロトラストの原理・原則や実現方法に関する資料を無料プレゼント中!

ERPの4つの盲点:SaaSを選ぶべき理由

前書き

ERPシステムと従来の会計アプリケーションは、あらゆる企業にとって重要な記録システムであり、多くの場合、あらゆる企業のITインフラストラクチャのバックボーンを形成します。企業は、会計、財務報告、人事、経費管理、注文管理、在庫管理など、多数のコアビジネス管理機能をこれらのシステムに依存していることに気づくことがよくあります。時が経つにつれて、ERPシステムはさまざまな機能のホストを含むように成長し、企業全体のさまざまな部門のビジネス要求を満たすためにすべてが1つの統合された傘の下にまとめられました。

システムの中心は、その基本的なデータモデルです。ERPシステムの基盤を形成するコアデータモデルは、1つの主要な前提に基づいています。

  • 企業が「アイテム」を販売すると仮定します。それは、このペーパーで私たちが「製品経済」ビジネスと呼んでいるものを構成するビジネスです。

ERPシステムのすべてはこの基本的な仮定を中心に展開し、ERPシステムのコアプロセスとワークフローはこの仮定を念頭に置いて構築されています。しかし、そこには問題があります。ではデジタル製品やサービスの時代、この仮定はもはや成立しません。

今日の世界では、企業はサブスクリプションビジネスモデルを採用して、製品やサービスを収益化しています。これらは、このホワイトペーパーで「サブスクリプションエコノミー」ビジネスと呼ぶビジネスを構成するものです。

サブスクリプションモデルの中心にあるのは、長期にわたる定期的な顧客関係を収益化するという考え方です。従来の注文管理、ERP、および会計システムは、定期的な関係を収益化、管理、測定するようには設計されていませんでした。それらはアイテムを収益化するために構築されました。定期的な関係を収益化、管理、測定するように設計された、Relationship Business Management Systemsと呼ばれる新しい種類のシステムが登場しています。

企業が定期的な繰り返しの関係を収益化するためにサブスクリプションビジネスモデルを採用することを決定すると、ビジネスの運営方法の4つのコア領域にわたって大きな変化が生じます。これは、ERPシステムが処理するように構築されていなかった複雑さを処理するために、ERPシステムを強化する新しいシステムの必要性を生み出します。

1.価格とパッケージ

おそらく誰もがUSBスティックを使ってファイルを保存しているでしょう。そして、誰もがおそらくファイル、ボックス、ドロップボックス、またはグーグルドライブのようなクラウドファイルストレージアプリケーションを使用してファイルを保存しました。

USBスティックの価格設定の例を使用してみましょう。これは、お客様に固定容量のストレージを提供する単一製品の単一価格です。顧客がそのUSBスティックをいっぱいにすると、別のUSBスティックを購入します。おそらく今回は、より容量の大きいUSBスティックを購入し、それに対して固定価格を支払います。

または、これらのUSBスティックを製造している会社であれば、工場に戻って、より多くの容量を持つまったく新しいバッチを製造します。

このスティックの価格を左右する重要な点は、製造コストです。そして、誰かがあなたが製造したものの半分の容量しか必要としないなら、あなたは彼らに半分のUSBスティックを売ることはできません。

1つの製品。1つの価格。それを購入する1つの方法:全部を購入するか、何も購入しないか。次に、ファイルをクラウドに保存する場合と対照をなしてください。さらにストレージが必要な場合は、別のプランに切り替えることができます。または、同じプランを継続していて、プランに含まれている以上の量を保存し始めると、超過分が請求される場合があります。

クラウドストレージサブスクリプションサービスプロバイダーは、同じサービスを利用して、個人ごと、企業ごと、GB ごと、ユーザーごと、使用頻度ごと、または顧客がサービスをどのように使用するかを定義する消費特性ごとに異なる価格を設定できます。

クラウドストレージサブスクリプションサービスプロバイダーは、同じサービスの価格を設定する方法を無数に考え出すことができます。

1つのサービス。無限の価格設定オプション。消費の無限の可能なオプション。

これがサブスクリプションエコノミーでの価格設定の違いです。しかし、これがERPシステムがサブスクリプション価格のニーズを満たすことを困難にしている理由でもあります。ERP価格設定エンジンは、アイテムの価格を構成するために設計されました。アイテムには固定価格があります。頻度、時間、消費レベルの概念はありません。

多くの場合、サブスクリプション価格の処理を要求するカスタムモジュールを備えたERPシステムが見つかります。しかし、これらのモジュールは、稼働するまでにかなりの時間と労力を費やします。稼働しても、これらの新しい価格モデルにわずかな変更を加えるために3〜4か月以上費やしていることに気づきます。

サブスクリプションビジネスでは、成長段階や外部市場の力に応じて、頻繁に価格を変更する必要があることがよくあります。また、達成しようとしているビジネス目標によっては、1つの製品に対して複数の価格戦略を展開する必要がある場合があります。

ERPシステムでは、これらのサブスクリプション価格設定戦略は、しばしば:

  1. ネイティブサポートされておらず、大幅なカスタム開発の取り組みが必要です。
  2.  SKUの急増を作成します。この場合、「アイテム」が誤って使用され、顧客が同じサービスを利用して支払うさまざまな方法が表現されます。

2.注文管理

I製品経済では、すべての注文が新規販売と見なされます。サブスクリプションエコノミーでは、注文は新規販売、アップグレード、ダウングレード、既存のサブスクリプションへのアドオン、更新、またはキャンセルになります。

そして、これらのタイプの注文はそれぞれ、さまざまな方法で発生します。例としてsalesforce.comを取り上げます。小さな会社は、5人分のsalesforce.comのシートを購入することから始めることができます。彼らのビジネスが成長し、彼らがより多くの人々を雇うとき、彼らは追加のシートを購入することができ、彼らは月間、年間のいつでもそれを行うことができると期待し、それらの変更を行うために彼らの更新が来るまで待つ必要はありません。

また、サブスクリプションビジネスは常に顧客に請求を行うため、困難な部分は、請求や収集のアクティビティを中断することなく、顧客がサブスクリプションを簡単に管理または変更できるようにする方法です。

一部の顧客セグメントは、サブスクリプションの完全な制御を必要とし、Webサイト上で、またはサブスクライブするアプリ内でさえ、これらの機能を期待します。また、コールセンターに電話をかけて、これらのタイプのサブスクリプション管理アクティビティを支援することを期待する人もいます。

残念ながら、ERP注文管理モジュールは製品経済の注文を処理するように設計されており、新規販売を表す注文の処理に優れています。しかし、彼らが不足し始めるのは、他のすべてのタイプの注文です:アップグレード、ダウングレード、既存のサブスクリプションへのアドオン、更新、キャンセル。

サブスクリプションエコノミーでは、顧客のニーズは常に変化しており、ニーズが変化するにつれて、それらのニーズに合わせてサブスクリプションを調整できるようになると期待しています。

多くの場合、サブスクリプション企業はERPシステムにサブスクリプションの注文管理を強制することを試みます。しかし、これらの企業は、期待されるレベルの柔軟性または制御を顧客に提供する準備ができていないため、顧客サービスが低下しています。ERP注文管理モジュールをサブスクリプションビジネスモデルのすべての注文処理ニーズに適合させるには、大幅なカスタム開発が必要です。

3.トランザクション処理

製品エコノミーでは、通常、1つの注文で1つの請求書と1つの支払いが発生します。

サブスクリプションエコノミーでは、単一の注文から生じる金融取引は無限に複雑になります。

サブスクリプションエコノミーでは、1つの注文が複数の請求スケジュール、複数の収集イベント、複数の収益スケジュールにつながります。また、サブスクリプションが変更されると(常に変更されます)、変更に対応するために、すべての請求、コレクション、および収益スケジュールを調整する必要があります。

これらを個別のコンポーネントに分解してみましょう。

3.1定期的な請求トランザクション

製品の世界では、時間の考え方は、何かの請求方法に影響しません。もしあなたが店に行き、月の初めの映画と20日の映画のチケットを購入したら、あなたはまだ同じ価格を支払います。

次に、その経験を月額で購読しているものと比較します。もしあなたがNetflixやHuluにサインアップしたら、月の初めにサインアップするか、20日にサインアップするかで、支払が異なるでしょう。

これは、7月20日にサインアップした場合、7月全体を請求するのが不公平になるためです。同様に、1か月あたり3本の映画を視聴できるプランに登録したが、ある特定の月に4本目の映画を視聴したいと決めたとします。その4本目の映画については、その月に追加料金を請求する必要があります。

そのため、サブスクリプションエコノミーでの請求は非常に複雑になり、非常に速くなります。単純な月額10ドルのサービスでさえ、顧客が月の途中でサインアップしたりサービスを変更したりすると複雑になる可能性があります。ERP請求エンジンは、比例配分とクレジットにつながる中間サイクルの請求変更をネイティブに管理するように構築されていません。ほとんどの場合、これらの変更を管理するために重いカスタム開発が必要になります。

SaaSなどの関係ビジネス管理アプリケーションは、この繰り返し発生する請求の複雑さをネイティブに処理できます。しかし、SaaSは、企業が通常はERPアプリケーションで顧客に請求書を提示するための既存のシステムを持っている可能性があることも理解しています。したがって、SaaSは、ビジネスのニーズに応じて、定期的な請求書を顧客に提示する際に選択肢を提供します。

  • 企業はSaaSを使用して請求書の計算と表示を行うことができます。
  • 企業はSaaSを使用して請求書計算を行うことができ、SaaSは請求書アイテムをERP 記録システムにフィードでき、ERPは請求書プレゼンテーションを統合できます。

3.2定期支払い取引

製品の世界では、企業が製品を販売するときに、料金を1回収集します。通常、この支払いは購入時に行われます。

もう一度USBの例に戻りましょう。USBスティックを購入すると、一度購入するだけです。あなたのUSBスティックを販売する会社はそれをあなたから絶えず収集お金を必要としません。

もう一度、あなたが加入している別のサービスと比べてみてください。あなたは一度サービスにサインアップしますが、サービスプロバイダーは常にあなたからお金を集めなければなりません。そして、彼らがあなたからお金を集める頻度は、あなたがサインアップしたプランによって異なります。

次に、サブスクリプションビジネスが実際にお金を回収するために必要なプロセスについて考えます。収集プロセスは、消費者からの収集と、注文書または小切手を使用してサービスの料金を支払う可能性のあるビジネスからの収集では、異なる必要があります。

顧客ベースの各セグメントは、クレジットカード、デビットカードなどの電子決済方法、およびPO、小切手、現金などの非電子決済を含む、異なる支払い方法を設定する場合があります。

また、ビジネスが絶えずサービスを収集している場合、クレジットカードの有効期限が切れたときや支払いが失敗したときに発生する例外の自動化を含め、このプロセスをできるだけ自動化する必要があります。

また、サブスクリプションの世界では、企業もコレクションの結果に基づいてサービスへのアクセスを開始または停止する必要がある状況にあります。そうしないと、支払いをしていなくても、顧客がサービスにアクセスできる状況に陥ります。

または、その逆の場合、顧客はサインアップ時に支払いをした可能性がありますが、サービスを有効にするのに遅延があります。つまり、コレクションとサービスへのアクセスは密接に接続されている必要があります。

ERPシステムは、定期的な支払いの性質を処理するように設計されておらず、多くのシステムには基本的な大量の支払い自動化機能がありません。

幸い、SaaSは大量の支払いの自動化を自然に処理できます。

しかし、SaaSは、企業が既存の収集システムを導入している可能性があることも理解しています。したがって、SaaSは、処理するコレクションの性質に応じて、定期的なコレクションに関して選択肢を提供します。

• 大量の電子支払いを自動化するシステムが必要な場合、企業はSaaSを支払いコレクションに使用できます。

• 企業はERPシステムを収集に使用でき、SaaSは既存の収集プロセスに統合できます。

3.3定期的な収益スケジュール

製品経済では、販売に関連するトランザクションの財務上の影響は単純でした。例:1月に注文を予約した場合、通常はすぐに支払いを回収し、できるだけ早く発送し、その収益をすぐに認識しました。トランザクションが多くの期間にわたって分散することはまれでした。

サブスクリプションエコノミーでは、各販売は複数の会計期間にまたがるトランザクションを生成します。たとえば、誰かがケーブルテレビの3か月のサブスクリプションにサインアップし、1月に請求される3か月間前払いで毎月$ 300が請求されたとします。

また、サブスクリプションは、サインアップ時、請求時、または現金の回収時に認識されます。以下の図は、月額100ドルで請求される3 か月のサブスクリプションサービスの収益がどのように認識されるかを示す簡単な例です。

これは、顧客が年の途中でサブスクリプションを変更し、それに映画パッケージを追加することを決定した場合、さらに複雑になります。

アップグレードセールは、元のセール用に設定されたすべての元のトランザクションに影響します。変更に合わせて調整する必要のあるすべての請求および収集スケジュールに加えて、元の収益認識スケジュールは、新しいサブスクリプションに一致するように調整する必要があります。これは、サブスクリプションサービスの収益認識スケジュールの管理に関して、財務チームに大きな複雑さをもたらします。

SaaSなどのリレーションシップビジネス管理システムは、サブスクリプションの変更による収益認識の影響を処理するように設計されています。SaaSは、通常ERPシステムを補完する収益認識エンジンと統合することもでき、サブスクリプション変更の最終結果を外部の収益認識エンジンにフィードできるため、企業は収益認識のための集中型システムを維持できます。

4.指標とレポート

ビジネスが物理的な製品を販売するのではなく、サービスのサブスクリプションを販売すると、ビジネスモデル全体が変化し、その結果、ビジネスの測定方法も変化します。

企業がUSBスティックなどの製品を販売する場合、それらは通常、販売されたUSBスティックのユニット数のレポートに焦点を当てています。

お客様はUSBスティックに対して1回請求され、現金が1回収集されるため、通常、ビジネスは過去に収集された請求と現金を測定します。

しかし、サブスクリプションエコノミーでは、サブスクリプションは将来に支払われる定期的な収益ストリームを表すため、企業はビジネスに将来の価値を追加するサービスを販売しています。

従来の財務指標に加えて、企業はARRやMRRなどの将来を見据えた定期的な指標を測定し、解約する必要があります。

また、企業は、顧客の数を測定するだけでなく、顧客のライフタイムバリューを測定して、顧客の価値やサブスクリプションの長さを増加させる製品またはサービスを決定できるようにする必要があります。

データモデルのコアに「アイテム」を使用して設計されたERPシステムには、データモデルに本質的に組み込まれた時間または反復の概念がありません。これらのメトリックはERPアプリケーションによってネイティブにキャプチャされないため、通常、カスタム作業とカスタムデータアルゴリズムが必要です。

SaaSのデータモデルは、MRRやTCVなどのサブスクリプションメトリックを最も詳細なレベルでキャプチャするように設計されています。これにより、顧客は、主要なサブスクリプションメトリックのコンテキストで、製品、地域、顧客などのあらゆるディメンションに沿って集計されたビジネスの健全性を表示できます。

結論

結論として、ERPシステムは今日のエンタープライズITインフラストラクチャのバックボーンを形成します。しかし、これらのシステムは、サブスクリプションビジネスの成功に不可欠な4つの領域に不足しています。サブスクリプションエコノミーでは、企業はERPシステムをSaaSなどのリレーションシップビジネス管理アプリケーションで補完することを検討する必要があります。これらのアプリケーションは、ERPシステムが対象としていない複雑さを管理するように設計されています。

サブスクリプションエコノミーでERPアプリケーションを補完するSaaSシステムがない場合:

  • GMとビジネスリーダーは、ERPシステムによって成長戦略が制限されていることに気づき、収益の可能性が失われています。
  • 財務運用チームは手動のプロセスとスプレッドシートを使用するため、運用効率が低下します。
  • ITリーダーは、貴重なドルとかなりの時間と開発リソースを費やして、ERPアプリケーションがビジネスのニーズを満たすように強制します。
  • ERPシステム内のデータモデルでは、繰り返し発生する関係の価値を測定できなくなり、計画と意思決定に課題が生じます。

デジタルトランスフォーメーションとビジネスバリューの推進

デジタルトランスフォーメーションは、組織のプロセス・イニシアチブの主要な触媒であり、ビジネスの目標となっています。エンパワーメントされた顧客の増加と破壊的な競合他社からの脅威が、この傾向を強めています。Forresterの2018年第1四半期デジタルプロセス自動化調査によると、ビジネスおよびテクノロジーの意思決定者の32%が、デジタルビジネストランスフォーメーションの加速がプロセス改善イニシアチブの最重要ドライバーであると答えています。

続きを読む

レガシーと統合する方法-デジタルプラットフォームの中核を生み出す

インテグレーション(統合)は、コンピュータアプリケーションを連携させて意味のある結果を提供するための接着剤です。統合の概念とベストプラクティスの多くは何十年も前から存在していますが、アプリケーションを作成する新しい方法では、これらの統合パターンを再評価する必要があります。たとえば、複数のモノリシックアプリケーションを統合することは困難ですが、マイクロサービスやその他の分散配置パターンの台頭により、この課題は飛躍的に大きくなっています。

続きを読む