fbpx

認証進化の歴史:パスワードから生体認証まで

この記事では、過去50年間の認証の進化を探ります。パスワードと2要素認証から、真のパスワードレスセキュリティとゼロトラストセキュリティの時代に至るまで、ユーザー認証が長年にわたってどのように変化してきたか、またそれがどこに向かっているかを確認します。

認証は共有秘密を超えて進化している

アカウント乗っ取り詐欺(ATO)のコストは過去2年間で倍増しています。悪意のあるログインがeコマーストラフィックの90%以上を占めています。クレデンシャルスタッフィング攻撃は史上最高であり、米国の銀行業界には毎日5000万ドルのコストがかかっています。英国の全企業の半数以上が、過去2年間でフィッシング攻撃の被害を受けました。

パスワード、多要素認証、セキュリティトークン、バイオメトリクスの間で、インターネットユーザーはデジタルIDを保護するためにこれまで以上に多くの方法を持っています。それでも、これらの統計は、毎年悪化するデジタルIDの問題の物語を伝えています。

パスワードは1960年代に発明されました。2019年に早送りし、世界の多くは、オンラインサービスとITリソースへのアクセスを保護するための50年前のテクノロジーに依然依存しています。より強力な2要素認証ソリューションは広く利用可能ですが、広く採用されていません。インターネットユーザーの10%未満。実際、Mary Meekerによる2019年のインターネットトレンドレポートは、2FAのグローバルな採用が実際には50%の低い範囲で停滞していると推定しています。

非常に多くの認証方法を使用すると、アカウント乗っ取りの統計情報は悪化するのではなく、向上すると考えられます。

共有秘密は常に問題だった

問題は、パスワード、2FA、レガシーの多要素認証ソリューションに共通することが1つあるということです。それらは共有シークレットに依存しています。つまり、ユーザーには秘密があり、中央の権限には同じ秘密が保持されます。認証時に、これら2つのシークレットが比較され、ユーザーアクセスが承認されます。悪意のあるサードパーティがシークレットを傍受すると、ユーザーになりすます可能性があります。

悪い知らせは、この共有シークレットへの依存が、アカウント乗っ取り(ATO)の急増の一因となっている一方で、フィッシング、資格情報の詰め込み攻撃、およびパスワードの再利用に対して脆弱な多数のユーザーを維持していることです。

良いニュース?デジタルアイデンティティの状況は急速に変化しつつあります。

信頼についての簡単な歴史…

パスワード

  • 1961年:パスワードはFernando J. Corbatoによって発明された
  • 1974年:Unix OSでの最初のハッシュ形式のパスワードストレージ
  • 1998年:CAPTCHAとAdvanced Encryption Standard (AES)が公開された

ハードウェアセキュリティトークン

  • 2003年:ハードウェア2要素認証の主流の採用
  • 2005年:HOTP (OTP)アルゴリズムが登場

SMS 2FAA

  • 2007年:初代iPhoneがスマートフォン時代の幕を開けた
  • 2011年:TOTPが正式にRFC 6238になった
  • 2012年:FIDOアライアンスがパスワードなしの認証標準を確立するために立ち上げられた

Token MFAとしての電話

  • 2013年:アップルがTouchIDで生体認証を世界に紹介

真のパスワードなしのセキュリティ

  • 2018年~

ユーザー認証技術は進化しました。世界は、共有シークレットに依存する独自のモノリシック認証方式から、セキュリティと使いやすさを優先する標準ベースのパスワードレスソリューションに急速に移行しています。

デジタルIDの方向性を予測するには、最初にここに到達する方法を理解する必要があります。このペーパーでは、デジタル認証の歴史の簡単なタイムライン、一般的なさまざまな認証方法の概要、およびこれらのアプローチが相互にどのように組み合わされるかを探る認証攻撃マトリックスを提供します。

パスワード

2014年に、コンピューターパスワードの発明者であるフェルナンドJ. コルバトは記録に残り、彼の発明は「悪夢のようなもの」になっていると述べました。Corbató は1961年頃、MITで当時革命的な互換性のあるタイムシェアリングシステム(CTSS)の開発に携わっていたときに、パスワードを発明しました。パスワードが解決していた問題は、これらのコンピュータエンジニアリングの初期の開拓者が「複数の」端末にログオンして、自分の記録に確実にアクセスできるようにすることでした。

彼らが「複数」について話したとき、チームは接続されたグリーンスクリーン端末のほんの一部に言及していました。早送り60年近くとCorbatóの発明は、依然として支配的なログインアクセス方式である- 今日の認証セッションの大半を支えます。パスワードは、ラップトップからタッチスクリーンやコネクテッドカーさえ備えたスマートモバイルデバイスに至るまで、数十億のデバイスで毎日数十億のセッションを認証しますが、パスワードの問題はどれほどひどいですか。

資格スタッフィングは、コンシューマーバンキングトラフィックの56%以上を占める悪質なログインと共に、流行となっています。

2016年以降、50億を超えるパスワードが盗まれました。盗まれたパスワードの武器化はかつてないほど容易になりました。SNIPRなどのツールにより、これまで以上に簡単に攻撃を開始できます。 攻撃のコストはハッカーにとって下がっていますが、防御のためのコストは企業にとって劇的に増加しています。

クレデンシャルスタッフィング攻撃は過去最高で、アカマイは「1年足らずで300億回以上の悪意のあるログイン試行」を報告しています。 SANS Analyst Researchによると、資格情報の再利用攻撃は、最大1%から2%の成功率を達成することができます。

2019年のジャベリン戦略の「クラウドの難問」レポートによると、これらの傾向をまとめると、ATO詐欺の費用が前年比で2倍になり、2018年には17億ドルを超えたのは当然のことです。

「ファイアウォールの内側からクラウドへのアプリケーションのこの大規模な移行は、広範囲にわたる顧客のパスワード違反と相まって、ATOとそのコストの急上昇の主な原因です。」

ハードトークン2FA

大企業で働いたことがあれば、これらのいずれかを使用した可能性があります。ハードウェアセキュリティトークンが普及したとき、時間ベースのワンタイムパスワード(TOTP)アルゴリズムと改ざん防止ハードウェアを使用して、世界のセキュリティを強化しました。ハードトークンは認証(2FA)に「第2要素」を導入し、より高いレベルの保証を必要とする認証セッションに追加の標準ベースのセキュリティを提供するのに優れていました。これらのデバイスは、パスワードよりもセキュリティを強化することを約束していましたが、長年にわたって、ユーザーエクスペリエンスに多くの欠点とセキュリティの脆弱性があることが判明しています。

トークンの共有は企業で一般的な慣例であり、従業員は、ハードトークンを付箋のパスワードのように渡すことが知られています。

ハードトークンOTPはキーロガーまたは中間者攻撃のいずれかによってキャプチャされ、企業に追加のセキュリティ上の懸念をもたらすため、悪意のある攻撃も一般的です。

しかし、ハードトークンの最も困難な側面は、その使いやすさのままです。ユーザーは、追加のデバイスの必須使用によって引き起こされる追加の摩擦に不利に反応することがよくあります。

世界がデスクトップを超えてモバイルデバイスに移行すると、ハードトークンはさらに使いにくくなり、ユーザーエクスペリエンスに大きな摩擦が加わりました。その結果、消費者の間での採用の欠如は、ハードトークンベースの2FAの大量採用への別のハードルを作成しました。

スマートカード

スマートカードは、企業や政府機関で使用されているプラ​​スチックカードです。マイクロプロセッサが組み込まれており、識別、認証、物理的アクセス、さらには金融取引のために従業員が携帯または着用します。公共および金融セクターでは、セキュリティ上の懸念により携帯電話の使用がサポートされていないミッションクリティカルな環境でスマートカードが正常に展開されています。

