このパターンは「レガシーシステム置換のパターン」の一部です
プロダクトラインの抽出
プロダクトラインごとにシステムを識別し、分離します。
2021年7月21日
多くのアプリケーションは、同じ物理システムから複数の論理的な製品を提供するために構築されています。多くの場合、これは再利用への欲求によって推進されます。「ふむ、消費者向けローンは事業者向けローンとよく似ているな」とか「衣料品は製品だし、オーダーメイドのカーテンもそうだし、どこが違うんだ？」という具合です。私たちが出会う大きな問題は、表面上は製品が似ているように見えても、詳細になると大きく異なることです。
時間の経過とともに、複数の製品を提供する単一のシステムは過度に汎用的になり、コードは可能なすべての製品のすべての可能な組み合わせを処理するように進化する可能性があります。たとえば、n個の製品を処理するように設計された汎用システムで、製品ごとにn個の変更がある場合、すべての可能な組み合わせをチェックするために実行する必要があるテストの量はnの階乗になります。これはすぐに大きくなる数字です。また、著者が遭遇したこのタイプのアプリケーションの多くが、自動テストカバレッジが非常に少なく、代わりに大規模で多くの場合手動のリグレッションスイートに依存していた理由も説明できます。非常に多くの異なるコードパスをテストすることは不可能です。
したがって、問題は経済性の問題であることが多いのです。製品ごとにシステムを開発および保守する方が、単一のシステムを開発および保守するよりも経済的に優れている可能性があるという事実を受け入れることは困難です。製品ごとに分割することにより、複数の製品への変更を同時に行うことができ、不要な場所に欠陥を導入する可能性のある変更の組み合わせの爆発を回避することでリスクを軽減できるという事実を利用しています。
もちろん、これはトレードオフです。赤いズボンと黒いズボンで別々のアプリケーションは必要ありませんが、既製品とオーダーメイド、または住宅保険とペット保険で別のアプリケーションが必要になる場合があります。
バリューストリームの抽出で説明されているように、異なるプロダクトラインが非常に異なるバリューストリームを持っていることも一般的です。
仕組み
システム内の製品またはプロダクトラインを特定します。これは、構築/移行する薄いスライスを形成します。既存のシステムが提供するすべての機能を特定し、それらを新しい製品にマッピングします。機能を特定する際には、データ、プロセス、ユーザーなど、さまざまな観点から検討する傾向があります。
共有機能を特定します。異なるプロダクトラインが共有されているビジネス機能を持っているかどうかを特定します。これにアプローチする方法はいくつかあり、「ビジネス機能の理解」で説明します。いつものように、再利用よりも使用を重視することをお勧めします。そのため、迷った場合は、共有機能の数をできるだけ制限するようにしてください。
誰を最初にするかを選択します。どのプロダクトラインから最初に移行しますか？私たちが好むアプローチの1つは、リスクの観点から考えることです。移行によるビジネスへのリスクを理解した後、*2番目にリスクの高いプロダクトライン*を選択することがよくあります。これは直観に反するように感じるかもしれませんし、最初に最もリスクの低いオプションを選択すべきだと思うかもしれませんが、実際には、ビジネスの注意を引き付け、資金調達を優先させるのに十分なほどの規模でありながら、問題が発生した場合にビジネスが失敗するほどリスクが高くない製品を特定したいのです。
ターゲットのソフトウェアアーキテクチャを特定します。この場合、すべての製品のソフトウェアを一度に構築することを意味するビッグバン置換を推奨することは非常にまれです。代わりに、ステップ1で特定された薄いスライスに適したアーキテクチャを特定することを検討してください。
技術的な移行戦略を特定します。テクノロジー移行パターンのセクションで説明するように、現在の制約に応じて展開できるさまざまなオプションがあります。単純なWebアプリケーションの場合は、ForkByUrlを使用できる可能性があります。ForkingOnIngressが適切な場合は、MessageRouterパターンを選択する方が適切な場合があります。移行アーキテクチャが必要になる可能性があることに注意してください。
いつ使うか
次のメリットがある、簡単に識別できるプロダクトラインを持つシステムがあります。
- 独立して作業できること。システムを個別の製品に分割することは、個々の製品を中心にチームを形成し、マージ地獄や長いリグレッションサイクルなどの変更調整の典型的な問題なしに進捗を可能にすることを意味します。
- 異なる非機能的な特性を持っていること。製品ごとに異なるSLOを提供できるようにしたいと考えています。たとえば、特定のレイテンシーに対して異なる負荷要件などです。
- 異なる変更率。一部のプロダクトラインは安定しており、他のプロダクトは活発な開発が行われています。システムを分割するということは、安定した製品への変更のリスクを負わないことを意味します。
保険の例
保険の分野では、異なる製品タイプは非常に異なる特性を持っています。たとえば、自動車保険は通常、高量ですが低利益であり、一方、住宅保険はその逆です。また、競争が激しいため、迅速に変更を加える能力が非常に重要です。私たちが協力したある保険会社は、図1に示すように、自動車、生命、住宅、ペットのラインを含む、保険会社が提供するすべての異なる製品の見積もりエンジンとして機能する3層アーキテクチャを開発しました。
達成したい結果を理解する
ビジネスの製品オーナーは、リードタイムが長く、ますます長くなっているため、変更に不満を募らせていました。彼らはThoughtworksに連絡し、アーキテクチャと開発プロセスを調べて、状況がなぜそれほど悪いのかを特定できるかどうかを確認することにしました。開発プロセスのバリューストリームマップは、リードタイムが急増する原因となっている多くの制約を特定しました。各技術ドメインは他のドメインから分離されていましたが、異なるビジネスドメインは密接に結合していました。これは、自動車製品の新しい要件を追加すると、住宅、生命保険などにも影響を与えることがよくあることを意味します。これらの変更には、慎重な検討と広範なリグレッションテストが必要でした。また、複数製品アーキテクチャは、コードベースで安全に作業できる人の数を制限し、進捗をさらに遅らせました。
最後に、自動車製品ラインのボリューム要件とビジネスの成長により、基盤となるデータストアを頻繁に拡張する必要があり、システムがホストする他のすべての製品がダウンタイムを必要としました。
問題をより小さな部分に分解する方法を決定する
その結果、保険会社は、技術的機能を中心に編成されたn層アーキテクチャから、プロダクトラインによって編成されたアーキテクチャへの移行を決定しました。製品はすでに特定されていました。自動車、住宅、生命保険、ペット保険です。これらを理解すると、個々の質問セット、見積もり、顧客アカウント、および認証や認可などのより技術的な機能など、それぞれが必要とするさまざまな機能が特定されました。顧客アカウントは、すべてのプロダクトラインが使用する主要な共有機能として特定され、EAマジッククアドラントの調整アプローチを採用する良い例となりました。
次に必要だったのは、どこから始めるかを特定することでした。会社の収益順に、プロダクトラインは自動車、住宅、生命保険、ペット保険と評価されました。一方、顧客数では順序が逆でした。その結果、住宅保険が最初に個別に実装されるプロダクトラインとなることが決定しました。これは、何か問題が発生した場合のビジネスへのリスクと、選択を重要にするのに十分な収益とのバランスがとれていました。
部分を正常に配信する
上の図は、チームが構築を開始したイベント駆動型アーキテクチャを示しています。見積もりエンジンや顧客管理機能との通信は、RabbitMQメッセージバスを介して渡されるイベントを介して行われました。これらのイベントは、レポート目的で既存のエンタープライズデータウェアハウスにも伝播されました。
チームが既存システムの横に新しいシステムを構築していくにつれて、レガシーシステムから新しいシステムにトラフィックを切り替える準備が整えられました。製品ライン全体を移行することの1つの欠点は、顧客を切り替える前に質問セットを完全に実装する必要があったことです。この制約のため、新しいシステムはベータフェーズに入り、一部の顧客にはベータ版を使用するオプションが提供されました。オプトインした人は、新しい外観と使い心地に関するフィードバックを提供する機会もありました。新しいシステムが段階的に強化され、最終的な外観上の機能が追加されるにつれて、ゴー・ノーゴーの決定が下され、数週間かけて顧客が新しいシステムに徐々にリダイレクトされました。最初は1％、次に5％、そして10％というように。これにより、チームとビジネスは、新しいシステムが機能面と非機能面の両方で期待どおりに動作しているという確信を深めることができました。最終的に、新しいシステムは住宅保険のトラフィックの100％を処理しました。その後、チームは継続的な製品開発に取り組みました。
継続的にこれが発生するように組織を変更する
最初の移行の成功後、次の課題である車両保険の移行に注意が向けられました。同じアプローチが使用され、移行が完了して古いシステムが停止するまでパターンが繰り返されました。
その間、組織全体は徐々にプロジェクトベースの開発から製品中心の開発へと移行しました。もちろん、これには初期の問題がありました。プロダクトオーナーシップは時間をかけて構築する必要があるスキルであり、移行は徐々に行われました。また、従来のIT運用にも同じアプローチを採用し、CTOとチーフアーキテクトの指導の下、オンデマンドインフラストラクチャ、そしてデータと分析のためのプラットフォーム製品エンジニアリングのアプローチへと移行しました。
重要な修正
2021年7月21日