西方有句諺語叫做："an elephant in the room"。
用以指代那些顯而易見又容易被忽視的東西。
這些東西是什麼呢？
"an elephant"：我們可以解釋為那些重要的，困難的或者棘手的。
這裡我們要討論的則是架構中的"大象"：業務價值。
通常我們做架構評估的時候，一般會對關聯絡統的效能，容錯彈性，業務擴充套件性等進行論證，但很少會考慮各個系統的業務價值以及這些業務價值和前述架構特性之間的關係。
沒有這些價值關聯的理解，對於架構設計中的一些關鍵因素選擇就會很難做決定。
交易系統容錯
以向交易系統新增容錯機制為例，通常需要花費大概幾萬到幾十萬不等。那麼這筆錢到底值不值得花呢？
做這個決定的前，要先了解系統所承載的業務價值，如果是日億級的交易量業務，那麼上面所說的花費就顯得微不足道，是否新增容錯機制這個架構元素也就更容易做決策了。
這裡舉上述這個例子，並不是為了申述架構團隊在做決策時容易忽略業務價值因素這個問題。相反，這個點的考慮也已成為了普遍會進行考量的關鍵點。這裡所要重點指出的是，很多時候，架構團隊並不能很好的明晰各個系統所承載的業務價值是什麼？價值的量是多少？不同系統模組對業務表現的貢獻？
保險公司系統微服務化
一個保險公司確定要將公司的單體服務拆分為產品線維度微服務（家庭險、個人險、車險等），但是它們對不同業務線對公司利潤的貢獻比例不甚清楚。那麼這種情況下需要優先考慮哪些決策因素呢？可以肯定的是首先需要拆分出的一定不是價值最高的業務，因為第一次拆分必然會伴隨著許多不定性的風險。前期非核心繫統遷移的試錯，經驗積累必不可少。
一、核查架構價值流對映
首先要做的是針對架構中的每一個系統模組，構建其價值對映。也就是每個系統對應的業務價值對映。
企業透過業務系統來服務外部客戶，客戶在使用企業的服務時都會遵循特定的行為步驟。
以使用者購買商品為例，使用者通常會執行登入、查詢商品、對比價格、下單、支付，檢視訂單、跟蹤物流，商品簽收，服務評價等一系列操作。使用者每一個操作行為都對應於業務系統特定的服務模組。基於此，我們可以明晰每個業務系統模組對於服務使用者這個商業行為的貢獻價值，以及各個環節的失敗影響。
二、考量系統異常的業務價值影響
我們評估一個業務系統模組的價值的時候，除了有明確的其承載的業務價值的標準，對於哪些無法明確考量的（如底層資料庫，儲存等）模組，我們可以從另外一個角度來估量：失敗異常會造成的損失。
例如，在某個重大節日大促將要到來之前，研發排期裡已經羅列很多業務功能 feature 迭代需求。此時，要如何將一個看似和業務無關的“資料庫災備、恢復演練”需求插入到日程裡呢？
此時，只需要提出如下問題即可：假如節日大促時，資料庫服務當機了，會造成多大的損失？希望資料庫服務能在多長時間內恢復？
在評估業務價值風險時可以透過如下兩種方式：
1、自上而下，跟蹤業務功能流程並識別支援每個流程節點的業務系統。
2、自下而上，檢查各個業務系統，分析其失敗所影響的業務功能。
風險考量另一個需要關注的點是：不同的失敗異常所可能引發的影響不同。不同的業務系統所需要的系彈性是不同的。
例如，人門對開盤日當機的股票交易系統和一時無法使用的內部報銷系統的容忍係數是完全不同的。達成何種彈性界別完全一種業務決策
還有常見的“資料一致性”問題也是同樣的道理，例如在對待分散式資料儲存時，相對於可用性，架構師更傾向於追求資料一致性表現。但是就商業層面來看，以訂票業務為例，重複訂票反而是無傷大雅，人們更加不願意看到的是無法訂票這種情景。
就如我們經常會談論到的CAP理論一樣，CP ？ 還是 AP ？ 從來都是一個業務決策，而不是技術決策。
三、基於業務價值評非功能需求
在評估功能價值時，不應只關注單一的業務功能，還要考慮如系統質量、相容性、穩定性等非功能性需求。
如果我們想要系統達到某些技術標準，那麼我們就需要讓非技術人員瞭解到，如果達不到這些標準將會失去什麼樣的業務價值。
評估非功能更性需求價值通常都比較困難，許多技術人員也常常會迴避由此產生的爭論。但是避而不談則會產生比低價值技術投入更大的危害，同時也會在技術人員和非技術人員之間產生更大的合作障礙。
以業務價值的理解和元件靈活性需求決策為例，某個客戶的支付處理元件是由特定的支付處理供應商提供服務的。現在客戶想要將支付元件升級為可配置化，這樣就能夠更好的應對支付供應商的變化。要實現這個需要有兩種方案可選，一是將和服務提供商的互動邏輯進行硬編碼處理，二是將所有的互動邏輯可配置化。但是，互動邏輯可配置化處理必然會增加支付元件的複雜性及其它變更的成本，這也會是一個相當大的投入。然而，通常支付提供商變更的商務談判互動會就會花費相當長的時間，這裡或許根本不需要支付元件上的快速配置變更，反而，低成本的硬編碼處理更加適合。
四、非功能性需求業務價值評估因元件而異
上述例項的闡述說明了在評估如系統彈性、靈活性等非功能性需求業務價值上不能單純的採取“一刀切”的統一標準。
例如，實現一個交易系統的5個9的可用性是合理的，但是對於一個內部訂餐系統則是完全沒有必要。
對不同層級業務提供不同級別標準的服務系統是我們應當遵循的基本準則。
特定服務的當機是否會立刻影響到使用者體驗及收入？能否承受資料庫幾個小時的當機，恢復損失？等等。
關於分析系統支撐業務價值，另一個需要關注的情景是：單個元件支撐多個業務價值流及不同業務價值流所需的不同級別可靠性。簡單來說就是公共服務元件問題，尤其在單體服務模式下更為明顯。這也促成了人們對微服務模式的追捧，關注核心價值業務並提供高階別服務系統。
五、基於監控工具評估業務價值
監控是必要且必需的。
隨著分散式大行其道，互動邏輯，互動流程日趨繁雜，監控更是我們能夠把控服務健康狀態的必要工具。
監控資料通常分為兩類：1、技術性指標，這是術人員通常關注的；2、業務性指標，則是我們這裡所需要討論的，對評估業務價值非常有用的資料。
業務性監控資料，如交易資料走勢，營收曲線，使用者活躍度等等，往往成為日常經營決策基礎，更加科學化的以資料驅動企業發展。
六、只進行必要的核心業務上雲
隨著雲服務的日趨繁盛及成熟，很多企業都傾向將自有業務系統遷移至雲上服務。遷移的過程通常會持續很長一段時間，在這段時間內，雲上，雲下服務通常會並行執行。在這個過程中，人們通常會犯的一個錯誤是將所有服務完全的照搬到雲上，簡單的理解為一個複製貼上過程，這是非常不可取的。
上雲應該是一個最佳化，提升的過程。我們前面論述過，核心價值的業務才是最值得關注的。另外，在歷久的業務迭代過程中，存在著許多無用的，低價值的，甚至對業務最佳化形成干擾的功能。因此，上雲之前應該對整個業務系統進行充分的分析，拆解，提優去糟，只將最核心，必要的的業務最佳化上雲。相對於完全的照搬策略，這樣反而更容易實施，roi更高。
七、業務價值重要且變化無常
架構元素業務價值不是一成不變的，同樣一個業務，有發展，成熟，衰敗的漸變或驟變過程，因此相應的價值對映也要做相應的調整。
業務價值預估也是我們進行業務價值評估所必要做的工作，這其中的影響因素包括企業經營決策，行業發展趨勢等不一而論。
比如，大資料模型由原來做推薦，然後跟隨趨勢支撐AI；核心的社群業務轉變為非核心的交易支撐業務等等。
八、技術職業生涯中的業務軟技能
做技術的人不能只關注技術，技術是利器，而業務知識則執利器之手。
技術人員在掌握必要的技術技能同時，更多的應該關注其所負責業務知識，邏輯，業務價值的產生，流動路線，變化發展規律，趨勢等。能夠深刻的理解怎麼能用現有的技術更好的服務業務價值。