スマートカードとハードトークンは、同様のユーザビリティの問題を共有しますが、重要な利点はセキュリティです。スマートカード認証は主に公開キー基盤(PKI)に依存しているため、多くの場合、共有シークレットの代わりにスマートカード認証が使用され、セキュリティが大幅に向上します。

SMS 2FA

モバイル時代には、ハードトークンによって普及したTOTPメソッドを使用したSMS認証が導入されました。

別のハードウェアでOTPを生成する代わりに、サーバーがコードを生成し、SMSを介してモバイルデバイスにユーザーに配信します。ほとんどの人が何らかの携帯電話を持っているので、ハードウェアトークンのコストを回避することで、多くのサービスプロバイダーが大規模な消費者向けの2FA SMSを採用するようになりました。これは現在でも最も広く採用されている2FA方式であり、コンシューマーユースケースの「ハードトークンと同等」と見なすことができます。ただし、SMSベースの認証は、その成長をほとんど停止させる重大なリスクを伴います。

私たちは、SS7ネットワーク攻撃を介してSMSメッセージを簡単に傍受できること、一般的なSIM-Swapping問題がOTPメッセージを間違った携帯電話(通常は詐欺師の手に渡る)に配信する方法、そして人気の高いキーロガーと携帯電話の使いやすさを見てきました。 Modlishkaなどのマルウェアの亜種には、自動化されたSMS OTPスチール機能が搭載されています。

そのため、サービスプロバイダーにとっては安価でしたが、SMS 2FAアプローチは、モバイルデバイスまたはWebブラウザーにOTPを入力する必要があるため、ユーザーエクスペリエンスに顕著な摩擦を加えながら、新しいセキュリティ問題を作成しました。また、共有シークレットへの依存のおかげで、認証へのこのアプローチはユーザーのセキュリティに意味のある影響を与えることができませんでした。

国立標準技術研究所(NIST)が2016年7月に2 つ目の強力な要因としてSMSの使用を推奨するのをやめたときのSMS 2FA LEDの脆弱性が転倒ポイントに。

TOKEN MFAとしての電話

企業とそのユーザーがモバイルデバイスにシフトするにつれて、ソフトトークンMFAが主流になりました。これらの方法は、ソフトウェアベースのワンタイムパスワード(OTP)を普及させ、ハードトークンの大部分をPIN、PUSH、または生体認証ベースのMFA に置き換えることに成功しました。

企業や開発者の間で人気があったが、ソフトウェアベースの2要素および多要素認証(2FA / MFA)システムの多くには、多くの既知の弱点があります。ワンタイムパスワード(OTP)を利用する最も人気のある認証方法のいくつかは、共有シークレットに依存しているため、ユーザーはソーシャルエンジニアリング、モバイルマルウェア、および中間者(MitM )攻撃の影響を受けやすくなっています。

2FAログインインターフェースを偽装するフィッシングサイトの人気が高まり、Gmail ユーザーなどの大規模な集団を標的とした攻撃が大規模に展開されています。Microsoftなどの主要なMFAプロバイダーでさえ、ハッカーがIMAP プロトコルを利用してMFAをバイパスするなど、重大な攻撃を経験しています。

Stripeが委託した最近の調査によると、ソフトトークンMFAでさえ、消費者向けアプリケーションでほとんど採用されていないことが示されています。販売者は、カートの放棄率の増加に対する懸念を、顧客体験に摩擦をもたらさないための主要な要因として挙げています。

真のパスワードなしのセキュリティ

これは、認証の進化における次のステップです。前任者とは異なり、このアプローチは共有シークレットの使用に依存しません。代わりに、ユーザーの信頼できるデバイスに格納されている秘密キーを使用して、オンラインサービスにアクセスし、トランザクションに署名します。

真のパスワードレスアーキテクチャでは、パスワード、PIN、SMSコード、OTPなどの共有シークレットの使用は、公開鍵暗号化に置き換えられています。

秘密鍵はユーザーがデバイス上で生成し、常にデバイス上に残ります。AppleのTouch IDなどの生体認証センサー。Face IDとその対応するAndroidおよびWindowsは、公開鍵暗号を使用して認証サーバーに対して検証されるこれらの資格情報のロックを解除するためによく使用されます。

企業内にパスワードや共有シークレットを保存するのではなく、True Passwordless Securityは王冠の宝石をエッジに移動します。ユーザーの資格情報は、ユーザーが管理するスマートフォンやデバイスの最も信頼できる領域に安全に保存されます。このアプローチは、企業内外での採用だけでなく、金融サービス、決済、ヘルスケア、eコマースセクター全体での大規模な展開にも大きな勢いを見せています。多くの真のパスワードなしのデプロイメントは、以前はIAMスペースに欠けていた相互運用性と革新のレイヤーを利用して、FIDO(Fast Identity Online)などのオープンスタンダードを活用しています。

使い方

真のパスワードなしのセキュリティ公開鍵暗号、オープンスタンダード、および生体認証センサーの使用を組み合わせて、完全にパスワードなしの認証フローを作成します。

共有秘密から離れたパラダイムシフト…なぜ今なのか?

FIDOなどのPKCベースの認証規格の採用

セキュリティの標準化により、インターネットの最大の成果のいくつかがもたらされました。SSL / TLS標準なしで安全なeコマースを実現できますか?FIDO認証標準は、真のパスワードレスフレームワークが具体化すべきものの主な例であり、あらゆる規模の組織がパスワードや共有シークレットを超えて前進することに成功しています。

モバイル生体認証センサーの主流の採用

今日出荷されるほぼすべてのスマートフォンには、1つ以上の高度な生体認証センサーが搭載されています。指紋、顔、虹彩、音声認識の台頭により、企業は、大規模なユーザーにパスワードなしのエクスペリエンスを簡単に提供できるようになりました。

主要なブラウザがパスワードなしの認証をサポート

2018年現在、FIDO Web認証標準(WebAuthn )は、Chrome、Safari、FireFox 、Edge などの主要なWebブラウザーでサポートされています。この主要なマイルストーンにより、真のパスワードなしセキュリティのサポートがさらに幅広いWeb読者にもたらされ、採用がさらに加速しました。

PSD2規制により強力な顧客認証を実施

欧州連合(EU)PSD2の強力な顧客認証(SCA)規制は、支払いサービスプロバイダーが最新の強力な認証技術を採用するための規制フレームワークを作成しており、サポートされる要素の1つとしてパスワードなしの生体認証の使用を明示的にサポートしています。

技術の巨人、大規模なパスワードなしの取り組みを加速

MicrosoftやGoogleなどの業界リーダー、Azure Active Directory(Azure AD)は、OAuth 2.0やOpenID Connect などの業界標準プロトコルをサポートし、IDをサービスとして提供することで、アプリケーション開発者の認証を簡素化します。

それらはどのようにすべて積み上げますか?

認証は、共有シークレットに依存するモノリシックシステムを超えて、真のパスワードレステクノロジーに進化しました。パスワードを置き換えるための世界的な進化運動が進行中です。

共有シークレットからのパラダイムシフトが起こっており、組織はそれを採用して、データ侵害、資格情報の盗難、そして最終的にはアカウントの乗っ取りや金融詐欺などの高額なイベントにつながる無限のサイクルを回避する必要があります。以上のことを踏まえて、さまざまなアプローチはどのように比較されますか?次の表は、多くの既知のセキュリティの脅威と利点をヒートマップし、重要な認証ソーシングの決定の基礎となる知識を追加して、幹部や実務家に提供されています。

リモート会議を開始するための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システム内のデータモデルでは、繰り返し発生する関係の価値を測定できなくなり、計画と意思決定に課題が生じます。

ネットワークの新しい規範:SDN (Software Defined Networking)

