首先要解釋一下文章的標題，爲什麼是CEO必讀，然後又特別強調“技術無關”呢？因爲我們都知道在過去的雙十一中，在一天時間之內互聯網用戶（C端）、電商平臺（B端）、所有平臺上的商家以及支付&物流系統（B端）在強大的技術平臺（T端）支撐下，單一平臺實現了超過3000億規模的交易，衆多電商平臺完成了超過5000億規模的交易，這應該可以說是非常讓人歎爲觀止的T2B2C的實戰案例。在這個過程中，所有企業的CEO都一定要去關注一個問題：如此龐大的交易是如何做到平穩有序進行的呢？這中間的技術能力如何強大，衆多的企業如何構建出一個強大的技術平臺用於企業的數字化升級（員工在線、產品在線、客戶在線、管理在線）呢？與其羨慕，不如進來一探究竟吧。
同時也說一下在金融行業正在發生的事情，一邊是金融企業大量的裁員，另一邊是大量招聘具有FinTech的專業人才，所有在職人員都必須會用SPSS、PYTHON（人工智能領域的編程語言，沒錯，要求金融行業人羣也要會編程），例如：JP Morgan首席運營官馬特·澤瑪斯曾表示：“我們要保證行業領頭羊地位，就必須得在金融科技上先拔頭籌。”像JP Morgan在金融技術領域也走在行業前沿的金融公司專門設立了技術中心，聘用約4萬名技術工作者，技術預算達96億美元，專攻大數據，機器人和雲基礎設施。此外，它還和英特爾、微軟等30多家企業組成了一個新的區塊鏈聯盟，以開發相關的標準和技術。
雖然傳統行業的CEO不用在金額行業對於IT技術的要求這麼極端，但許多CEO有着豐富的商業背景，並不具備IT與互聯網技術的背景啊，一說到強大的IT系統，大家就立即就浮現出了一行行的代碼，一排排的服務器，雖然這是真實的代碼世界。但我們就在代碼世界裏仍然是有許多可以進一步進行抽象、構建成爲模型的領域知識，用於各位CEO進行商業決策時的技術指導思路參考。
如：CEO在面向企業的CIO或是CDO向自己彙報需要構建系統的時候，除了關注系統好不好用之外，還需要進一步關注系統的架構設計，是否在安全、可擴展性、高性能層面有所保障？過往的決策邏輯似乎很簡單，只要選擇國外知名廠商的系統平臺就可以支撐自己企業內部的應用了，即便系統出問題了也不是做選擇的那個人技術負責人的問題，因爲這裏有一句潛臺詞：我已經選擇了全世界最牛B的系統，如果還出問題就不能怪我能力不行了吧。
但如今從中國雙十一的實踐來看，能夠進行支撐海量大規模交易的系統並不是一箇中心化的、大而全的統一化平臺，而是基於衆多生態企業進行緊密協作的，形成生態協作網絡的“鬆散組合”的生態平臺，在統一的接口與技術規範下各自發揮的平臺，那我們還能用簡單的一句“國外的月亮就是圓的”來做技術平臺的選擇嗎？從這個視角來看，未來商業企業的CEO必然要面對企業的數字化升級、轉型的問題，必須要對IT技術領域要有一個初步的認知與瞭解。
從這個視角來看，我們不妨先看似最神祕的“系統架構”來看一下，CEO在沒有技術背景下，如何去理解一個軟件平臺稱的上“高大上”呢？借用前eBay、Palpay CTO在《架構即未來》（《THE ART OF SCALABILITY》）一書的觀點來告訴各位CEO，其實技術架構沒有這麼複雜，甚至從某種程度上來說，技術架構與組織架構一樣也是要符合一些基本原則的。（注意：這也是真正CTO的能力，將一個CEO不懂的技術領域用商業語言進行有效表達，做好技術創新與商業價值之間的轉換及平衡）
好的IT系統架構原則是什麼？首先，這是需要符合SMART原則的架構設計，是可以影響團隊的行爲和文化的，它們應該幫助指導設計，並以此測試和確定這些設計是否符合公司的目標和需求，有效的架構原則與公司的目標、願景和使命緊密地結全在一起。一個好的架構原則有以下幾個特點：
1、具體的：原則不應該被混淆在它的措辭中，如果一個系統架構只是說明了技術很牛B，但不能舉例說明具體場景的，那可能這只是“看起來高大上，但實際上沒有什麼用”；
2、可度量的：原則不應包含“無限”這樣的詞彙，如可支持無限擴展，畢竟任何的技術架構實現都是會有資源與成本投入的，一個可度量的目標是技術架構規劃的商業限制邊界所在。
3、可達到的：儘管原則應該是鼓舞人心的，它們應該能夠在設計和執行上實現，只能畫餅不能兌現的目標不設也罷。
4、現實的：團隊應該有能力達成目標。有些原則是可以實現的，但是需要時間和天賦。
5、可測試的(Test)：修改後的原則可以用於測試設計 ，以驗證它是否答規整需要，如果最後的這一個環節中，我們沒有辦法做到可測試的話，那意味着我們仍然沒有形成校驗的閉環，仍然是一個假設的架構規劃。
談起來可衡量這個事情，對於非IT領域的CEO來說心裏就算是有底了，就是拿個尺子去量唄，那具體應該怎麼量呢？
對於架構設計的原則，主要是從三級指標來衡量，首先系統要能用、可以用，別這麼輕易地就掛掉，所以第一組指標是可擴展性、可用性、質量；再者系統應該是符合財務投資視角的“成本/效率比“的，那第二組指標爲成本和效率性相關指標；最後一組指標則更爲高級一些，是指開發、運行的處理能力的，第三組指標就是爲TTM（設計響應時間），當然也會有在這個三個要素下的綜合類指標，包括異步設計與自動化等，這些要點可以從上述的架構原則維恩圖來確定，以下內容是對於架構設計原則的詳細內容展開：
1、N+1設計：這個原則所表達的就是要確保任何你所開發的系統在發生故障時，至少有一個冗餘的實例。應用三規則爲一個爲自己，一個爲客戶和一個爲失敗。
2、回滾設計：無論你構建什麼，都要確保它可以向後兼容。回滾設計是提供網絡、Web2.0或者SaaS服務公司的一個重要架構原則。
3、禁用設計：當設計系統，特別是與其他系統或服務通信的高風險系統時，要確保這些系統能夠通過開關來禁用。這將爲修復帶來額外的時間，確保系統不因爲錯誤引起的詭異需求而宕機。
4、監控設計：如果監控做的好，不僅能夠發現服務的死活，檢查日誌文件，還能收集系統相關的數據，評估終端用戶的響應時間，如果系統和應用在設計時就考慮好監控，那麼即使不能自我修復，也至少可以自我診斷。
5、設計多活數據中心：必須擁有多個數據中心，以便向股東保證可以渡過任何在地理上可以隔離的災難和危機。開始考慮數據中心運維策略的時間，不是在部署數據中心的時候，而是在設計數據中心的時候。
6、使用成熟的技術：新技術往往可以幫助我們降低成本、減少產品上市時間，降低開發成本、提高可擴展能力、減少終端用戶的響應時間。
7、異步設計：異步系統對於速度減緩更加寬容，在某些情況下，反應可能會有所減緩，但整個系統不會停頓下來，這種方法可能會給你幾天時間來“解決”一個擴展性的瓶頸問題，而不是像一個同步系統那樣需要立即採取行動。
8、無系統狀態：狀態系統中的操作都是在前後關聯的情況下進行的，因此對於任何給定的執行或系列的請求，其過去的操作信息必須要暫時存儲在某個地方，儘管在許多情況下狀態是有價值的，但應該密切評估其投入產出效益。狀態通常意味着需要額外的系統和同步的調用，也使得設計多活數據中心更加的困難，所以只要有可能就要避免開發需要狀態的產品。在必要的情況下，可以考慮存儲在客戶端，而不是在系統裏。當然，嘗試把狀態信息按照客戶或交易類別分割以便於更方便地分佈存儲在多個數據中心，並儘可能把某個客戶或某交易類別的數據存儲在一個數據中心，只需爲災備複製數據。
9、水平擴展而非垂直升級：如果你想達到近乎無限的擴展，那麼就必須分散系統、組織和流程以利於擴展。特別是當利用IaaS廠商提供的彈性和自動擴展功能時，水平擴展而不是垂直升級的能力非常重要。
10、設計至少要有兩個步驟的前瞻性：領導者、管理者和架構師都要考慮未來，對於任何服務都應該考慮如何進行下一個分割。
11、非核心則購買：無論你和你的團隊有多麼聰明，你不可能什麼事都做得最好，因此非核心購買是一個成本效益原則，它也影響可擴展性，可用性及生產力。
12、使用商品化硬件：類似於使用成熟技術的原則，硬件，特別是服務器的商品化迅速，基於成本原則以市場購買爲特徵的趨勢很明顯。
13、小構建、小發布、快試錯：小版本的失敗率較低，因爲失敗率與解決方案中的變更數量直接相關。
14、隔離故障：我們要認識到工程們懂得該如何把事情做好，但是往往很少花時間去思考清楚系統是怎麼失敗的，故障隔離的原則類似於建立一個有斷路器的電氣系統。
15、自動化：設計和構建自動化的過程，如果機器可以做，就不要依賴於人。所有系統都應該在開始設計的階段就要考慮自動化。自動部署、構建、測試、監控甚至報警。
許多架構設計原則也只是原則，無法有效執行落地，那就要從技術團隊的運營管理機制上來保障，因此可以有兩個積極的軟件工程過程來保障，事前規劃所需的聯合架構設計（Joint Architecture Design,JAD）和事後審查的架構審查委員會（Architecture Review Board，ARB），這兩個過程本質上是跨部門並交織在產品或軟件開發的生命週期中，JAD是一個協同設計的過程，所有的工程人員一起共同設計和開發一些符合架構原則的主要新功能。而ARB是一個架構設計得到最終簽署之前，要由該委員會確定設計符合公司所有的架構原則和業界的最佳實踐。
JAD是一個協同設計過程，它集中所有工程需要的資源共同完成新功能或進行架構修改所需要的設計工作，這些設計必須符合公司的架構原則和最佳實踐要求，JAD的目的就是通過跨部門的認知型衝突（認知型衝突是一個良性衝突，而惡性衝突則爲情感衝突）來增加創新。JAD團隊應該包括一個未來負責編碼的軟件工程師、一位架構師、至少一個運維工程師、產品經理、項目經理和質量保證工程師。
而ARB的團隊成員都需要展示自己的專長，無論是在工程、架構還是業務方面，這就需要有以下人選侯選人，包括：首席架構師、可擴展性架構師、基礎設計架構師、工程副總或董事、運維或基礎設施的副總裁、高級系統管理員\DBA、高級工程師、CTO和CIO、事業部總經理、產品或業務負責人。ARB團隊最好是由4-8人組成，需要每週一次會議來審視JAD的工作成果，因此考慮到團隊中人員的精力投入，可以考慮設定一部分人員爲ARB的常設人員，另一部分則爲輪換，每季度調整一次ARB委員會的輪換成員。
當我們要對IT系統構建做決策時，我們在技術選擇上仍然是使用了最常見的商業邏輯：首先界定一個符合SMART原則的技術目標，在這個技術目標之後構建一個完整的技術架構能力評估框架，並通過聯合架構設計（JAD）和架構審覈委員會（ARB）的工作機制來確保決策能夠得到有效落地，看起來很簡單不是嗎？在數字化時代生存，CEO也要懂點技術，這是必須的！