- 組織業務：
- 架構師經由過程索求和研究營業範疇的常識，構建自身看待業務的"世界觀"。他會基於這類認識拆分業務生命週期，確立營業邊界，構建出了一套解決特定營業問題的範疇模子。而且確認模子之間、範疇之間的關係與協作體例。完成了對營業領域內的要素的組織工作。
- 組織技術：
- 為了能在計算機世界中運作人類社會的業務模子，架構師需要選用計較機世界中合適的框架、中心件、編程說話、網絡協議等技術對象依據之前設計方案組織起來構成一套軟件系統方案，在我看來軟件系統就像是一種手藝組織，即手藝組件、手藝手段依據某種邏輯被組織起來了，這些手藝東西被肯定了職責，有了明白分工，並以實現營業功能為方針鸠合在了一路。比如RPC框架或動靜隊列被用於內部系統之間的通訊辦事就猶如信使一般，而數據庫則負責記錄成績，它更像是一位書記員。
- 組織人員：
- 為了能夠實現哄騙軟件系統解決營業問題的目標，架構師還需要關注軟件系統的構建進程，他以實現軟件系統為號召，從公司組織中聚集一批軟件工程師，並將這些人員按分歧工種、不同職責、分歧系統進行組織，肯定這些人員之間的協作體式格局，並關注這個組織系統是不是運作傑出好比溝通是不是順暢、產出是不是到達要求、可否按時候完成等。
- 組織全局，對外輸出：
- 架構師的重要方針是解決營業問題，鞭策業務增加。所以他極度關心軟件的運行狀態。因為只有在軟件系統運行起來後，才能對外供應辦事，才能在用戶拜候的過程中，解決業務問題。架構師需要關注運行過程中產生的數據好比業務成功率，系統運行資源佔用數據、用戶反饋信息、業務增長環境等，這些信息將會扶助架構師擬定下一步架構方針和方向。
所以軟件架構不僅僅只是選用什麼框架、選用什麼技術組件這麼簡單。網站架設它貫穿了對人的組織、對手藝的組織、對業務的組織，並將這三種組織以解決業務問題這一目的有機的連系在了一起。
良多面試的候選人在被問及他所開辟的系統採用什麼架構的問題時，只會枚舉出一些手藝組件、技術框架等手藝要素，如許看來其根本沒有理清架構的深層寄義。也有一些架構師只專注對底層技術的研究，以為打造一個卓著的系統長短常牛逼的工作，可是他疏忽了軟件系統的價值是以解決營業問題的能力、支持營業增進的能力為權衡標準，所以最後生產出了許多對組織，對營業沒有幫助的系統。
本錢與收益正如之前所說軟件系統只有在運行的時辰才能締造價值，也就是說軟件系統能否7*24小時＊365天穩定的工作關係到公司的收益程度。所以開發團隊對生產情況的發布老是戰戰兢兢，對解決生產情況的問題老是加班加點。而軟件系統的本錢則體現在軟件構建過程，這時候候我們就能理解那些工程手藝如項目辦理、火速開發、單位測試、延續集成、延續構建，版本經管等的價值了，他們有的是保證軟件系統准確性，有的是為了降低溝通本錢，有的是為了提升開發效力等但總的來講就是為了下降軟件的構建本錢。所以在提升系統辦事能力，創造更多業務收益的同時，下降構建成本也是一種晉升收益的有用手段。
作為一位軟件工程師而言，我們往往處在軟件構建進程系統中的某個環節，我們可以基於本錢與收益的關係去思慮本身每項技術的價值，進修新的有價值的技術，乃至在工作中基於本錢與收益的考量選擇適合的技術。好比在邏輯不大發生變化的處所，沒有需要去做過量的設計，利用各類花俏的設計模式等浪費時候。如許我們才能成為手藝的主人。
架構方針需要順應營業的成長
架構的目的就是為了支持營業增長，就是晉升軟件系統的服務能力。
可是話雖然說如斯，但真實卻要做很多取捨。
比如對始創團隊而言，其產品是不是解決營業問題這一設想還沒獲得確認，就立即去機關一個高機能、高可用的散佈式系統，這樣的架構目的遠超越營業成長的需求，最後的效果就是虛耗大量人力物力，卻得不到任何起色。架構師需要審時度勢，仔細權衡正確性、大範圍、可用性三者的關係，好比本年業務蓬勃發展日均定單300萬，基於對將來的可能展望，來歲可能有3000萬的定單，那麼架構師應當要側重斟酌大範圍和可用性。並且每一點晉升的程度，也需要架構師衡量掌控，好比可用性要到達2個9照樣3個9。
回顧自己以往的工作很多時候就是因為沒有確立架構方針致使鋪張了組織良多資源，好比在之前的創業團隊中，由於本人有必然的代碼潔癖，常常會破費很多時間和同事計較代碼質量，如許本可以更快上線的功能卻需要被延遲，當時過度尋求准確性的行為是與創業團隊快速驗證設法的營業需求不匹配的。
別的一點比力深刻的案例則是在本人擔任一個手藝團隊負責人的時候，在一次述職講述的時刻，leader問我對接下來團隊工作有什麼計劃？我那時說了一堆什麼改良代碼質量，天天晨會，任務透明化，設立建設迭代機制等等，然後就被各類褒貶一通。
那時團隊基本以外包人員為主，人員水平較差，開辟出來的金融系統也是千瘡百孔而這條營業線最主要的營業價值則是按企圖實現潛在投資方的需求，爭取拉到投資。
所以不久leader就召集測試架構的相幹人員與我這邊一同梳理對核心功能的測試工作，將研發、測試、上線的流程主動化。
其時並不理解如許做焦點價值是什麼？但回過甚來看如許的工作體例恰恰相符了營業發展的需求，即確保系統是符合設計需求的，包管系統到達可接管的正確性，為後續能過快速前進打下基礎，最主要的是為企業下降了構建本錢。
所以程序員想要工作出業績，必須認清晰系統背後的業務價值，按價值去梳理工作優先級，而不是像我一般過度糾結細節，尋求手藝理想化。
成也分工，敗也分工
正如在法式員的渺茫那一章節提到的：法式員的迷茫因為持久埋沒於軟件世界的浩大的分工系統中，無法看清從營業到軟件架構的價值鏈條，沒法清晰定位本身在分工體系的位置，處置欠好本身與手藝、營業的關係而至，所以在這裡我想談談分工。
架構師為了使軟件系統更好的辦事業務，必定將軟件系統生命週期進行拆分，好比分出開辟生命週期、測試生命週期、用戶接見生命週期、軟件運維生命週期。並根據不同的生命週期劃分出分歧的職責與腳色，比如開發人員負責開辟週期負責完成軟件研發，測試人員負責對開辟人員交付的功效進行測試等，於是就構成了分工。
一旦分工構成，每個分工組織都會有自己的價值尋求，架構師關注的頂層的價值即軟件系統可否支持營業增長被分工的情勢打碎到各個組織中。
分工是有其價值的，他使得複雜昂貴的任務可以被簡單、並行、可替代的流水線體例解決。
但長此以往，價值碎片化的問題就呈現了，好比測試人員只關注找出更多問題，開發人員只關注快速開辟更多的系統，運維人員只關注保障系統不變。
三者之間經常都只站在本身的立場去要求對方怎麼做，沒有人再關注整體價值，產生諸多矛盾增添軟件實施本錢。
而身處流水線中的一員，又因為困擾於反複性工作，渺茫於工作的意義，乃至感受自己做為了人的創意與靈感都被抹殺了。所以我的伴侶吐槽我說你寫了那麼多代碼然後並沒有怎麼樣長短常有道理的，那是因為我只關注著做為流水工人的價值要求，看不到生態鏈最頂真個價值。
我們細心想一想那些團隊輔導，精英首腦哪個不是為著更恢弘的價值所負責，比如項目司理只需要關心本身項目標貿易價值，而公司CEO則關心公司領域內所有業務的總體貿易價值。
所以關注的價值越大且職位也就越高。這些高層領導者們把控著整體的價值鏈條，及時改正底層分工組織的價值方針與整體價值方針呈現誤差的問題。
從價值出發－找尋學習與工作的新思緒渺茫能激發思考，架構則塑造了視野，而價值則是我們之所以存活，之所以工作的邏輯出發點。
基於如許一種價值思惟，對我們的學習和工作又可以有哪些改啟示呢？
