アーキテクチャにおける盲点

バリューストリームマッピングを用いてアーキテクチャを検証する

アーキテクチャのビジネス価値を評価するための最初の良いステップは、ITランドスケープのさまざまなシステムとコンポーネントに焦点を当てたバリューストリームマッピングを行うことです。ビジネスはしばしば、ビジネスプロセスのための何らかのバリューストリームマッピングを行い、カスタマージャーニーの各部分が収益とマージンにどのように影響するかを調べますが、多くの場合、ITに到達するとマッピングは停止し、さまざまなシステムを通じてバリューストリームをマッピングしようとする試みは行われません。

アーキテクトはこれを基に、マッピングをそれらのシステムに拡張することにより、ビジネスプロセスをサポートするシステムに同様のビジネス指標を割り当てる必要があります。財務指標と同様に、重要な非財務指標も検討できます。顧客がオンラインで請求状況を確認できることは、顧客維持にどの程度影響しますか？（このような測定は通常、より困難ですが、測定方法について考えることで、しばしば重要な洞察が得られます。）

最近のクライアントでは、顧客がクライアント企業とどのように対話するかを説明するカスタマージャーニーから始めて、このような演習を行いました。私たちはこれらの手順をチームルームの壁の最上部に配置し、各手順をクライアントのITポートフォリオのシステムとコンポーネントに結び付けました。その後、各システムがカスタマージャーニーの手順にどのように貢献し、障害の影響がどうなるかを評価できました。

障害のビジネス価値への影響を考慮する

最初の例で示唆したように、障害の影響を評価することになると、特に重要です。システムの耐障害性を向上させるための対策を講じたい場合は、障害が発生した場合のリスクのある価値の観点から表現することをお勧めします。ある小売業者は、在庫データベースのバックアップ復元プロセスをテストすることを正当化しようと苦労していました。クリスマスシーズン前に必要なビジネスに見える機能の大きなバックログがあり、このような技術的なタスクの優先順位を付けるのは困難でした。私たちの提案は、ブラックフライデーのデータベースクラッシュについてビジネスがどのように感じているかを尋ねることでした。コストはどれくらいか、システムをどれくらい早くバックアップしたいか？これらの質問は、データベース復元のドレスリハーサルを行い、そうでなければITの作業キューに埋もれてしまう回復時間を短縮するという、ビジネス主導の決定につながりました。

リスクにさらされる価値の評価を行う場合は、2つの補完的な方法でアプローチする価値があります。1つのルートはトップダウンで、ビジネス機能を見て、その機能をサポートするソフトウェアシステムを特定することです。もう1つは逆で、ソフトウェアシステムから始めて、ここでの障害がどのような影響を与えるかを検討することです。

リスクにさらされる価値を分析する重要な部分は、さまざまな障害がさまざまな深刻な結果をもたらすため、すべてのソフトウェアコンポーネントが同じレベルの耐障害性を必要とするわけではないことを認識することです。ボクシングデー（ブラックフライデーに相当する英国）の在庫管理システムの障害を想像してみてください。それが在庫レベルを確認できないことを意味する場合、私たち は、満たすことができない注文を確認するか、注文を受けないかのいずれかです。どちらも大きな損失を引き起こします。ただし、フルフィルメントシステムに障害が発生すると、処理を待機しているキューに注文が置かれる可能性があり、配信が遅れる可能性があります。ビジネスリーダーは後者をそれほど懸念していないと考えるかもしれず、したがって、そのシステムの耐障害性が低くても構わないと思っています。詳細がどうであれ、重要なのは、耐障害性のレベルはビジネス上の決定であるということです。データの整合性も同様です。分散データベースを見ると、アーキテクトは可用性のために整合性を緩めることに躊躇することがよくあります。しかし、ホテルの部屋を二重に予約することのビジネスコストは、予約をまったく取らないことよりもはるかに心配が少ないかもしれません。CAP定理に enshrinedされている整合性と可用性のトレードオフは、技術的な決定ではなく、ビジネス上の決定です。

横断的要件はビジネス価値によって正当化されるべきである

ここでのテーマは、機能の価値だけでなく、多くの場合、横断的要件（非機能要件、または「ilities」の推奨名）として分類されるシステム特性の価値も評価する必要があるということです。システムに何らかの技術標準を順守させたい場合は、それを怠ることによって失われる価値を理解し、その価値を非技術的な利害関係者に伝える必要があります。CFRの価値を評価することはしばしば困難であり、多くの技術者は結果として生じる議論を避けます。しかし、これを怠ると、低価値のテクノロジーに過剰投資するリスクだけでなく、より多くの害を及ぼします。また、技術者とユーザーのコラボレーションに真の障壁を erectedます。