従来のネットワークアーキテクチャは今日の企業、キャリア、エンドユーザの要求を満たすには不向きだ。Open Networking Foundation (ONF) が主導する幅広い業界の努力のおかげで、SoftwareDefined Networking (SDN) はZTNAへのネットワークアーキテクチャを変革している。

エグゼクティブサマリー

SDN アーキテクチャでは、制御とデータプレーンは分離され、ネットワークインテリジェンスと状態は論理的に集中化され、基礎となるネットワークインフラストラクチャはアプリケーションから抽象化される。その結果、企業やキャリアは前例のないプログラマビリティ、自動化、ネットワーク制御を獲得し、変化するビジネスニーズに容易に適応する高度にスケーラブルで柔軟なネットワークの構築を可能にします。

ONF は非営利の業界コンソーシアムで、SDN の進歩をリードし、OpenFlowプロトコルのような SDNアーキテクチャの重要な要素を標準化している。OpenFlow は SDN のために特別に設計された最初の標準インターフェースであり、複数のベンダのネットワークデバイス間で高性能で粒度の高いトラフィック制御を提供します。

OpenFlow ベースの SDN は現在様々なネットワーキングデバイスとソフトウェアで展開されており、企業とキャリアの両方に大きな利益をもたらしています。

  • 複数ベンダーのネットワークデバイスの一元管理と制御。
  • 共通のAPIを使用して、オーケストレーションやプロビジョニングのシステムやアプリケーションからネットワークの詳細を抽象化することで、自動化と管理を改善します。
  • 個々のデバイスを設定したり、ベンダーのリリースを待つことなく、新しいネットワーク機能やサービスを提供することで、迅速なイノベーションを実現します。
  • 共通のプログラミング環境を使用して、オペレータ、企業、独立系ソフトウェアベンダー、ユーザー(機器メーカーだけでなく)がプログラミングを行うことで、すべての関係者に収益と差別化を促進する新たな機会を提供します。
  • ネットワークデバイスの集中管理と自動管理、統一されたポリシーの実施、設定ミスの減少により、ネットワークの信頼性とセキュリティが向上します。
  • セッション、ユーザー、デバイス、アプリケーションの各レベルで包括的かつ広範なポリシーを適用できるため、よりきめ細かなネットワーク制御が可能になります。
  • アプリケーションが中央化されたネットワークの状態情報を利用して、ネットワークの動作をユーザーのニーズにシームレスに適応させることで、より良いエンドユーザー体験が得られる。

SDN はダイナミックで柔軟性のあるネットワークアーキテクチャであり、既存の投資を保護しながらネットワークの将来性を保証する。SDN によって、今日の静的なネットワークはビジネス、エンドユーザ、市場のニーズの変化に迅速に対応できる拡張可能なサービスデリバリプラットフォームへと進化することができる。

新しいネットワークアーキテクチャの必要性

モバイルデバイスやコンテンツの爆発的な普及、サーバの仮想化、クラウドサービスの出現など、ネットワーク業界では従来のネットワークアーキテクチャの再検討が進められています。従来のネットワークの多くは階層構造になっており、ツリー構造に配置されたイーサネット・スイッチを何層にも重ねて構築されています。この設計は、クライアント・サーバ・コンピューティングが主流だった時代には理にかなっていましたが、このような静的なアーキテクチャは、今日のエンタープライズ・データセンター、キャンパス、およびキャリア環境の動的なコンピューティングおよびストレージのニーズには不向きです。新しいネットワーク・パラダイムの必要性を促進している主なコンピューティング・トレンドには、以下のようなものがあります。

  • 交通パターンの変化。企業のデータセンター内では、トラフィックのパターンが大きく変化しています。通信の大部分が 1 つのクライアントと 1 つのサーバの間で行われるクライアント・サーバ・アプリケーションとは対照的に、今日のアプリケーションは異なるデータベースとサーバにアクセスし、「東西」のマシン間のトラフィックを大量に発生させた後、従来の「南北」のトラフィック・パターンでエンドユーザ・デバイスにデータを返しています。同時に、ユーザーは、自分のデバイスを含むあらゆるタイプのデバイスから企業のコンテンツやアプリケーションにアクセスし、いつでもどこからでも接続したいと考えているため、ネットワーク・トラフィック・パターンも変化しています。最後に、多くの企業データセンターの管理者は、プライベート・クラウド、パブリック・クラウド、またはその両方を組み合わせたユーティリティ・コンピューティング・モデルを検討しており、広域ネットワークのトラフィックが増加しています。
  • ITのコンシューマ化です。スマートフォン、タブレット、ノートパソコンなどのモバイル・パーソナル・デバイスを利用して企業ネットワークにアクセスするユーザーが増えています。IT部門は、企業のデータや知的財産を保護し、コンプライアンスを遵守しながら、これらのパーソナルデバイスをきめ細かく対応しなければならないというプレッシャーにさらされています。
  • クラウドサービスの台頭。企業はパブリックとプライベートの両方のクラウドサービスを積極的に取り入れており、その結果、クラウドサービスはかつてないほどの成長を遂げています。企業のビジネスユニットは、アプリケーション、インフラストラクチャ、およびその他の IT リソースにオンデマンドでアラカルトでアクセスできる俊敏性を求めています。さらに複雑さを増しているのが、セキュリティ、コンプライアンス、監査要件の強化、ビジネスの再編、統合、合併など、一夜にして前提条件が変わる可能性のある環境下で、IT部門がクラウドサービスの計画を立てなければならないということです。プライベート・クラウドでもパブリック・クラウドでも、セルフサービス・プロビジョニングを提供するには、コンピューティング、ストレージ、およびネットワーク・リソースの弾力的なスケーリングが必要です。
  • “ビッグデータ “とは、より多くの帯域幅を意味します。今日の「ビッグデータ」またはメガデータセットを処理するには、何千台ものサーバで大規模な並列処理を行う必要があり、これらのサーバはすべて相互に直接接続する必要があります。メガデータセットの増加に伴い、データセンターのネットワーク容量の追加が常に求められています。ハイパースケールデータセンターネットワークの運営者は、ネットワークをこれまで想像を絶する規模にまで拡張し、あらゆる接続性を維持しながら、破たんすることなくネットワークを拡張しなければならないという困難な課題に直面しています。

現在のネットワーク技術の限界

