前言
什麼是架構？
通常情況下，人們對架構的認知僅限於在軟件工程中的定義：架構主要指軟件系統的結構設計，比如常見的SOLID準則、DDD架構。一個良好的軟件架構可以幫助團隊更有效地進行軟件開發，降低維護成本，提高系統的可擴展性和可維護性。這裏的架構定義有更多元化的理解：架構不僅是對軟件開發設計和流程規範的定義，也包含了參與架構設計的人員、以及項目過程中和架構有關的活動，都可以稱爲架構。
從廣義角度來理解架構，意味着更全面的思考和新的融合。
按這張圖理解，架構是指架構師以商業價值爲導向、以用戶爲核心，在所處的商業、文化、技術環境中，利用有限的資源和成本，設計架構方案、組織或參與研發活動，從而達到既定目標的一項複雜且持續的活動。
架構師面對實際問題，在複雜的環境中如何做出正確的選擇，如何確保架構活動順利進行，保障項目落地，可以從目標、資源、行爲、趨勢這四個層面來梳理。
架構
目標
明確目標：在開始新事物時，可能需要面對各種各樣的選擇和挑戰。在這種情況下，明確具體的目標並非易事。
-
可實現：目標需要具有可實現性，過高或過低的目標都可能導致挫敗感和疲憊。要在充分評估自己能力、資源和環境的基礎上，設定合理的目標。
-
具體、明確：目標應該具體、明確，易於衡量，以便對自己的進展進行有效跟蹤和調整。將目標細化爲若干小目標，有助於更好地管理和實現目標。
-
有彈性：目標制定過程需要有一定彈性，能夠應對不確定性和變化。當遇到挫折或不可預測的因素時，可以適時調整目標，以保持積極的心態和動力。
-
持續關注和調整：目標制定並非一勞永逸，需要根據實際情況進行持續關注和調整。通過定期評估進展、學習經驗教訓，可以保持目標與現實的一致性，並提高實現目標的可能性。
上面4條是指導原則，實際情況更爲複雜，比如技術人員通常以技術驅動去探索目標，但是它不一定適合商業活動。拿MQ的對比Kafka和Pulsar，後者相較更新、更快，技術極客們通常會毫不猶豫的選擇探索後者並將它應用到實際工作中。從普適性很強的成熟方案切換到新穎高性能的方案，除了考慮切換的成本外，還要考慮切換後帶來的收益，以及團隊成員掌握Pulsar的成本。從發展的角度上看，除非Kafka有致命的缺陷且不被修復，那麼隨着時間推移Kafka可以一直演進迭代也會變得更出色。所以單純從短期的技術先進性上看並不可取，也要關注技術的生態，這也就是常說的對技術的生態有一定的前瞻性。
結合自身的情況，在線業務爲什麼要切GBF，是要基於領域建設提高複用度，達到降本增效。架構活動的所有目標都是爲了降本增效。切框架短期內會使業務迭代成本變高，中期途中就會陷入一個悖論：當上下游環境協調成本高時，如果從自身妥協方案，會使得US短中期成本增高，且如果沒有改進的情況下無論是從US自身還是縱觀全局看長期收益降低，但是又不能影響進度，或者說可不可以等時機成熟再進行，我感受到過不小的壓力。
這些原則說起來比較簡單：確保長期目標不動搖，臨時方案做取捨。做下來就會有犯難的時候：如果臨時方案做得多了容易形成包袱，影響長期收益，最終會使定製的目標打折扣。階段目標保障和長期收益並不是完全對立的，實際工作中也會存在需要做取捨的情況，當階段目標和長期收益出現矛盾時，需要架構人員爭取資源或做好取捨。縱使做完決定選擇階段目標臨時放棄長期收益時，這也只是一個短期的決定，並不能代表將來，也就是說在時機成熟的時候（例如上下游在自身的演進中做了理想態的改造），那麼作爲部門自身也需要時刻關注並及時跟進。
談到取捨，深有感觸：作爲決策者或有決策權限的角色，在決策範圍內需要做好取捨。如果當事人不做取捨，那麼就只能讓別人來替他做取捨。執行者大都選擇丟掉休息選擇加班、或者跳過總結歸納改進的環節，長此以往這種決策低效且不科學。決策人員需要做好清晰的取捨，避免無限度的索求（全都要），因爲很有可能無法被完全滿足，導致取捨權分散給執行者。取捨權分散給執行者有什麼不妥？個人認爲取捨的決策權下放分散給執行者存在問題是：執行者接觸到的信息有限、經驗不足易導致決策過於片面，不容易有全局觀，容易做出錯誤的決策，項目風險加大。
資源
資源，是有限的。
作爲一個架構師，要在有限的資源下最大化商業價值。如何讓技術人員站在商業的角度來理解這句話？
這裏描述是一項架構師參與的商業活動，既然是商業活動那麼必定要有商業價值。大部分技術人員並不關注商業的價值邏輯，通常只關注技術方案是否優越，容易忽略技術方案落地過程中客觀存在的資源、環境以及協作等因素。如何讓技術人員理解商業價值，可以從代碼和設計的三個作用來闡述：
技術人員主要通過上面這三個途徑爲公司賺錢。員工的工資和各種收入，來自於公司的商業收入和融資。
結合自身的理解，從公司到組織到個人，都有屬於自身層面的商業邏輯，科學合理可持續發展的商業邏輯也是支撐公司、組織和個人發展的基礎，脫離了合理商業邏輯的事物，短期內看並不一定會有明顯的結果，長期看會衍生出各種各樣的問題，問題的原因不僅僅歸咎於問題本身及產生的過程，更深層次上看是整個的商業邏輯是否合理、可持續。
那麼作爲個人來講，如何做到利用手中的資源最大化商業價值，對公司、組織、個人都能受益？
a.理解你所在的企業或團隊的商業模式
b.理解你在自己所處環境中創造的商業價值
c.保障架構活動的長期商業價值
d.在架構規劃中尋找擴大收入的機會
e.在架構規劃中尋找減少成本的機會
前兩點商業模式和商業價值，每個人的認知不一樣，通俗講就是這個公司、這項業務是不是核心、有沒有前景。對於公司業務前景經常會有不同的聲音，常見於新興業務，屬於仁者見仁智者見智，不過也從側面了印證了最近比較流行的一句話：人們通常賺不到認知以外的財富。行業、企業的發展作爲自然人很難影響和撼動，歷史和趨勢中個人只有選擇的空間。
那麼第三條對我們來講說是一個長期面對的事情：當做出選擇後，如何在工作中確保自己和團隊都能夠有持續的、足量的、正向的價值和收益。和經濟學一樣，技術的邊際效益也是遞減的，因爲技術一直在發展，個人的價值和優勢主要體現在增量價值上，也就是說個人通過工作創造的價值，是在平均價值之上，才能說這個人具有一定的優勢。然而這些優勢並不是一成不變的，因爲開源的解決方案也在源源不斷的提升，越來越多的人掌握，那麼個人的增量價值響應的就會減少，甚至不存在。這也就需要個人不斷的學習、提升自己來持續提高競爭力。
文中提到的資源和經濟學中的生產資料、生產成本類似，商業價值依賴資源，商業公司和組織對員工的期望是最小成本生產最大商業價值，這些無論是從短期還是長期來看都要關注，目標過於抽象時爲了避免不同的人理解不一致，可以根據每個人的環境、崗位具象專屬的目標，最好是根據時間粒度分散成階段性的目標，也就是說於員工個人而言，更多的是對階段性精確目標的最大化投入來取得收益。目標的定製依據這裏已經介紹完了。
當目標確認完後，就要奔着目標，發揮自身的最大價值。也就是兩個方面：發掘機會和減少成本。
機會需要發現，無論是來自於科學的數理統計、分析挖掘還是日常中的一些小Tips，都是在發掘機會。這一點我在業務側會接觸到比較多的機會，版本迭代中通常會和產品聊本次更新的動機是什麼，收益在哪，作爲C端的產品邏輯，除了這些收益，我們還要從用戶體驗出發，這些變化會給用戶帶來什麼樣的方便，以及我們會不會有額外的代價和成本。最常見的例子就是如何在有限的屏效中將活動信息、分享裂變、推薦合理的展示給用戶、引導用戶，以及每個模塊能否讓大部分用戶心領神會設計的初衷，交互能否適應人羣的習慣等等。但目前我還沒有精力投入到指標的研究和跟蹤中去分析驗證，只是有興趣，後面有機會需留意這塊。
除了業務的機會，也有技術的機會。比如發現並抓住開發中遇到的痛點。很多同學在開發或推進過程中會遇到各種各樣的痛點，非常多的情況就是考慮到時間、精力有限等因素後爲了保障任務按期完成，選擇性忽略這個痛點，當任務完成後又投入到其他事項中。這些痛點雖然造成了體感上的影響或者影響了一點點效率，但並沒有被抓住解決掉，因爲單論這一個問題不會被放大，也不影響KPI或OKR，痛點存在還會繼續影響其他將要遇到的“幸運同學”，當忽略的次數變得多起來，量變易引發質變：框架不夠好用。如何應對這種現象，個人覺得可以設計一種機制，強化痛點發現、上報、跟進、解決、反饋提升，也會從側面提醒項目Owner除了關注任務的進度，也要關注任務完成的質量。
成本包括人力成本、時間成本、機會成本，也包括技術遷移的成本，作爲架構師，需要從各類複雜成本中去衡量，按時間軸推演，保障中長期的收益。
行爲
技術同學每天沉浸在邏輯中，容易陷入一個思維區域：世界由邏輯和數字主宰。合理的結構中商業活動需要和技術解耦，因爲技術自身不會給企業和組織帶來價值，而是大多數企業和組織作爲一個平臺，使用技術盈利。技術落地的過程鮮有單兵作戰，大都是團隊協作、組織協同。上面這句話推導的邏輯是：商業價值 --> 組織活動 --> 人在組織 --> 活動主體是人 --> 遵循人性。
提到人性，就會提馬斯洛需求層次模型。儘管每個人所處的環境、接觸的信息、個人的觀念各有不同，需求層次模型也會有千差萬別，但是從公司、組織和員工的角度來看，這一模型相對穩定清晰。動機的搶佔模型也可以理解爲需求的壓制模型如下圖：
有時候任務推進會感覺到超乎尋常的艱難，合適的溝通方式表面上可以避免一些矛盾，本質上是作爲被推進方，或者當事人的資源不足（例如需求排不開），通常推進方並不瞭解合作方的需求優先級或依賴層次，和他要配合做這件事的成本，有些事只是在推進放看來比較簡單，就會有一個求證的過程，這個過程有沒有必要我自己也不太清楚。當這些需求得不到滿足的情況下，合作方會自動誘發動機，主導的意識和行爲通常讓人難以理解，遇到這種事情的解決方式是分析他的需求優先級，是否存在動機壓制，以及能否協調調整優先級，改變動機壓制的重要性和次序。
在最近的工作中經常遇到的一個現象是：方案可行，但是協同方沒資源。因爲組織的資源不單單爲我所在的一個項目提供，而是要支撐當下階段的各個目標。如何在多樣目標和複雜的組織資源協調中找到最優解，是非常困難的一件事情。作爲參與方，儘量去解，臨時做兜底。一次次兜底就是一個個小包袱，還要不忘提醒自己包袱不要太多。
動機優先級中每個人的認知和安排是不一樣的，有一個可以參照的依據：設計思維的精髓在於深度理解和尊重用戶，對技術人員來講到底是被動地迭代方案，執着於填補設計的漏洞；還是從共情用戶的角度出發，脫離現有技術方案的束縛。同時忘記現有的技術方案的優勢， 把關注點放在深度理解用戶、解決用戶的痛點上，進而拓展技術設計空間，找到更完美的技術路徑。答案不言自明。
上面提到的這些只是理論，也就是我們常說的理想態，能否很好的落地就變得複雜起來，因爲單純從理論上來看這些對每個人的要求非常高，無論是職業素養還是主觀能動性上，做到的都是少數。同時伴隨着邊際效益遞減、35歲危機、996等熱門社會現象，底層邏輯是人們沒有安全感導致行爲偏重自保，這些能不能帶來商業價值是值得分析和審視的。這裏提到的安全感是指能夠影響人做出科學決策的環境壓力，並不和居安思危中的危機感對立。
結合自己在技改項目的過程中，有同學反饋擔心會失去手裏的業務和之前負責的一些方向，也有同學有需求壓制導致參與度不高，有的會在交談中表達，有些雖然不明說，但種種跡象表明團隊協作或工作內容沒有安全感。我給出的反饋和建議是：當前目標是降本增效，業務的前景很寬廣，當下還在高速發展，完全沒理由縮編，但是這並不意味着可以無限度的擴張。我們需要在思考如何在不擴編的情況下更高效的做更多的事情，花更短的時間，支撐更多的行業。消除危機感的同時，還需引導良好的設計思維，剛纔提到的深度理解和尊重用戶，很多同學是需要這種自我滿足感的，但是當節奏變得緊張、感受到環境不寬鬆時，這些也就隨之被拋諸腦後轉而去滿足更原始和低層次的動機，也就是面對源源不斷的需求和迭代，將任務填滿日程表，從而持續不斷的投入到緊張的迭代中。
順勢—天時、地利、人和
如何看清行業的週期、把握新技術。
俗話講，你永遠叫不醒一個裝睡的人。是這個人不願意醒嗎？我看未必。而是人性的一些弱點導致這個人不願意接受現實、害怕變化、對過往的路徑嚴重依賴、或者思維僵化，導致他不想醒。自我麻痹源自處於風險或者壓力下的自我保護機制：當個體面臨壓力、困境或威脅時，爲了保護自己的心理健康和自尊，會出現一些消極的應對策略。這些策略通常表現爲對現實的否認、迴避或者對問題的輕視，從而使個體在心理上暫時免受困境帶來的痛苦。然而，長期的自我麻痹可能導致問題惡化，無法解決現實生活中的問題，不能全力探尋新的出路，甚至用勤奮彌補內心的不安，容易陷入於目標無用的布朗運動——目標不清晰、動作不連續。
畏懼變化：當人感受到壓力時，對變化感知異常慎重。在繁忙的事務中如何保持專注，歷史的包袱能不能放下，如何卸載，短時間內卸載不掉那如何長線對待，如何同時支撐好業務，當同時面臨這些問題時，每種取捨都有它自身的底層邏輯，當我們面向未來去思考這些問題時，就知道當下該如何選擇。
對於路徑依賴可以很好的用一句話解釋：成功可以借鑑，但不會復刻。技術的生命週期，可以從技術社區中獲取，技術的週期源於大多數人對該技術的定位。如果工程師們對這項技術不再有需求，那麼這項技術的命運將會毫不猶豫的被拋棄。
對技術週期的瞭解作爲架構師的基本功，這裏不再作分析。當一個架構師的技術掌握優秀時，又要避免一個誤區：拿着錘子看什麼都是釘子。技術是實現商業價值的一個手段，並不是唯一路徑。在這個前提下技術不能拖累商業價值的最大化。所以說架構師面對公司、組織、以及工作開展的實際情況，要選擇合適的技術方案。
如何定義合適的技術方案？先看三個不同的研發活動的層次：
架構師在這三個層次的研發活動中側重點是不一樣的，技術驅動需要保證技術的先進性、產品驅動保障客戶的體驗、業務驅動保障業務指標的全盤增長。
影響技術體系建設的外部因素還有行業發展、企業內部指標的壓力、組織結構的影響等等，需要架構師獲取全面的信息，通盤抓重點，找到保障商業價值最大化的關鍵因素和節點。
總結
最近在學習郭東白的架構課，本篇文章主要是結合自身實際的經歷闡述架構師定位、架構活動如何保障企業、組織實現商業價值，以及從員工層面的執行、管理角度分析各層次的定位、方向，通過這些思考總結沉澱，幫助我們在工作中更好地做技術落地和業務支撐。