架構中的大象

使用價值串流對應來檢視架構

評估架構中業務價值的良好第一步是進行價值流對應，重點放在 IT 環境中的各種系統和元件。企業通常會對業務流程進行某種價值流對應，檢查客戶旅程的每個部分如何影響收益和利潤，但通常在他們接觸到 IT 時，對應就會停止，並且不會嘗試對應各種系統中的價值流。

架構師應該以此為基礎，將類似的業務措施分配給支援業務流程的系統，方法是將對應延伸到這些系統中。除了財務措施之外，也可以查看重要的非財務措施 - 您的客戶線上查看其理賠狀態的能力在多大程度上會影響客戶保留率？（此類措施通常較難制定，但思考如何衡量它們通常可以產生重要的見解。）

我們最近與一位客戶進行了這樣的練習，從描述客戶如何與客戶公司互動的客戶旅程開始。我們將這些步驟放在團隊會議室牆壁的頂部，然後將每個步驟與客戶 IT 組合中的系統和元件連結起來。然後，我們可以評估每個系統如何促成客戶旅程中的步驟，以及故障的影響可能為何。

考量故障對業務價值的影響

正如我們的第 1 個範例所建議的，在評估故障後果時，特別重要。如果我們要採取措施來提高系統的復原力，最好根據故障時面臨的風險來表達。一位零售商正在努力證明測試其庫存資料庫的備份還原流程是合理的。由於在聖誕節季之前需要大量商業可見功能，因此很難優先考慮這種技術任務。我們的建議是詢問企業對黑色星期五資料庫崩潰有何看法：成本是多少，他們希望系統多快備份？這些問題促使企業做出有關資料庫還原彩排的決策，並縮短了原本會埋沒在 IT 工作佇列中的復原時間。

在評估面臨風險的價值時，值得採用兩種互補的方式來進行。一條路徑是自上而下，查看業務功能並找出支援該功能的軟體系統。另一種是相反的方式，從軟體系統開始，並考慮此處的故障會產生什麼影響。

分析風險價值時，一個重要的部分是了解，由於不同的故障會造成不同程度的嚴重後果，所有 軟體元件 都不需要相同的復原力等級。想像一下在節禮日（英國的黑色星期五）時，庫存管理系統發生故障。如果這表示我們無法檢查庫存，我們就會確認無法履行的訂單，或是不接受訂單，這兩種情況都會造成重大損失。然而，如果履約系統發生故障，可能會讓訂單排隊等待處理，這可能會導致交貨延遲。企業領導人可能會認為後者是一個較小的問題，因此準備接受該系統較低的復原力。無論具體情況為何，關鍵在於復原力等級是一項業務決策。資料一致性也是如此。在查看分散式資料庫時，架構師通常會猶豫是否要放寬一致性以換取可用性。但是，重複預訂幾間飯店房間的業務成本可能遠低於完全不接受預訂。CAP 定理中規定的在一致性和可用性之間進行權衡，是一項業務決策，而不是技術決策。

跨職能需求應由業務價值來證明

這裡的主題是，我們不應該只評估功能的價值，還應該評估通常歸類為跨功能需求的系統特性（我們偏好將非功能需求或「性」稱為跨功能需求）。如果我們希望我們的系統符合某些技術標準，那麼我們需要了解無法做到這一點會損失什麼價值，並將該價值傳達給非技術利益關係人。評估 CFR 的價值通常很困難，許多技術人員會迴避由此產生的爭論。但如果不這麼做，造成的危害不只是投資於低價值技術的風險。它還會在技術人員和使用者之間建立真正的合作障礙。

了解價值應該告知有關元件彈性的決策。一位客戶有一個付款處理元件，該元件經過編程，可與特定的付款處理公司合作。他們希望它易於設定，以便在付款處理器變更時可以快速調整。存在兩個廣泛的選項。一個選項會將與付款提供商系統的互動硬編碼在付款處理元件中，而另一個選項則讓所有此類互動都可設定。可設定的選項允許透過在幾天內變更設定檔來變更付款提供商。然而，通常情況下，這種可設定性會增加元件程式碼的複雜性，這會增加任何其他變更的成本。這是可設定性的常見權衡，你會以在其他地方更難變更為代價，來簡化可設定部分的變更。此處業務背景的重要部分是，變更付款提供商的困難部分實際上是協商新的法律合約，這項工作通常需要一年多的時間。因此，在此設定提供商資訊並不值得，因為修改不可設定的元件仍然比法律協商快得多。

業務價值表示 CFR 會因元件而異

最後兩個範例都說明了在彈性與靈活性等方面採用「一體適用」的方法可能無益且浪費。幾年前，我們與一個組織合作，該組織決定實施全面性的「五個 9」可用性要求，令人驚訝的是，他們甚至將其應用於員工用來預訂最愛午餐點心的三明治訂購系統。我們發現與業務部門同意不同的服務層級可能非常有用，例如服務的中斷是否會立即影響客戶體驗或收入，或者我們是否能負擔得起在資料庫還原時讓服務中斷幾個小時？

另一個可以透過了解系統如何支援業務價值而突顯的問題是，單一元件必須支援多種不同的價值流程和可靠性層級。這在單體元件中很常見，其中支援多種不同的業務流程，且可能是將事物拆解的重要動機，例如僅在對應業務價值合理時才支付高可用性的溢價

使用監控來評估業務價值