現在の市場の要件を満たすことは、従来のネットワーク・アーキテクチャでは事実上不可能です。企業の IT 部門は、予算が横ばいまたは削減されていることに直面し、デバイスレベルの管理ツールや手動のプロセスを使用して、ネットワークから最大限の効果を得ようとしています。通信事業者も、モビリティと帯域幅の需要が爆発的に高まる中、同様の課題に直面しています。既存のネットワーク・アーキテクチャは、今日のユーザー、企業、通信事業者の要件を満たすように設計されたものではなく、むしろネットワーク設計者は、以下のような現在のネットワークの制限によって制約を受けています。

  • うっ血につながる複雑さ。今日までのネットワーキング技術は、主に任意の距離、リンク速度、およびトポロジ上でホストを確実に接続するために設計されたプロトコルの離散的なセットで構成されていました。ここ数十年の間にビジネスや技術的なニーズを満たすために、業界はネットワーキングプロトコルを進化させ、より高いパフォーマンスと信頼性、より広い接続性、そしてより厳しいセキュリティを実現してきました。しかし、プロトコルは個別に定義される傾向があり、それぞれが特定の問題を解決するものであり、基本的な抽象化の恩恵を受けることはありません。これが、今日のネットワークの主要な制限の一つである複雑さにつながっています。たとえば、デバイスを追加したり移動したりするには、IT 部門は複数のスイッチ、ルータ、ファイアウォールWeb認証ポータルなどに触れ、デバイスレベルの管理ツールを使用して ACL、VLAN、サービス品質(QoS)、およびその他のプロトコルベースのメカニズムを更新しなければなりません。さらに、ネットワーク・トポロジー、ベンダーのスイッチ・モデル、ソフトウェアのバージョンをすべて考慮しなければなりません。このように複雑なため、今日のネットワークは比較的静的なものとなっており、IT 部門はサービス中断のリスクを最小限に抑えようとしています。ネットワークの静的な性質は、今日のサーバ環境の動的な性質とは対照的です。サーバの仮想化により、ネットワーク接続を必要とするホストの数が大幅に増加し、ホストの物理的な位置に関する前提条件が根本的に変化しました。仮想化以前は、アプリケーションは 1 台のサーバ上に存在し、主に特定のクライアントとトラフィックを交換していました。今日では、アプリケーションは複数の仮想マシン(VM)に分散しており、相互にトラフィックの流れを交換しています。VMはサーバのワークロードを最適化してリバランスを取るために移行するため、既存のフローの物理的なエンドポイントが時間の経過とともに(場合によっては急速に)変化します。VM の移行は、アドレススキームやネームスペースから、セグメント化されたルーティングベースの設計の基本的な概念に至るまで、従来のネットワーキングの多くの側面に挑戦しています。仮想化技術の採用に加えて、今日では多くの企業が音声、データ、およびビデオ・トラフィックのために IP コンバージド・ネットワークを運用しています。既存のネットワークでは、異なるアプリケーションに対して差別化された QoS レベルを提供することができますが、これらのリソースのプロビジョニングは非常に手動で行われます。IT 部門は、各ベンダーの機器を個別に設定し、ネットワーク帯域幅や QoS などのパラメータをセッションごと、アプリケーションごとに調整する必要があります。静的な性質のため、ネットワークはトラフィック、アプリケーション、ユーザーの要求の変化に動的に適応することができません。
  • 一貫性のない方針。ネットワーク全体のポリシーを実装するために、IT 部門は何千ものデバイスやメカニズムを設定しなければならない場合があります。例えば、新しい仮想マシンが立ち上がるたびに、IT 部門がネットワーク全体の ACL を再構成するのに数時間、場合によっては数日かかることもあります。今日のネットワークの複雑さは、IT 部門がアクセス、セキュリティ、QoS、その他のポリシーを一貫して適用することを非常に困難にしており、企業はセキュリティ侵害、規制への違反、その他の悪影響を受けやすくなっています。
  • スケール感の無さ。データセンターの需要が急速に増加するにつれ、ネットワークも成長しなければなりません。しかし、構成と管理が必要な数百から数千のネットワーク・デバイスが追加されると、ネットワークは非常に複雑になります。また、IT 部門は、予測可能なトラフィック・パターンに基づいてネットワークを拡張するために、リンクのオーバーサブスクリプションに頼ってきましたが、今日の仮想化されたデータ・センターでは、トラフィック・パターンは信じられないほど動的で、したがって予測不可能です。グーグル、ヤフー、フェイスブックなどのメガ・オペレーターは、さらに困難なスケーラビリティの課題に直面しています。これらのサービスプロバイダは、大規模な並列処理アルゴリズムとそれに関連するデータセットをコンピューティングプール全体で使用しています。エンドユーザーのアプリケーションの範囲が拡大するにつれ(例えば、検索結果をユーザーに即座に返すためにワールドワイドウェブ全体をクロールしてインデックスを作成するなど)、コンピューティング要素の数は爆発的に増加し、コンピュートノード間のデータセットの交換はペタバイトに達する可能性があります。このような企業には、数十万、数百万の物理サーバ間で高性能かつ低コストの接続性を提供できる、いわゆるハイパースケール・ネットワークが必要となります。このようなスケーリングは、手動での設定ではできません。競争力を維持するためには、通信事業者はこれまで以上に価値の高い、より差別化されたサービスを顧客に提供しなければなりません。ネットワークは、異なるアプリケーションと異なるパフォーマンスニーズを持つユーザーのグループにサービスを提供しなければならないため、マルチテナンシーは、通信事業者のタスクをさらに複雑にしています。顧客のトラフィック・フローをステアリングしてカスタマイズされたパフォーマンス制御やオンデマンド配信を提供するなど、比較的簡単に見える主要な操作も、既存のネットワーク、特にキャリア・スケールで実装するには非常に複雑です。また、ネットワーク・エッジに特殊なデバイスを必要とするため、資本支出や運用コストが増加し、新サービスの導入までの期間も長くなります。
  • ベンダー依存通信事業者や企業は、変化するビジネスニーズやユーザーの要求に迅速に対応して、新しい機能やサービスを展開しようとしています。しかし、ベンダーの機器の製品サイクルが3年以上に及ぶこともあり、その対応能力は妨げられています。標準的でオープンなインターフェイスがないため、ネットワーク事業者が個々の環境に合わせてネットワークを調整する能力が制限されています。市場の要求とネットワークの能力の間にあるこのミスマッチが、業界を転換点に追い込んでいます。これに対応するため、業界は Software-Defined Networking (SDN) アーキテクチャを作成し、関連する標準を開発している。

 

ソフトウェア定義型ネットワーキングの導入

Software Defined Networking (SDN) はネットワーク制御が転送から切り離され、直接プログラム可能な新しいネットワークアーキテクチャである。以前は個々のネットワークデバイスに強く縛られていた制御がアクセス可能なコンピューティングデバイスに移行することで、基礎となるインフラストラクチャをアプリケーションやネットワークサービスのために抽象化することが可能になり、ネットワークを論理的または仮想的なエンティティとして扱うことができるようになります。

図 1 は SDN アーキテクチャの論理的なビューを示している。ネットワークのインテリジェンスは(論理的に)ソフトウェアベースの SDN コントローラに集中され、ネットワークのグローバルなビューを維持している。その結果、ネットワークはアプリケーションとポリシーエンジンに単一の論理的なスイッチとして見える。SDN によって、企業とキャリアは単一の論理ポイントからネットワーク全体をベンダーに依存せずにコントロールできるようになり、ネットワークの設計と運用が大幅に簡素化される。SDN はまた、ネットワークデバイス自体も大幅に単純化する。なぜなら、何千ものプロトコル標準を理解して処理する必要がなくなり、SDN コントローラからの指示を受け入れるだけだからだ。

おそらく最も重要なことは、ネットワークオペレータと管理者は何千ものデバイスに散らばった何万行もの設定を手作業でコーディングするよりも、この単純化されたネットワークの抽象化をプログラムで設定することができるということだ。さらに、SDN コントローラの集中化されたインテリジェンスを活用することで、IT はリアルタイムでネットワークの動作を変更し、新しいアプリケーションやネットワークサービスを数時間から数日のうちにデプロイすることができる。

今日必要とされている数週間や数ヶ月ではなく。ネットワークの状態を制御層に集中させることで、SDN はネットワークマネージャに動的で自動化された SDN プログラムを介してネットワークリソースの設定、管理、安全性の確保、最適化の柔軟性を与える。さらに、彼らはこれらのプログラムを自分で書くことができ、ネットワークの真ん中にあるベンダのプロプライエタリでクローズドなソフトウェア環境に機能が組み込まれるのを待つ必要はない。

ネットワークを抽象化することに加えて、SDN アーキテクチャは一連の API をサポートしており、ルーティング、マルチキャスト、セキュリティ、アクセス制御、帯域幅管理、トラフィックエンジニアリング、サービス品質、プロセッサとストレージの最適化、エネルギー使用量、そしてビジネスの目的に合わせてカスタマイズされたあらゆる形態のポリシー管理を含む一般的なネットワークサービスの実装を可能にしている。例えば、SDN アーキテクチャはキャンパス内の有線と無線の両方の接続において一貫したポリシーを定義し、実施することを容易にする。