価値を理解することは、コンポーネントの柔軟性に関する決定に役立つはずです。あるクライアントには、特定の決済処理会社と連携するようにプログラムされた決済処理コンポーネントがありました。彼らは、決済処理業者が変更された場合に迅速に調整できるように、簡単に設定できるようにしたいと考えていました。2つの大きな選択肢がありました。1つは、決済処理コンポーネントで決済プロバイダーのシステムとの相互作用をハードコーディングする一方で、もう1つのオプションは、そのようなすべての相互作用を設定可能にすることです。設定可能なオプションを使用すると、構成ファイルを数日で変更することで、決済プロバイダーを変更できます。ただし、通常の場合と同様に、このような設定可能性は、他の変更のコストを増加させるコンポーネントのコードに複雑さを追加します。これは、設定可能性における一般的なトレードオフです。設定可能なビットの変更を容易にすることで、他の場所での変更が難しくなります。ここでのビジネスコンテキストの重要な部分は、決済プロバイダーを変更する際の難しい部分は、実際には新しい法的契約を交渉することであったということです。これは通常、完了するまでに1年以上かかる演習です。そのため、設定不可能なコンポーネントを変更する方が法的交渉よりもはるかに高速であるため、ここでプロバイダー情報を設定する価値はありませんでした。

ビジネス価値は、コンポーネントによってCFRが異なることを意味する

最後の2つの例はどちらも、耐障害性や柔軟性などに「万能」アプローチをとることが役に立たず、無駄になる可能性があることを示しています。数年前、私たちは、包括的な「ファイブナイン」の可用性要件を課すことを決定した組織と協力しました。驚くべきことに、彼らはこれをスタッフがお気に入りのランチタイムスナックを予約するために使用するサンドイッチ注文システムにも適用しました。たとえば、サービスの損失が顧客体験や収益にすぐに影響を与えるか、データベースが復元されている間、数時間ダウンしても大丈夫かなど、ビジネスでさまざまなサービス階層に同意することは非常に役立つことがわかりましたか？

システムがビジネス価値をどのようにサポートしているかを理解することで強調できるもう1つの問題は、単一のコンポーネントが複数の異なる価値の流れと信頼性のレベルをサポートする必要がある場合です。これは、複数の異なるビジネスプロセスがサポートされているモノリシックコンポーネントでは一般的であり、対応するビジネス価値によって正当化される場合にのみ高可用性のプレミアムを支払うことができるようにするなど、物事を分割するための重要な動機となる可能性があります

監視を使用してビジネス価値を評価する

私たちは、システムの振る舞いをより深く理解するために、リッチモニタリングを活用することを強く推奨しています。これは、分散システムの複雑さが増大するにつれて特に重要になっています。このようなモニタリングは、多くの場合システムの健全性に焦点を当て、本番環境でのQAをサポートします。しかし、この種のモニタリングは、システムがビジネス価値にどれだけ貢献しているかを評価するためにも使用できます。たとえば、特定のコンポーネントを介してどれだけの売上収益が発生しているかを判断するなどです。ある小売業のお客様は、メインフレームのキューの長さとメッセージレートを監視することが、各店舗の収益を測る適切な代替手段になることを発見しました。正確ではないものの、この情報をビジネス関係者に提供することで、純粋に技術的な観点からの監視では見逃されていた可能性のある問題を特定することができました。別のお客様は、Webサイト上のすべてのトランザクションについて正確な収益を算出し、オフィス周辺の画面に毎分表示することができました。時間の経過とともに、CPU、メモリ、その他の技術的指標を表示する画面よりも、これらの画面の方がはるかに注目されるようになりました。

このようなデータの収集はシステムの振る舞いを理解する一部ではないと主張する人もいるかもしれませんが、私たちは、これがソフトウェアコンポーネントがビジネスに貢献する上で不可欠な情報であると断言します。クラウドでホストされるシステムが増えるにつれて、個々のFaaS関数に対して生成される請求書を確認できます。この粒度でコストを取得できる場合は、メリットに関するデータの収集にも努める必要があります。

定期的なモニタリングデータは、それ自体で投資判断の材料となります。私たちは、Webサイトを通じて市民にサービスを提供している政府機関に出会いました。Webアプリケーションに新しい機能を追加するためのコストは、アップグレードできない市民のために必須とされていた古いブラウザをサポートするためのコストによって大幅に増加していました。トラフィックを調べた結果、そのような古いブラウザを使用している市民は非常に少ないため、古いブラウザをサポートするよりも、新しいコンピュータと花束を提供する方が安価であることがわかりました。

クラウドに移行する場合は、価値のある部分だけを移行する