我們非常支持使用豐富的監控來更深入了解系統的行為，這對於日益複雜且分布式程度越來越高的系統來說特別重要。此類監控通常著重於系統健康，支援生產中的 QA。但我們也可以使用此類監控來評估系統對業務價值的貢獻，例如確定有多少銷售收入透過特定元件傳遞。一位零售客戶發現監控其大型主機上的佇列長度和訊息速率可以很好地代理衡量其各個商店中獲得的收入，雖然不準確，但讓業務利害關係人取得這些資料讓他們能夠發現純粹從技術角度監控可能錯過的議題。另一位客戶能夠為其網站上的每筆交易推導出準確的收入衡量，並且他們在辦公室周圍的螢幕上逐分鐘顯示這些資料。隨著時間推移，這些資料比顯示 CPU、記憶體和其他技術衡量的螢幕獲得更多關注。

有人可能會辯稱收集此類資料並非了解系統行為的一部分，但我們會主張這是了解軟體元件對業務的貢獻至關重要的情報。隨著更多系統託管在雲端上，我們可以看到為個別 FaaS 函數產生的帳單。如果我們能取得這種詳細程度的成本，我們也應該努力收集收益資料。

定期監控資料可以自行提供投資決策資訊。我們遇到一個使用網路向其公民提供服務的政府機構。其網路應用程式新增功能的成本因支援舊瀏覽器的成本而大幅增加，而這被認為是那些無法升級的公民的強制要求。查看流量顯示，使用此類舊瀏覽器的公民非常少，因此與其支援舊瀏覽器，不如送他們一台新電腦和一束花更便宜。

如果您要移轉到雲端，請只攜帶有價值的部分

隨著雲端系統的崛起，我們看到許多組織希望將其軟體系統移至雲端主機。這與系統更換的悠久歷史類似，公司希望用支援相同功能但運行於更現代化（且希望更有效率）的基礎架構上來取代現有系統。在我們的職業生涯中，我們已經看到數十年來這類的努力，我們發現有容易犯的錯誤。也許最常見的是，系統更換最簡單的方法是功能相等更換，尋求在新的平台上完全模仿現有功能。這種一模一樣的方法忽略了一個事實，即許多現有功能價值不大，有些根本沒有使用，有些則會主動干擾最佳業務流程。功能相等更換比人們通常認為的更困難，花時間避免複製很少使用的功能很容易就能得到回報。

我們合作的一個組織啟動了一項遷移工作，將其 100% 的物流處理程式碼移至一個新系統，這花了好幾個月，並涉及到他們的許多開發人員。當我們與業務部門討論他們的未來計畫時，他們解釋說，由於成本高，他們計畫放棄對許多種類包裝的支援。處理包裝周圍的所有邊緣案例結果證明是遷移中最耗時的事情，但業務部門在沒有它時會很樂意。

因此，了解對業務價值的貢獻可能有助於確定如何進行更好的重新平台化工作。如果現有元件沒有貢獻太多價值，那麼就不應該將它們複製到新平台。這裡的一個常見情況是，一家服務公司的大部分服務都遵循一些常見案例，但有一些不尋常的服務很少出現。這種不尋常的案例通常涉及特殊的軟體支援，但在新平台上重新實作之前，應始終檢閱這些邊際案例。如果業務預計在接下來的六個月內停止提供此服務，那麼這應該是重新實作計畫的一部分。

業務價值至關重要，但並不恆定

與生活或軟體架構中的任何事物一樣，這種價值評估並非恆定的。我們與一家保險公司合作，該公司透過其評分模型獲得競爭優勢。這款軟體被視為該公司的皇冠上的寶石之一。但隨著時間的推移，保險報價已大量轉向線上進行，並進行直通式處理。皇冠上的寶石需要許多參數，在線上時代之前，透過代理商與客戶會面可以合理地擷取這些參數，但複雜的表格在網路上沒有吸引力。隨著這種轉變，皇冠上的寶石價值逐漸消失。因此，除了了解軟體資產的當前價值外，還值得嘗試粗略預測技術和業務環境的變化如何影響該價值。

另一種情況是零售商，其目錄管理系統可以輕鬆應付每年兩次的更新，但無法應對快速線上變更的轉變。損失收入的機會成本從來都不是一件容易量化的事情，但在決定將投資用於重組或重寫組件時，需要考慮這一點。

業務知識應成為技術職涯路徑的一部分

當人們關注技術領導者的成長時，大部分注意力往往會放在「硬」技術主題上。各種軟體平台的培訓課程（經過認證，不少）比比皆是。對於技術技能發展，我們提倡專注於核心原則的培訓，而不是當今流行的平台。明智的技能發展意識到「軟」技能（注意我們的反諷引號）這個困難得多的領域，隨著人們晉升領導階層，變得越來越重要，而這也是我們認可的事情。[1]

儘管這些事情很有價值，但我們也認為確保技術領導者對其經營的業務有堅定的了解，以及領域中的各種參與者如何創造價值至關重要。這通常不是通過培訓課程獲得的，而是通過與商業領導者的定期互動獲得的。這種社交互動應該在技術人員的職業生涯早期開始。認為將 IT 人員與業務人員分開會對軟體開發等職業造成難以估量的傷害，而軟體開發的價值根植於軟體在所支援企業的活動中有多麼深入。開發人員需要及早了解與使用者和客戶保持持續聯繫是正常的，並學習如何做好這件事。多年來的這種接觸在他們成為領導者並熟悉與他們一起成長的業務時，會帶來豐厚的回報。