同様に、SDN はインテリジェントなオーケストレーションとプロビジョニングシステムを通してネットワーク全体を管理することを可能にする。Open Networking Foundation はマルチベンダ管理を促進するためにオープンAPIを研究しており、オンデマンドのリソース割り当て、セルフサービスプロビジョニング、真の仮想化ネットワーキング、セキュアなクラウドサービスへの扉を開いている。

このように、SDN の制御層とアプリケーション層の間のオープンAPI により、ビジネスアプリケーションはネットワークの抽象化された上で動作し、実装の詳細に縛られることなくネットワークサービスと機能を活用することができる。SDN はネットワークを “アプリケーションを意識したもの” ではなく “アプリケーションにカスタマイズされたもの” にし、アプリケーションを “ネットワークを意識したもの” ではなく “ネットワーク機能を意識したもの” にする。その結果、コンピューティング、ストレージ、ネットワークのリソースを最適化することができる。

オープンフローの内部

OpenFlow は SDN アーキテクチャの制御層と転送層の間で定義された最初の標準的な通信インターフェースである。OpenFlow はスイッチやルータのようなネットワークデバイスのフォワーディングプレーンへの直接アクセスと操作を可能にする。今日のネットワークデバイスがモノリシック、クローズド、そしてメインフレームのようなものであるという特徴付けにつながっているのは、フォワーディングプレーンへのオープンなインターフェースがないことだ。OpenFlow と同じことができる標準プロトコルは他になく、ネットワーク制御をネットワーキングスイッチから論理的に中央集権化された制御ソフトウェアに移すためには、OpenFlow のようなプロトコルが必要とされています。

SDN ユースケース

ONF は著名な企業やサービスプロバイダ、システムやアプリケーションの開発者、ソフトウェアやコンピュータの会社、半導体やネットワーキングのベンダによって指導されている。この通信とコンピューティング業界の多様な断面は SDN と関連する標準が市場の各セグメントにおけるネットワークオペレータのニーズに効果的に対応することを確実にするのに役立っている。

  • キャンパス – SDN の集中化された自動制御とプロビジョニングモデルはデータ、音声、ビデオのコンバージェンスをサポートし、IT が有線と無線の両方のインフラストラクチャに一貫してポリシーを適用できるようにすることで、いつでもどこでもアクセスできるようにする。同様に、SDN は個々のユーザープロファイルとアプリケーション要件によって決定されるネットワークリソースの自動プロビジョニングと管理をサポートし、企業の制約の中で最適なユーザー体験を保証する。
  • データセンター – SDN アーキテクチャはネットワークの仮想化を促進し、データセンターでのハイパースケーラビリティ、自動化された VM 移行、ストレージとのより緊密な統合、より良いサーバ利用率、より低いエネルギー消費、帯域幅の最適化を可能にします。
  • クラウド – プライベートクラウドやハイブリッドクラウド環境をサポートするために使われるかどうかに関わらず、SDN はネットワークリソースを非常に伸縮性のある方法で割り当てることを可能にし、クラウドサービスの迅速なプロビジョニングと外部のクラウドプロバイダへのより柔軟なハンドオフを可能にします。仮想ネットワークを安全に管理するツールがあれば、企業やビジネスユニットはますますクラウドサービスを信頼するようになるだろう。

ONFホワイトペーパー ソフトウェア定義ネットワーキング。ネットワークの新しい規範
OpenFlow は CPU の命令セットに例えることができます。図 2 に示されているように、プロトコルは CPU の命令セットがコンピュータシステムをプログラムするのと同じように、外部のソフトウェアアプリケーションがネットワークデバイスの転送プレーンをプログラムするために使用できる基本的なプリミティブを規定している。

OpenFlow プロトコルはネットワークインフラストラクチャデバイスと SDN コントロールソフトウェアの間のインターフェースの両側に実装されている。OpenFlow はフローの概念を使い、SDN コントロールソフトウェアによって静的または動的にプログラムされた事前に定義されたマッチルールに基づいてネットワークトラフィックを識別する。また、IT は使用パターン、アプリケーション、クラウドリソースのようなパラメータに基づいてネットワークデバイスを通過するトラフィックの流れを定義することができます。OpenFlow はネットワークをフロー毎にプログラムすることを可能にするので、OpenFlow ベースの SDN アーキテクチャは非常に細かい制御を提供し、ネットワークがアプリケーション、ユーザ、セッションレベルでのリアルタイムの変化に対応することを可能にする。現在の IP ベースのルーティングはこのレベルの制御を提供していない。なぜならば、二つのエンドポイント間のすべてのフローは、それらの異なる要件に関わらず、ネットワークを通る同じパスに従わなければならないからだ。

OpenFlow プロトコルはソフトウェア定義ネットワークのキーイネーブラーであり、ネットワークデバイスのフォワーディングプレーンを直接操作できる唯一の標準化された SDN プロトコルである。最初はイーサネットベースのネットワークに適用されていたが、OpenFlow スイッチングはより広範なユースケースに拡張することができる。OpenFlow ベースの SDN は物理的にも仮想的にも既存のネットワーク上にデプロイすることができる。ネットワークデバイスは従来のフォワーディングと同様に OpenFlow ベースのフォワーディングをサポートすることができ、企業やキャリアがマルチベンダのネットワーク環境であっても OpenFlow ベースの SDN テクノロジーを徐々に導入することを非常に簡単にしている。

Open Networking Foundation は OpenFlow を標準化するために設立され、プロトコル、コンフィギュレーション、相互運用性テスト、その他の活動を担当する技術的なワーキンググループを通して、異なるベンダのネットワークデバイスや制御ソフトウェア間の相互運用性を確保するのを支援しています。OpenFlow はインフラストラクチャベンダによって広く採用されており、彼らは通常シンプルなファームウェアやソフトウェアのアップグレードで実装している。OpenFlow ベースの SDN アーキテクチャは企業やキャリアの既存のインフラストラクチャとシームレスに統合し、SDN の機能を最も必要とするネットワークのセグメントにシンプルな移行パスを提供することができる。

OpenFlowベースのソフトウェア定義のメリット
ネットワーク

企業とキャリアにとって、SDN はネットワークを単なる避けて通れないコストセンターではなく、競争上の差別化要因とすることを可能にする。OpenFlow ベースの SDN テクノロジーは IT が今日のアプリケーションの高帯域幅、ダイナミックな性質に対処し、ネットワークを常に変化するビジネスニーズに適応させ、運用と管理の複雑さを大幅に削減することを可能にする。