クラウドシステムの台頭により、多くの組織がソフトウェアシステムをクラウドホスティングに移行することを希望しています。これは、企業が既存のシステムを、同じ機能をサポートするが、より現代的な（そしてうまくいけばより効率的な）インフラストラクチャ上で動作するものに置き換えようとする、システム置換の長い歴史と軌を一にしています。私たちは、数十年にわたりこのような取り組みを見てきた中で、犯しやすい間違いがあることを知っています。おそらく最も一般的なのは、システム置換を行う最も簡単な方法は、新しいプラットフォーム上で既存の機能を正確に模倣しようとする、機能パリティ置換であるという考え方です。このような同等の置換アプローチは、既存の機能の多くは価値が低く、一部はまったく使用されておらず、一部は最適なビジネスプロセスを積極的に妨げているという事実を見落としています。機能パリティ置換は、人々が通常考えるよりも難しく、使用頻度の低い機能のコピーを回避するために時間をかけることは、容易に元が取れます。

私たちが協力したある組織は、物流処理コードの100％を新しいシステムに移行することから移行作業を開始しました。これには数か月かかり、多くの開発スタッフが関わりました。彼らの将来の計画についてビジネスに話を聞いたところ、彼らは高いコストのために多くの種類のパッケージのサポートを中止する予定であると説明しました。パッケージに関するすべてのエッジケースへの対処は、移行に最も時間を費やすものでしたが、ビジネスはそれがなくても満足していたでしょう。

したがって、ビジネス価値への貢献を理解することは、より良いリプラットフォーム化の取り組みを行う方法を特定する上で大きな助けとなります。既存のコンポーネントがあまり価値を生み出していない場合は、新しいプラットフォームにコピーすべきではありません。ここでの一般的なケースは、サービスのほとんどがいくつかの一般的なケースに従っているが、まれにしか発生しない珍しいサービスをいくつか提供しているサービス会社です。このような珍しいケースには、多くの場合特別なソフトウェアサポートが必要ですが、このような限界的なケースは、新しいプラットフォームに再実装する前に必ずレビューする必要があります。ビジネスが今後6か月以内にこのサービスの提供を停止する予定がある場合は、再実装計画の一環として理解しておくべきことです。

ビジネス価値は重要だが、不変ではない

人生やソフトウェアアーキテクチャにおけるあらゆるものと同様に、このような価値の評価は一定ではありません。私たちは、評価モデルを通じて競争上の優位性を持っていた保険会社と協力しました。このソフトウェアは、同社の至宝の1つと見なされていました。しかし、時間の経過とともに、ストレートスルー処理によるオンラインでの保険見積もりが大きくシフトしました。この至宝には多くのパラメータが必要でしたが、これはオンライン以前の時代には、エージェントが顧客と面会することで合理的に取得できましたが、複雑なフォームはWeb上ではあまりにも魅力的ではありませんでした。この変化により、彼らの至宝の価値は薄れていきました。そのため、ソフトウェア資産の現在の価値を理解するだけでなく、技術環境とビジネス環境の変化によってその価値がどのように影響を受けるかを大まかに予測してみる価値があります。

別のケースは、カタログ管理システムが年に2回の更新には問題なく対応できていましたが、急速なオンライン変更への対応ができなかった小売業者です。収益の損失による機会費用を定量化することは決して容易ではありませんが、コンポーネントの再構築または書き換えに投資する場所を決定する際には、考慮する必要があります。

ビジネス知識は、技術的なキャリアパスの一部であるべきである

人々が技術リーダーの成長を見るとき、ほとんどの注目は「ハード」な技術的なテーマに向けられます。さまざまなソフトウェアプラットフォーム向けのトレーニングコース（認定済み）はたくさんあります。技術スキルの開発には、今日の一般的なプラットフォームではなく、コアとなる原則に焦点を当てたトレーニングを推奨します。「ソフト」スキル（皮肉な引用符に注意してください）のはるかに難しい分野は、人々がリーダーシップのはしごを登るにつれてますます重要になることを賢明なスキル開発は認識しており、それは私たちも支持していることです。[1]

これらのことは貴重ですが、技術リーダーが、自分たちが活動するビジネスと、その分野のさまざまなプレーヤーによってどのように価値が生み出されるかをしっかりと理解していることを確認することも不可欠だと考えています。これは通常、トレーニングコースでは得られないものであり、むしろビジネスリーダーとの定期的な交流を通じて得られるものです。この社会的交流は、技術者のキャリアの早い段階で始めるべきです。ITスタッフとビジネススタッフを分離することが、ソフトウェアがサポートする企業の活動にどれほど深く関わっているかによって価値が決まるソフトウェア開発のような職業に計り知れない弊害をもたらすという考えです。開発者は、ユーザーや顧客との継続的な接触が正常であることを早期に学び、それをうまく行う方法を学ぶ必要があります。長年のこのような接触は、彼らがリーダーになり、一緒に成長してきたビジネスの人々に精通しているときに大きな成果をもたらします。