企業やキャリアが OpenFlow ベースのSDN アーキテクチャを通して達成できる利益には以下のようなものがあります。

  • マルチベンダー環境の集中管理SDN コントロールソフトウェアはスイッチ、ルーター、仮想スイッチを含むあらゆるベンダーの OpenFlow 対応ネットワークデバイスをコントロールできる。個々のベンダのデバイスのグループを管理するのではなく、IT は SDN ベースのオーケストレーションと管理ツールを使ってネットワーク全体のデバイスを素早くデプロイ、設定、更新することができます。
  • 自動化により複雑さを軽減。OpenFlow ベースの SDN は柔軟なネットワークの自動化と管理フレームワークを提供し、今日手動で行われている多くの管理タスクを自動化するツールの開発を可能にする。これらの自動化ツールは運用上のオーバーヘッドを減らし、オペレータエラーによってもたらされるネットワークの不安定性を減らし、IT-as-a-Service やセルフサービスプロビジョニングモデルをサポートします。さらに、SDN を使えば、クラウドベースのアプリケーションはインテリジェントなオーケストレーションとプロビジョニングシステムによって管理され、ビジネスの俊敏性を高めながら運用上のオーバーヘッドをさらに減らすことができる。
  • 技術革新率が高い。SDN の採用は IT ネットワークの運用者が特定のビジネスニーズやユーザーの要求を満たすために文字通りリアルタイムでネットワークをプログラムし、再プログラムすることを可能にすることでビジネスの革新を加速させる。ネットワークインフラストラクチャを仮想化し、個々のネットワークサービスから抽象化することで、例えば SDN と OpenFlow は IT、そして潜在的にはユーザさえもネットワークの動作を調整し、新しいサービスやネットワーク機能を数時間のうちに導入する能力を与える。
  • ネットワークの信頼性とセキュリティが向上しました。SDN は IT が高レベルのコンフィギュレーションとポリシーを定義することを可能にし、それは OpenFlow を介してインフラストラクチャに変換される。OpenFlow ベースの SDN アーキテクチャはエンドポイント、サービス、アプリケーションが追加されたり移動されたり、ポリシーが変更されたりする度にネットワークデバイスを個別に設定する必要性を排除し、設定やポリシーの不一致によるネットワーク障害の可能性を減らす。SDN コントローラはネットワークの完全な可視性と制御を提供するので、アクセス制御、トラフィックエンジニアリング、サービス品質、セキュリティ、その他のポリシーが支店、キャンパス、データセンターを含む有線と無線のネットワークインフラストラクチャ全体で一貫して実施されていることを保証することができる。企業と通信事業者は、運用コストの削減、よりダイナミックな構成機能、エラーの減少、一貫した構成とポリシーの実施などのメリットを享受できます。
  • よりきめ細かなネットワーク制御。OpenFlowのフローベースの制御モデルは、高度に抽象化された自動化された方法で、セッション、ユーザー、デバイス、アプリケーションの各レベルを含む非常に細かいレベルでポリシーを適用することを可能にします。この制御により、クラウド事業者は、顧客が同じインフラストラクチャを共有する際に、トラフィックの分離、セキュリティ、弾力性のあるリソース管理を維持しながら、マルチテナンシーをサポートすることができます。
  • より良いユーザー体験。ベルのアプリケーションで利用可能にすることで、SDNインフラストラクチャは動的なユーザーのニーズにより良く適応することができる。例えば、キャリアはプレミアムな加入者に可能な限り最高の解像度を自動化された透過的な方法で提供するビデオサービスを導入することができる。今日、ユーザーは解像度の設定を明示的に選択しなければならず、それはネットワークがサポートできないかもしれないし、できないかもしれないが、その結果、遅延や中断が発生し、ユーザーの経験を低下させている。OpenFlow ベースの SDN では、ビデオアプリケーションはネットワークで利用可能な帯域幅をリアルタイムで検出し、それに応じてビデオの解像度を自動的に調整することができるようになります。

結論

ユーザーのモビリティ、サーバーの仮想化、IT-as-a-Service、ビジネス状況の変化に迅速に対応する必要性などのトレンドは、今日の従来のネットワーク・アーキテクチャでは対応できないネットワークへの大きな要求をもたらしています。Software-Defined Networking は、従来のネットワーク・バックボーンをリッチなサービス・デリバリー・プラットフォームに変換する、新しいダイナミックなネットワーク・アーキテクチャを提供します。

ネットワーク制御とデータプレーンを分離することで、OpenFlowベースの SDN アーキテクチャは基礎となるインフラストラクチャをそれを使用するアプリケーションから抽象化し、ネットワークがますます似てきているコンピュータインフラストラクチャと同じようにプログラマブルで管理可能なスケールになることを可能にします。SDN のアプローチはネットワークの仮想化を促進し、IT スタッフが共通のアプローチとツールセットでサーバ、アプリケーション、ストレージ、ネットワークを管理することを可能にします。キャリア環境であれ、企業のデータセンターやキャンパスであれ、SDN の採用はネットワークの管理性、スケーラビリティ、敏捷性を向上させることができる。

Open Networking Foundationはアプリケーション開発者、ソフトウェア会社、システムや半導体メーカー、コンピュータ会社、そして様々な種類のエンドユーザを含む大小のインフラストラクチャベンダーにまたがる SDN に関する活気あるエコシステムを育ててきた。OpenFlow スイッチングは SDN コントローラソフトウェアと同様に、物理的、仮想的の両方のインフラストラクチャの設計に既に組み込まれている。ネットワークサービスとビジネスアプリケーションは既に SDN コントローラとインターフェイスし、それらの間のより良い統合と調整を提供している。

ネットワークの未来はますますソフトウェアに依存するようになり、それはコンピューティングとストレージの領域でそうであったように、ネットワークのイノベーションのペースを加速させるだろう。SDN は今日の静的なネットワークを、リソースを動的に割り当てるためのインテリジェンス、巨大なデータセンターをサポートするためのスケール、そして動的で高度に自動化された安全なクラウド環境をサポートするために必要な仮想化を備えた柔軟でプログラム可能なプラットフォームに変えることを約束する。その多くの利点と驚くべき業界の勢いで、SDN はネットワークの新しい規範になりつつある。

 

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

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

続きを読む

SMB向けの重要なサイバーセキュリティeBook

前書き

近年、中小企業(SMB)を標的とするサイバー犯罪者は、SMB を悪用して破壊するための高度なテクノロジーとソーシャルエンジニアリング手法を使用してますます攻撃的になっています。中小企業へのサイバー攻撃は、データベースの消去、運用、財務、および評判の低下から、業務の麻痺および停止に至るまで、重大な被害を引き起こす可能性があります。今日、中小規模の組織で展開されている平均的なセキュリティソリューションは、攻撃者が最新の革新的な攻撃方法を定期的に使用する絶えず進化する脅威の状況に直面して不十分です。

小規模組織で働いている400人のサイバーセキュリティおよびITプロフェッショナルに対するEnterprise Strategy Group(ESG)の調査によると、過去2年間、回答者の3分の2が少なくとも1回のサイバーセキュリティインシデント(システムの侵害、マルウェアインシデント、DDoS標的型フィッシング攻撃、データ侵害など)を経験しました。回答者のほぼ半数(46%)がセキュリティインシデントが生産性の低下につながったと主張し、37%が攻撃によりビジネスアプリケーションまたはITシステムの可用性が混乱したと述べ、37%がビジネスプロセスが混乱したと述べました。

ESGのシニアプリンシパルアナリストであり、会社のサイバーセキュリティプラクティスの創設者は、「SMBの幹部が、中小企業がサイバー攻撃者にとって簡単な目印になることを認識する時が来ました。 犯罪者はSMBを標的にして金銭を強要したり、貴重なデータを盗んだりしますが、国家は中小企業を接続されたパートナーを攻撃するための先駆けとして使用します。」と信じています。

次の電子書籍は、SMBのセキュリティの基本、フレームワーク、SMBの推奨事項、およびSMBがサイバーセキュリティインシデントを防御および回復するのに役立つ方法論について概説しています。

SMB セキュリティの基礎

包括的なセキュリティプログラムは、中小企業が顧客、従業員、およびビジネスパートナーを獲得して維持するのに役立ちます。米国商務省の一部門である国立標準技術研究所(NIST)によると、顧客は、機密情報が盗難、開示、誤用などから保護されることを期待しています。顧客情報を保護することは、優れたカスタマーサービスであるだけでなく、ビジネスを大切にしていることを顧客に示します。

基本的なビジネスプラクティスとして、コンピューターのセキュリティは、SMBがセキュリティプログラムを実装する際に留意する必要がある3つのプロセス領域(情報セキュリティ、ネットワークセキュリティ、サイバーセキュリティ)に分類できます。

情報セキュリティー

情報セキュリティは、NISTによって「機密性、完全性、および可用性を提供するための不正アクセス、使用、開示、破壊、変更、または破壊からの情報および情報システムの保護」として定義されています。

情報セキュリティには、以下の保護に重点を置く人、プロセス、およびテクノロジーが含まれます。

  • トピック:守秘義務
    不正アクセスおよび開示から情報を保護します。
    例:盗まれたユーザー名、パスワード、またはクレジットカード情報。
  • トピック:整合性
    不正な変更から情報を保護します。
    例:給与情報または提案された製品設計が攻撃者によって変更されました。
  • トピック:可用性
    情報へのアクセス方法の混乱を防ぎます。
    例:あなたの銀行口座、顧客の情報にアクセスできません。または、あなたの顧客があなたのネットワークリソースにアクセスできません。

ネットワークセキュリティー

SANS Instituteは、ネットワークセキュリティを、不正なアクセス、誤用、誤動作、変更、破壊、または不適切な開示から基盤となるネットワーキングインフラストラクチャを保護する物理的およびソフトウェアの予防措置を講じ、それによりコンピュータ、ユーザー、およびプログラムが安全なプラットフォームを作成するプロセスと定義しています。安全な環境内で許可された重要な機能を実行します。

サイバーセキュリティ

そして最後に、NISTはサイバーセキュリティを「コンピュータ、電子通信システム、電子通信サービス、有線通信、および電子通信の損傷の防止、修復、およびそれらに含まれる情報を含む、それらの可用性、完全性、認証、機密性、否認防止」と定義しています。

SMB向けNISTサイバーセキュリティフレームワーク

NISTの出版物Small Business Information Security:The Fundamentalsは、サイバーセキュリティの経験がない中小企業のオーナー向けに書かれています。NISTガイドは、情報システムを保護するためにSMBが実行できる基本的な手順を説明し、重要インフラストラクチャサイバーセキュリティを向上させるためのNIST フレームワークに基づいています。

NIST Small Business Publicationでは、次の方法について説明しています。

  •  データと情報への従業員のアクセスを制限します。
  • 情報セキュリティについて従業員を訓練します。
  • 情報セキュリティのポリシーと手順を作成します。
  • データを暗号化します。
  • Webおよび電子メールフィルターをインストールします。
  • オペレーティングシステムとアプリケーションにパッチを適用するか、更新します。

NISTサイバーセキュリティフレームワークは、もともと重要なインフラストラクチャ組織のために特別に開発されましたが、NIST は、組織がサイバーセキュリティリスクを識別、評価、管理するのに役立つシンプルで共通の言語を備えている中小企業に役立つと考えています。

重要インフラストラクチャを改善するためのフレームワークサイバーセキュリティは、既存の標準、ガイドライン、および慣行に基づく自主的なガイダンスです。NISTによれば、「組織内外のコミュニケーションを改善するのに特に役立ちます。これは、以下の定義されている5つのフレームワークのコア機能を含んでいます。これらの関数は、シリアルパスを形成したり、静的な望ましい最終状態をもたらすことを意図していません。むしろ、機能を同時に継続的に実行して、動的なサイバーセキュリティリスクに対処する運用文化を形成することができます。」ということです。

NISTサイバーセキュリティフレームワークのコア機能の例

  • 機能:識別
    システム、資産、データ、機能に対するサイバーセキュリティリスクを管理するための組織の理解を深めます。ビジネスコンテキスト、重要な機能をサポートするリソース、および関連するサイバーセキュリティリスクを理解することで、組織は、リスク管理戦略とビジネスニーズに合わせて、取り組みに集中して優先順位を付けることができます。
    例:この関数内の結果カテゴリの例は次のとおりです。
    資産運用管理; ビジネス環境、ガバナンス、リスク評価、リスク管理戦略。
  • 機能:保護
    重要なインフラストラクチャサービスを確実に提供するための適切な保護手段を開発して実装します。保護機能は、潜在的なサイバーセキュリティイベントの影響を制限または封じ込める機能をサポートします。
    例:この関数内の結果カテゴリの例は次のとおりです。
    アクセス制御、意識とトレーニング、データセキュリティ、情報保護プロセスと手順、メンテナンス、保護技術。
  • 機能:検出
    サイバーセキュリティイベントの発生を特定するための適切なアクティビティを開発して実装します。検出機能により、サイバーセキュリティイベントをタイムリーに発見できます。
    例:この関数内の結果カテゴリの例は次のとおりです。
    異常とイベント、セキュリティ継続監視、および検出プロセス。
  • 機能:応答
    検出されたサイバーセキュリティイベントに関してアクションを実行するための適切なアクティビティを開発および実装します。応答機能は、潜在的なサイバーセキュリティイベントの影響を封じ込める機能をサポートします。
    例:この関数内の結果カテゴリの例は次のとおりです。
    対応計画、コミュニケーション、分析、緩和、改善。
  • 機能:回復
    レジリエンスの計画を維持し、サイバーセキュリティイベントによって障害が発生した機能やサービスを復元するための適切なアクティビティを開発して実装します。リカバリ機能は、通常の運用へのタイムリーなリカバリをサポートし、サイバーセキュリティインシデントによる影響を軽減します。
    例:この関数内の結果カテゴリの例は次のとおりです。
    復旧計画、改善、コミュニケーション。

SMBサイバーセキュリティチェックリスト

以下のイスラエル国立サイバー総局からの推奨事項は、SMBがITシステム、ビジネス情報、および顧客データを保護するために必要な基本的なビジネスプロセスの概要を示しています。

  1. 従業員の認識
    1. ソーシャルエンジニアリング攻撃、フィッシング詐欺、またはランサムウェア攻撃を防ぐには、従業員のサイバーセキュリティ教育への投資が不可欠です。サイバー攻撃はソーシャルエンジニアリングと人間の弱点に大きく依存しているため、エンドユーザーは、マルウェアが他のコンピューターに拡散するなどの方法で操作される可能性があります。ITセキュリティの意識について従業員を教育する人材と連携したトレーニングプログラムは、サイバー攻撃を防ぐための重要な要素です。
  2. 情報資産マッピングとリスク調査
    1. ITリソースマッピングとリック調査プロセスは、組織のIT資産、ネットワークトポロジ、およびコンピューティングリソースに対する既存のリスクを、オンプレミスまたはクラウドの両方で特定します。組織内外のIT セキュリティ専門家の支援により、既知の脅威、システムの弱点、および既存のセキュリティ対策の分析は、リスクを軽減するために組織のセキュリティアーキテクチャ、ポリシー、およびプログラムに影響を与える上で重要です。
  3. ライセンスソフトウェア
    1. ライセンスソフトウェアを使用すると、秩序だったセキュリティ更新プロセスが保証されます。ライセンスされていないソフトウェアや海賊版ソフトウェアを使用することは攻撃者にとって魅力的な機会です。これには、ビジネスアプリケーションの最新のセキュリティ更新がなければ脆弱性が悪用される可能性もあります。
  4. ウイルス対策ソフトウェア
    1. ビジネスコンピュータまたはモバイルデバイスにローカルにインストールされたウイルス対策ソフトウェアは、脅威を特定し、コンピュータウイルスを隔離および排除します。攻撃者がコンピューティングリソースやネットワークリソースにアクセスできないように、ウイルス対策ソフトウェアを頻繁に(少なくとも1日に1回)更新する必要があります。
  5. ソフトウェアの更新
    1. IT管理者は、すべての内部ソフトウェアとクラウドリソースに対して定期的な自動更新が行われるようにする必要があります。これは、Microsoft Office 365などの定期的に使用されるパーソナルコンピューティングおよびモバイルデバイスのオペレーティングシステムとソフトウェアにとって特に重要であり、ソフトウェアの脆弱性を悪用する潜在的な攻撃者の能力が低下します。
  6. 強力な識別パスワードと、数回の識別試行の失敗後のロック
    1. 最も一般的な攻撃方法の1つは、パスワードの推測とパスワードの解読です。攻撃プロセス中に、攻撃者は正しいものを推測するために数百万の可能なパスワードのパスワードディクショナリを実行します。単純なパスワードを使用すると、簡単に推測してコンピューティングシステムにアクセスできます。数字、大文字と小文字の文字、特殊記号で構成された、推測しにくい長いパスワードを使用することをお勧めします。 2要素認証を使用すると、電子メールフィッシングなどによるパスワードを盗もうとする試みに対する別のセキュリティ層が提供されます。
  7. 情報を暗号化してビジネス情報とクライアントデータを隠す
    1. 暗号化は、HTTPS、安全なプロトコル、データセンターサーバー、企業のコンピューティングデバイスなどのプロトコルを使用して、転送中または保管中の不正アクセスからデータを保護します。ITスタッフまたはサードパーティのソフトウェアサプライヤーによる暗号化の適切な使用を保証するには、ユーザーデータ、暗号化キー、およびネットワークセキュリティを管理する必要があります。
  8. バックアップとリカバリ
    1.  適切なバックアッププロセスにより、さまざまなサイバー攻撃からのリカバリが可能に。
    2. たとえば、ランサムウェア攻撃中に、マルウェアは特定のコンピューター上の情報を暗号化したり、組織のネットワーク全体で人質データを暗号化して保持したりする可能性があります。この場合、更新されたバックアップを介して感染時から情報を復元できるため、ビジネスへのさらなる害を防ぐことができます。バックアップ方法には、ローカルバックアップ、クラウドバックアップ、物理的なドキュメントコピーの印刷などがあります。トリプルバックアップを使用して、初期または二次バックアッププロセス中のデータ損失を最小限に抑えることができます。
      バックアップは、組織の重要な情報を含む外付けドライブまたはテープドライブを使用して実行できます。さらに、情報資産のマッピングは、ビジネスの重要な情報を識別して特定するのに役立ちます。災害やマルウェアの攻撃が発生した場合にビジネスが移行する代替サイトにバックアップを作成することもできます。バックアップ戦略は、ビジネスの固有の性質、ビジネス継続性に必要なデータの範囲、およびさまざまなバックアップソリューションに投資するビジネスの能力に応じて選択されます。
  9. ワイヤレスネットワーク
    1.  従業員とクライアントにワイヤレスネットワークアクセスを提供する場合は、セキュリティリスクを軽減するために、以下のベストプラクティスに従うことをお勧めします。
    2. クライアントまたはインターネットサービスを使用するクライアントがビジネスのプライベートネットワークへの不正アクセスを取得できないように、2つの個別のワイヤレスネットワークを確立します。
    3. 暗号化– 現時点で利用可能な最も強力なワイヤレス暗号化であるWPA2を使用します。
    4. パスワード–長くて複雑なネットワークパスワードを使用し、定期的に変更します。
    5. MACアドレスファームウェア– ホワイトリストフィルターなど、ワイヤレスルーターに接続するMACアドレスを可能な限り強化します。
    6. ネットワークのサービスセット識別子(SSID)を隠します– ネットワークの名前を隠し、エリア内のワイヤレスネットワークを調査しているユーザーに公開されないようにします。
    7. ルーターの管理– ネットワークルーターを管理するためのデフォルトのパスワードを変更します。
    8. ワイヤレスキーボード、ワイヤレスマウス、ワイヤレスプリンターなどのデバイスのワイヤレスセキュリティを確認します。
  10. サイバーセキュリティ保険
    1. 現在市場に出回っている既存のすべてのセキュリティソリューションにもかかわらず、サイバー攻撃は依然としてビジネスに経済的損害を与える可能性があります。攻撃の成功による金銭的被害を最小限に抑える重要な方法は、サイバーセキュリティ保険を購入することです。サイバーセキュリティ保険は、攻撃者が企業に金銭的損害を与えた場合に補償を受ける資格を得るように、企業に基本的なサイバーセキュリティ保護を実装することを要求します。

中小企業向けのクラウドVPN

前述のイスラエル国営サイバー総局の推奨事項に加えて、すべてのSMBは、クラウドVPNをセキュリティ戦略に組み込んで、ネットワークのセキュリティを迅速に高め、データを「送信中」および「保管中」に保護し、暗号化とユーザーアクセス制御を提供する必要があります。 、GDPR、SOC 2、HIPAA、ISO 27001および27002を含むコンプライアンス要件を満たします。

現在、多くのSMBは、企業または従業員所有のWindows、iOS、Mac OS、およびAndroidデバイスを介してアクセスされるOffice 365、AWSまたはSalesforce CRM などのクラウドベースの生産性アプリケーションに依存するさまざまなグローバルオフィスに拠点を置く従業員を抱えています。従業員が自宅や旅行で仕事をするにつれて、リモート接続も重要になっています。安全なWi-Fiホットスポットまたは地理的制限とオンライン検閲によってゲート制御されたパブリックネットワークを介して企業ネットワークにアクセスするビジネスのために、従業員が自宅または出張で仕事をするとき、リモート接続も重要になっています。

ITマネージャーの課題は、ITリソースと予算を使い果たすことなく、安全で信頼できる従業員アクセスを提供することです。従来のVPNは、ハードウェアとソフトウェアの両方の観点から、展開と保守が複雑になる場合があります。これには、物理サーバーとサイト固有のアプリケーション、クラウドベースのインフラストラクチャとアプリケーション、およびIDアクセスと管理の統合が含まれます。したがって、IT管理者は、従来のVPNを超えて、ソフトウェア定義の境界構成で迅速に展開および構成できるクラウドベースのVPNを検討する必要があります。

Perimeter 81ソリューション

Perimeter 81は、SMBにクラウドベースの高度なVPNソリューションを提供し、オンプレミスおよびクラウドリソースへのアクセスを迅速かつ簡単に保護し、従業員アクセスのための軽量のクロスプラットフォームクライアントアプリケーションサポートを提供し、すべてが単一の管理コンソールで制御されます。ソフトウェア定義の境界セキュリティモデルを利用するPerimeter 81のクラウドVPN は、VPNエンドポイントのシームレスな展開を可能にし、デバイス認証、IDベースのアクセス、およびすべてのユーザーに動的にプロビジョニングされる接続を組み合わせたクラウドベースのインフラストラクチャにより、高価なハードウェアを排除します。

モバイル従業員は、Windows、Mac、iPhone、Androidデバイスで使用できるPerimeter 81のシングルサインオンネイティブクライアントアプリケーションで保護されています。Perimeter 81の革新的な自動Wi-Fiセキュリティは、従業員が不明または信頼できないネットワークに接続したときにVPN 保護を自動的にアクティブにすることで、すべてのデータを保護します。

中央制御とID 81 管理がPerimeter 81ポータルに統合されているため、安全なポリシーベースのリソースアクセスにより、従業員とグループを企業ネットワークリソースとクラウド環境に簡単に追加できます。詳細なアクティビティレポートは、リソースと帯域幅の使用状況に関する洞察を提供し、アクティブな接続とセッションの情報を監視できます。

最後に、あらゆるネットワークを通過するすべての企業データは、256ビットの銀行レベルの暗号化で保護され、企業の実際のIPアドレスをIPマスクで隠す専用プライベートサーバーを介してルーティングされます。Perimeter 81の34か所以上にある700を超える高速パブリックサーバーのグローバルネットワークは、プライベートVPNサーバーと専用IPアドレスの迅速かつ簡単な展開を提供します。

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

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

続きを読む